Hi Jarek, I think the issue might be that the 'ready for maintainer review' label might be too broad. Perhaps, your auto-triage tool could incorporate an automated ranking system that categorizes each by PR using criteria such as:
1) Urgency (PRs that need to be merged for the upcoming releases should be reviewed first) 2) Contributor History (perhaps contributors above a certain threshold of merges could be prioritized) 3) PR quality (this may include a multitude of criteria including testing and documentation) Note that the above is not an exhaustive list. The basic idea is creating multiple categories from 'most reviewable' to 'least reviewable' (which is currently collapsed under the 'ready for maintainer review' label). This will save time that is currently spent by maintainers pointing out basic issues in lower quality PRs. Granted, there is a possibility for false categorizations here. Therefore, a manual override might be needed if a high quality PR has been miscategorized as low quality. Thanks, Sameer. On Wed, 10 Jun 2026 at 18:29, Jarek Potiuk <[email protected]> wrote: > > I think the process of getting many PRs into green in terms of CI pass > while no meaningful review done is causing a lot of noise. > > That's an interesting comment; I'm glad you raised it. There is an easy way > to avoid it - instead of not commenting on them at all, not drafting them, > and not sending comments. I can easily see how we could avoid the message > noise—for example we could just turn the PR into a draft and "fold" the > instructions into the PR itself. This technique works well for Security > issues, and we could employ it instead. It won't generate additional noise > - and should have the same effect (It can still be done deterministically). > > This way we could keep the same process, and draft PRs that need fixing. > > Would that also solve your problem? And yes I see that as a problem for > people who are using "emails" or notifications as a signal, so that's a > very fair statement. > > Just to clarify: Actually turning the PRs to "ready for maintainer review" > does not send any message in the PR thread so we do not need to do much > about it. > > > My recommendation would be to tune down running the tools. Maybe focus on > > 20 PRs to the finish line and only then move to the next batch. > > Getting 200 PRs into "ready" is proven not useful I think. > If you look at the stats - this already happens - most of the PRs that get > "ready" are not those we drafted. We only turn PRs into "ready for > maintainers" when they are genuinely ready - so all tests passing, and > other "basic" criteria are met. Also note that we have not turned those 200 > PRs into "ready" overnight. If you look at previous reports they are slowly > accumulating - and the "20 at a time" volume is far more than what we > handle on a daily basis > > I do not think we have a problem with "marking PRs ready," but with > handling those that are ready. > > J, > > > On Wed, Jun 10, 2026 at 6:51 PM Elad Kalif <[email protected]> wrote: > > > I think the process of getting many PRs into green in terms of CI pass > > while no meaningful review done is causing a lot of noise. > > My mailbox is swamped and this actually causes me to miss human comments > > across PRs that I track. > > At least for me, it takes longer to track the PRs that I can help review > > and merge due to that noise. The "ready for maintainer review" is not > > useful for me. > > > > My recommendation would be to tune down running the tools. Maybe focus on > > 20 PRs to the finish line and only then move to the next batch. > > Getting 200 PRs into "ready" is proven not useful I think. > > > > > > On Wed, Jun 10, 2026 at 7:17 PM Jarek Potiuk <[email protected]> wrote: > > > > > Hi everyone, > > > > > > Building on Ash's recent discussion, I’d love to start a conversation > > about > > > how we handle our open PRs. While we explore PR templates and > > instructions, > > > I believe looking at our current data can help us find the best path > > > forward together. > > > > > > I’ve been looking into the statistics from our last four weeks of > triage > > > (you can see the details here: > > > https://gistpreview.github.io/?ff06225744d9386195510453190e354a), and > I > > > wanted to share some encouraging insights: > > > > > > - Out of 373 open PRs from non-maintainers, we’ve successfully > > identified > > > 95 as Drafts. Most of these (70%) were moved to draft status during > > triage > > > to help authors focus on fixes, which keeps our main queue much leaner. > > > - We have 211 PRs "ready for maintainer review," meaning they pass > all > > > our CI and testing criteria. > > > - Interestingly, about 108 of these are fully ready but haven't > > received > > > a comment yet, and 23 are approved and just waiting for a final merge. > > > > > > The great news is that about 80% of our current triage actions are > > > deterministic! We could potentially automate these into CI scripts, > which > > > would naturally clear about 100 items from our review queue. I’m more > > than > > > happy to help set this up if you think it’s a good next step. > > > > > > I really value the human element in our community and want to make sure > > our > > > contributors feel heard. > > > > > > Since many follow our criteria perfectly but still wait weeks for a > > > response, I’d love to hear your creative ideas on how we can better > > support > > > them and stay on top of these high-quality PRs. > > > > > > What do you all think? > > > > > > Best regards, > > > > > > Jarek > > > > > >
