Airflow has reached a scale where contributor inflow is much higher compared to maintainer review capacity. Since the challenge now seems to be reviewer bandwidth and attention, especially during release periods when maintainers are naturally focused on release-critical work.
The numbers Jarek shared are actually encouraging in one sense: many contributors are successfully getting their PRs into a reviewable state. That suggests the triage process is doing its job. The remaining bottleneck appears to be getting human eyes on those PRs. As a first step, perhaps we don’t need more tooling yet. It might be useful to regularly discuss these statistics during dev calls so we build shared visibility into the state of the reviewable PRs. We can also nudge swim lane owners which could help us identify where attention is needed. Once we have that visibility and agreement that review throughput is something we want to improve, we can explore whether ownership, prioritization, or automation can help. Thanks & Regards, Amogh Desai On Thu, Jun 11, 2026 at 4:45 AM Jarek Potiuk <[email protected]> wrote: > 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 > > > > > > > > > > > > > > >
