On Wed, 19 Feb 2025 at 17:32, Robert Haas <robertmh...@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
