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: