Re: new commitfest transition guidance

On 2025-02-19 We 1:03 PM, Jelte Fennema-Nio wrote:
> On Wed, 19 Feb 2025 at 17:32, Robert Haas<robertmhaas(at)gmail(dot)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