Re: commitfest.postgresql.org is no longer fit for purpose

On Fri, May 17, 2024 at 9:59 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Fri, May 17, 2024 at 11:05 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > > We already have gone back to that model. We just haven't admitted it
> > > yet. And we're never going to get out of it until we find a way to get
> > > the contents of the CommitFest application down to a more reasonable
> > > size and level of complexity. There's just no way everyone's up for
> > > that level of pain. I'm not sure not up for that level of pain.
> >
> > Yeah, we clearly need to get the patch list to a point of
> > manageability, but I don't agree that abandoning time-boxed CFs
> > will improve anything.
>
> I'm not sure. Suppose we plotted commits generally, or commits of
> non-committer patches, or reviews on-list, vs. time. Would we see any
> uptick in activity during CommitFests? Would it vary by committer? I
> don't know. I bet the difference wouldn't be as much as Tom Lane would
> like to see. Realistically, we can't manage how contributors spend
> their time all that much, and trying to do so is largely tilting at
> windmills.
>
> To me, the value of time-based CommitFests is as a vehicle to ensure
> freshness, or cleanup, or whatever word you want to do. If you just
> make a list of things that need attention and keep incrementally
> updating it, eventually for various reasons that list no longer
> reflects your current list of priorities. At some point, you have to
> throw it out and make a new list, or at least that's what always
> happens to me. We've fallen into a system where the default treatment
> of a patch is to be carried over to the next CommitFest and CfMs are
> expected to exert effort to keep patches from getting that default
> treatment when they shouldn't. But that does not scale. We need a
> system where things drop off the list unless somebody makes an effort
> to keep them on the list, and the easiest way to do that is to
> periodically make a *fresh* list that *doesn't* just clone some
> previous list.
>
> I realize that many people here are (rightly!) concerned with
> burdening patch authors with more steps that they have to follow. But
> the current system is serving new patch authors very poorly. If they
> get attention, it's much more likely to be because somebody saw their
> email and wrote back than it is to be because somebody went through
> the CommitFest and found their entry and was like "oh, I should review
> this". Honestly, if we get to a situation where a patch author is sad
> because they have to click a link every 2 months to say "yeah, I'm
> still here, please review my patch," we've already lost the game. That
> person isn't sad because we asked them to click a link. They're sad
> it's already been N * 2 months and nothing has happened.

Yes, this is exactly right.

This is an off-the-wall idea, but what if the inverse is actually what
we need? Suppose there's been a decent amount of activity previously
on the thread, but no new patch version or CF app activity (e.g.,
status changes moving it forward) or maybe even just the emails died
off: perhaps that should trigger a question to the author to see what
they want the status to be -- i.e., "is this still 'needs review', or
is it really 'waiting on author' or 'not my priority right now'?"

It seems possible to me that that would actually remove a lot of the
patches from the current CF when a author simply hasn't had time to
respond yet (I know this is the case for me because the time I have to
work on patches fluctuates significantly), but it might also serve to
highlight patches that simply haven't had any review at all.

I'd like to add a feature to the CF app that shows me my current
patches by status, and I'd also like to have the option to have the CF
app notify me when someone changes the status (I've noticed before
that often a status gets changed without notification on list, and
then I get surprised months later when it's stuck in "waiting on
author"). Do either/both of those seem reasonable to add?

Regards,
James Coleman