Hi everyone, Thank you, Sameer, for those suggestions. Incorporating urgency, contributor history, and PR quality are good ideas for improving our workflow.
The key is defining these standards together. We can easily codify these priorities in our Pull Request Quality Criteria ( https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#id2). Once we agree on these benchmarks, the triage process can naturally use them (it's currently using those). I’d love to see a few of us team up to draft these descriptions. If we reach a consensus on what a "high-priority" PR looks like, we could even use LLMs to help with the classification. I believe that with our collective willpower, we can better support the humans waiting for our feedback there. But we need - I think a collective agreement on acknowledging this is a problem and some kind of social contract between us here that we would like to solve it. What does everyone think? Best regards, Jarek On Wed, Jun 10, 2026 at 10:18 PM Sameer Mesiah <[email protected]> wrote: > 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 > > > > > > > > > >
