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

On Fri, May 17, 2024 at 7:11 AM Tomas Vondra
<tomas.vondra@enterprisedb.com> wrote:
>
> On 5/16/24 23:43, Peter Eisentraut wrote:
> > On 16.05.24 23:06, Joe Conway wrote:
> >> On 5/16/24 16:57, Jacob Champion wrote:
> >>> On Thu, May 16, 2024 at 1:31 PM Joe Conway <mail@joeconway.com> wrote:
> >>>> Maybe we should just make it a policy that *nothing* gets moved forward
> >>>> from commitfest-to-commitfest and therefore the author needs to care
> >>>> enough to register for the next one?
> >>>
> >>> I think that's going to severely disadvantage anyone who doesn't do
> >>> this as their day job. Maybe I'm bristling a bit too much at the
> >>> wording, but not having time to shepherd a patch is not the same as
> >>> not caring.
> >>
> >> Maybe the word "care" was a poor choice, but forcing authors to think
> >> about and decide if they have the "time to shepherd a patch" for the
> >> *next CF* is exactly the point. If they don't, why clutter the CF with
> >> it.
> >
> > Objectively, I think this could be quite effective.  You need to prove
> > your continued interest in your project by pressing a button every two
> > months.
> >
> > But there is a high risk that this will double the annoyance for
> > contributors whose patches aren't getting reviews.  Now, not only are
> > you being ignored, but you need to prove that you're still there every
> > two months.
> >
>
> Yeah, I 100% agree with this. If a patch bitrots and no one cares enough
> to rebase it once in a while, then sure - it's probably fine to mark it
> RwF. But forcing all contributors to do a dance every 2 months just to
> have a chance someone might take a look, seems ... not great.
>
> I try to see this from the contributors' PoV, and with this process I'm
> sure I'd start questioning if I even want to submit patches.

Agreed.

> That is not to say we don't have a problem with patches that just move
> to the next CF, and that we don't need to do something about that ...
>
> Incidentally, I've been preparing some git+CF stats because of a talk
> I'm expected to do, and it's very obvious the number of committed (and
> rejected) CF entries is more or very stable over time, while the number
> of patches that move to the next CF just snowballs.
>
> My impression is a lot of these contributions/patches just never get the
> review & attention that would allow them to move forward. Sure, some do
> bitrot and/or get abandoned, and let's RwF those. But forcing everyone
> to re-register the patches over and over seems like "reject by default".
> I'd expect a lot of people to stop bothering and give up, and in a way
> that would "solve" the bottleneck. But I'm not sure it's the solution
> we'd like ...

I don't think we should reject by default. It is discouraging and it
is already hard enough as it is to contribute.

> It does seem to me a part of the solution needs to be helping to get
> those patches reviewed. I don't know how to do that, but perhaps there's
> a way to encourage people to review more stuff, or review stuff from a
> wider range of contributors. Say by treating reviews more like proper
> contributions.

One reason I support the parking lot idea is for patches like the one
in [1]. EXPLAIN for parallel bitmap heap scan is just plain broken.
The patch in this commitfest entry is functionally 80% of the way
there. It just needs someone to do the rest of the work to make it
committable. I actually think it is unreasonable of us to expect the
original author to do this. I have had it on my list for weeks to get
back around to helping with this patch. However, I spent the better
part of my coding time in the last two weeks trying to reproduce and
fix a bug on stable branches that causes vacuum processes to
infinitely loop. Arguably that is a bigger problem. Because I knew
this EXPLAIN patch was slipping down my TODO list, I changed the patch
to "waiting on author", but I honestly don't think the original author
should have to do the rest of the work.

Should I spend more time on this patch reviewing it and moving it
forward? Yes. Maybe I'm just too slow at writing postgres code or I
have bad time management or I should spend  less time doing things
like figuring out how many lavalier mics we need in each room for
PGConf.dev. I don't know. But it is hard for me to figure out how to
do more review work and guarantee that this kind of thing won't
happen.

So, anyway, I'd argue that we need a parking lot for patches which we
all agree are important and have a path forward but need someone to do
the last 20-80% of the work. To avoid this being a dumping ground,
patches should _only_ be allowed in the parking lot if they have a
clear path forward. Patches which haven't gotten any interest don't go
there. Patches in which the author has clearly not addressed feedback
that is reasonable for them to address don't go there. These are
effectively community TODOs which we agree need to be done -- if only
someone had the time.

- Melanie

[1] https://commitfest.postgresql.org/48/4248/