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

I think there are actually a number of factors that make this much harder.

On Fri, May 17, 2024 at 2:33 PM Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>
> On 17/05/2024 05:26, Robert Haas wrote:
> > For bonus points, suppose we make it so that when you click the link,
> > it takes you to a box where you can type in a text comment that will
> > display in the app, explaining why your patch needs review: "Robert
> > says the wire protocol changes in this patch are wrong, but I think
> > he's full of hot garbage and want a second opinion!" (a purely
> > hypothetical example, I'm sure) If you put in a comment like this when
> > you register your patch for the CommitFest, it gets a sparkly gold
> > border and floats to the top of the list, or we mail you a Kit-Kat
> > bar, or something. I don't know.
>
> Dunno about having to click a link or sparkly gold borders, but +1 on
> having a free-form text box for notes like that. Things like "cfbot says
> this has bitrotted" or "Will review this after other patch this depends
> on". On the mailing list, notes like that are both noisy and easily lost
> in the threads. But as a little free-form text box on the commitfest, it
> would be handy.
>
> One risk is that if we start to rely too much on that, or on the other
> fields in the commitfest app for that matter, we de-value the mailing
> list archives. I'm not too worried about it, the idea is that the
> summary box just summarizes what's already been said on the mailing
> list, or is transient information like "I'll get to this tomorrow"
> that's not interesting to archive.
>
> > The point is - we need a much better signal to noise ratio here. I bet
> > the number of patches in the CommitFest that actually need review is
> > something like 25% of the total. The rest are things that are just
> > parked there by a committer, or that the author doesn't care about
> > right now, or that are already being actively discussed, or where
> > there's not a clear way forward. We could create new statuses for all
> > of those states - "Parked", "In Hibernation," "Under Discussion," and
> > "Unclear" - but I think that's missing the point. What we really want
> > is to not see that stuff in the first place. It's a CommitFest, not
> > once-upon-a-time-I-wrote-a-patch-Fest.

Yeah this is a problem.

I think in cases here something is in hibernation or unclear it really
should be "returned with feedback." There's really nothing stopping
someone from learning from the experience and resubmitting an improved
version.

I think under discussion is also rather unclear. The current statuses
already cover this sort of thing (waiting for author and waiting for
review). Maybe we could improve the categories here but it is
important to note whether the author or a reviewer is expected to take
the next step.

If the author doesn't respond within a period of time (let's say 30
days), I think we can just say "returned with feedback."

Since you can already attach older threads to a commitfest entry, it
seems to me that we ought to be more aggressive with "returned with
feedback" and note that this doesn't necessarily mean "rejected" which
is a separate status which we rarely use.
>
> Yeah, I'm also skeptical of adding new categories or statuses to the
> commitfest.
>
> I sometimes add patches to the commitfest that are not ready to be
> committed, because I want review on the general idea or approach, before
> polishing the patch to final state. That's also a fine use of the
> commitfest app. The expected workflow is to get some review on the
> patch, and then move it back to Waiting on Author.
>
> --
> Heikki Linnakangas
> Neon (https://neon.tech)
>
>
>