Re: Next commitfest app release is planned for March 18th

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Jelte Fennema-Nio <me(at)jeltef(dot)nl>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Maciek Sakrejda <m(dot)sakrejda(at)gmail(dot)com>, Jacob Brazeal <jacob(dot)brazeal(at)gmail(dot)com>
Subject: Re: Next commitfest app release is planned for March 18th
Date: 2025-03-04 20:34:05
Message-ID: CAH2-WzkxoZh1q0jyiTOua3sbUAmESa89Mo8Q35Pc_pq7ftZt4Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 4, 2025 at 3:06 PM Jelte Fennema-Nio <me(at)jeltef(dot)nl> wrote:
> So patches with failing CI in the "in progress cf" will sort below
> healthy patches in the "open cf". I don't think you necessarily said
> that, but this seemed nice to me. And it's easy to spot which patches
> are for which CF because of the color coded CF labels.

I agree that that's a nice detail. You might as well have a default
sort order that is as useful as possible. But, overall, the important
point to me about this dashboard view is that it emphasizes the actual
workflow of the individual user -- it groups and sorts things that are
definitely relevant to the individual user in one way or another,
based on what they're currently blocking on. In short, it mirrors the
kinds of questions I already tend to ask myself when I'm using the CF
app.

It seems obvious to me that you understand where I'm coming from
already. The things that you added seem like clear improvements,
because they take this general idea further. Prominently placing "Your
still-open patches in a closed commitfest" was a particularly useful
addition that I didn't suggest.

In summary, I have zero complaints about anything I've seen. At least
right now. ;-)

> This kind of sorting is possibly worth tweaking a bit after people
> start using this and running into annoyances or unexpected sorts in
> practice. Some other thing that's missing is the ability to "filter by
> commitfest".

It is probably worth tweaking. But I'd consider what you have here to
be a huge improvement.

> > It'd be nice if at some point you also added the ability to
> > star/favorite/like patches -- I'm thinking of something that worked a
> > little bit like starring a gmail thread. Any such patches would appear
> > towards the end of the dashboard page, in its own section,
> > independently of whether I as a user am involved or not involved in
> > the patch. This would be private information, visible only to the
> > individual user that favorited the patch -- a mere bookmark.
>
> Yeah, I had similar ideas.

Obviously I could bookmark patches myself, using my browser. I don't
think that I'll ever actually do that, though -- I'm likely to just
forget about the bookmarks (they have to be important bookmarks that I
return to again and again, without any reminders). Whereas if I can
star/favorite/like patches, it's unlikely that I'll forget about them
forever -- they'll be on the dashboard view, right at the end. They're
tracked in a way that is just prominent enough to prevent that, but
not so prominent as to cause annoyance (that's the idea, at least).

If I later decide that I actually do want to forget about a patch
forever, then it should be equally easy to unlike/unfollow a patch.
ISTM that there is value in a workflow that makes that into an active
choice.

--
Peter Geoghegan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jelte Fennema-Nio 2025-03-04 20:37:58 Re: Next commitfest app release is planned for March 18th
Previous Message Corey Huinker 2025-03-04 20:30:11 Re: Extended Statistics set/restore/clear functions.