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

On Fri, 21 Mar 2025 at 18:53, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Peter Eisentraut <peter(at)eisentraut(dot)org> writes:
> > - If I'm the committer for a patch but not a reviewer, and the patch is
> > in "needs review" status, then the patch is formally speaking not
> > actionable by me and should not be under "Patches that are ready for
> > your review". Perhaps it should be under "Blocked on others" [namely
> > the reviewers], or in a different category.

I think I agree with this... but is that actually a common situation?
I'd expect people to mostly "claim a patch as committer" when it's in
the "ready for committer" state.

> > - Conversely, if I'm the reviewer for a patch but not the committer, and
> > the patch is in "ready for committer" status, then it's also not
> > "Patches that are ready for your review". This might similarly be
> > "Blocked on others" [namely the committer].
>
> Both of these things would work correctly only for patches that you
> have already claimed as committer. I'm not sure about other people,
> but I rarely claim a patch as committer until I'm actually on the
> verge of committing it. I might mark myself as reviewer sometime
> sooner than that, in which case your second proposal would be a
> net negative for me.

I think probably a nice intermediary solution would be to handle
patches with an assigned committer differently. If a committer
assigned themselves as committer and it's "ready for committer", then
I don't think it should be marked as "ready for your review" for other
committers. If there's no committer, I think it should be, because
*some committer* needs to review the patch but it's unknown which one.

> I don't think we should encourage committers
> to claim patches early, because then they are a single point of
> failure (work-stoppage) in a way that a reviewer is not. Maybe
> we need a way for committers to mark patches as things they want
> to pay attention to, without thereby blocking other committers
> from taking up the patch?

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.

> > - 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.

Instead of showing all patches from all commitfests, how about we do
the following:
1. Show all open patches where you are the author, no matter which
commitfest they are in.
2. If there's currently no commitfest "In Progress", then we show all
patches (where you are not the author) both from the Previous
commitfest and the Open commitfest. I think it would be a shame if
everyone's dashboard is empty in the first week after a commitfest,
just because authors haven't moved their patches over to the Open
commitfest.
3. If there's a commitfest "In Progress", then we only show patches
(where you are not the author) from the "In Progress" commitfest to
keep reviews focussed.
4. Have a separate section at the bottom of the page with all the
patches that you are tracking, but are not matching one of the
criteria from the three rules above.