Re: Next commitfest app release is planned for March 18th - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Next commitfest app release is planned for March 18th
Date
Msg-id CAH2-WzmjsjqeFAV1M3HRRcfGE3UjH2cB1uLev-QNiB3yxPd5Sw@mail.gmail.com
Whole thread Raw
In response to Re: Next commitfest app release is planned for March 18th  (Jelte Fennema-Nio <me@jeltef.nl>)
Responses Re: Next commitfest app release is planned for March 18th
List pgsql-hackers
On Sat, Mar 22, 2025 at 7:15 AM Jelte Fennema-Nio <me@jeltef.nl> wrote:
> Yeah I think we need a way to "star" a patch (not just for committers,
> but for anyone). After creating this initial version of this dashboard
> I realized it's also possible to "subscribe to updates" for a patch,
> which means you'll get emails about it. I think if you "subscribe for
> updates" you should also see it in your dashboard (which you currently
> don't). But I also think there should be a way to "star" something, so
> you see it in your dashboard without receiving email updates about it.

Right. In my view "starring" something should definitely not appear in
the "History Log" of the patch; it should be private.

> > > - Also, my dashboard shows patches from past and future commitfests.  I
> > > don't know what I'm supposed to do with that.  The purpose of having a
> > > "current" commitfest is that you work on that one when it's current.
> >
> > This might make sense for the patch author, but I agree it's not
> > appropriate for anyone else.
>
> I'd love to hear some more thoughts on this. Especially from Peter G,
> because he explicitly requested to see patches from different
> commitfests in this dashboard. So I'm curious about his reasoning.
> Ofcourse we can make this configurable or have two separate pages, but
> I'm wondering if there's a way to change it in a way that works for
> everyone.

Personally, I think it'd be most useful for the dashboard to show all
open patches. I believe that that implies that it'll only show me
patches from either the current CF, or the next CF. But thinking about
it some more...I guess that there are edge-cases, where patches can be
in limbo between being "fully open" and "fully closed". Like when a
patch from an old CF isn't brought forward, and also isn't
withdrawn/returned.

I think that we should apply an expansive definition of "active", that
still shows me things that are less than 100% officially closed.
Possibly with additional visual cues that they're in this in
between/limbo state.

> Instead of showing all patches from all commitfests, how about we do
> the following:

I think that we should show all patches from all commitfests in the
"Personal Dashboard", provided that they're not closed. I probably
don't have enough experience with the current "Personal Dashboard"
yet, but so far it seems like exactly what I had in mind.

If I see something in the "Personal Dashboard" that seems like it
shouldn't be there, due to not being in either the current or next CF,
and am bothered by that, then maybe I should then take it as an
opportunity to fix the problem. As I said, maybe there should be some
additional visual cue that shows certain "Personal Dashboard" entries
are "in limbo". But please don't make entries in this state just
vanish, on the grounds that they're theoretically closed -- experience
suggests that they're probably not really closed at all.

If something appears on my "Personal Dashboard" it appears there
because I actively chose to participate, and hiding things from me on
bureaucratic grounds seems paternalistic.

--
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Melanie Plageman
Date:
Subject: Re: Parallel heap vacuum
Next
From: Tom Lane
Date:
Subject: Re: Next commitfest app release is planned for March 18th