Re: new commitfest transition guidance - Mailing list pgsql-hackers

On Wed, 19 Feb 2025 at 17:32, Robert Haas <robertmhaas@gmail.com> wrote:

What *I* think is incredibly painful is that I can spend an
hour going through the CommitFest and not find a single patch that
needs a review. And it's not just me.I have heard of multiple cases
of people wanting to get involved in patch reviewing and being unable
to find anything that seemed like a good candidate. We are literally
driving people out of our development community by having a CF app
that is totally unusable.

Agreed. For that reason, I've stopped using it for that purpose
completely. And I'm mostly using my inbox for that now. That's also
why I recently added the ability to sort by patch size and the cfbot
status, because those seemed like good indicators to find patches that
I could review with the limited time I have available for that.
Another thing that's high on my list is allowing labeling of entries.
So people can add labels like "dev tooling"/"docs only"/"poc" to make
it clearer for reviewers what to expect. If people have other/better
ideas for commitfest app changes to find patches of interest for them
in the current pile, I'm all ears.

The first priority here, at least IMHO,
should be improving the signal to noise ratio to something bearable.
If we can fix that - even partially - by making someone with ten
patches in the CommitFest -- who is thus, most likely, hoping for
something *at least* 50 to 100 hours of someone else's review time --
have to click 40 times once every two months, that is well worth it.

I'm very skeptical that it will actually meaningfully address the
problem you're describing. Especially given the results of the current
"no notice trial" that was attempted this time. The people that
figured out that they had to do move patches manually, moved 170
patches to the next commitfest while only closing 5 explicitly. There
are currently 84 patches "undecided" and a lot of those are by active
committers/contributors, so I'm very doubtful that with good
communication we would have trimmed more than 40 patches from the
commitfest. And while 40 patches is a decent amount, I don't think we
could expect similar results the following commitfest, due to most of
the dead patches already being trimmed the time before.

I am not saying that is the best possible experience for the
developer. I wish we could keep up on top of all the patch submissions
much better than we do. But insisting that we have to keep track of
the ones that maybe nobody cares about any more on top of the ones
that somebody definitely still does care about is not helping.

I think we agree here. I mainly think that having everyone do that
*clearly care about*, is a waste of everyone's time and is going to
make quite a few people pretty annoyed with this process.

So to summarize my opinion:
Requiring manually moving inactive patches: worth trying
Requiring manually moving clearly active patches: stupid busywork

I doubt too may will get very annoyed. So (following Tom's suggestion) once every couple of months you get an email that says "Hi, the following patches of yours were left over at the end of the CF just ended. If you want them to continue being considered, please move them to the next CF. Click Here"

Maybe that's stupid busywork, but it's kinda trivial.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com