> I'd like to suggest starting there as an initial step, and then > re-evaluating the numbers as the queue drains to see if moving toward a > stricter limit like 5 makes sense for a smooth transition.
I really hope we can proceed step-by-step and try things sequentially. I already - for months been trying to implement the triage steps and saw things working/not working/ working only for a while and many others... So ... time to stop trying, and switch to doing :). I see this progression of things we should try - and evaluate (for about a week per step to see the trend) to determine what works. If we implement everything at once, we might not discover the impact of each individual step. 1) limit PR # -> immediate drop, and we will see if "education" and "limits" will make the trend stabilize or hopefully going backwards 2) Switch CI to run in forks (separate discussion) The steps 1) and 2) are purely deterministic, controlled by basically settings modifications, contributor education + documentation. They are **cheap** to try. Then we have more expensive options: 3) Implement per-area-of-code rules in magpie triage and try them ... in order to do 4) 4) Install Airflow in the cloud and start adding triage automation. This is a heavy lift, as it means we need to start maintaining Airflow and triage workflows, but given all the dogfooding, that might be a good idea). And we can also work - maintainers - on increasing our review capacity **a bit**. It won't be dramatic without impacting quality, but I found my review capacity significantly (not dramatically but visibly) increased, especially in the areas I am not intimately familiar with, when I use agents smartly (enhanced by Magpie). And I learn a lot while doing so about parts of the code I was avoiding and new features implemented by others. In the meantime (and this can also be done in parallel), maintainers can learn to use more AI for reviews in a slightly more effective way. With Magpie already supporting marketplaces and nearing its 1.0.0 release, we could increase its adoption among maintainers. Installation and updates are now super easy: claude plugin marketplace add apache/magpie clayde plugin install magpie-setup@apache-magpie > / magpie-setup Airflow already "adopts" magpie pr-management family of skills and I am already using it heavily and it has **fantastic flexibility** as long as we start using it with some "open minds". * review all PRs that I am reviewer * review PRS for providers that are easy to review, starting from the easy ones * review PRS that have no reviews by other maintainers in dev area * review PRs where I am mentioned * review approve and merge all opened dependabot PRs * review all backport PRs * .... And we can even contribute some new skill capabilities to the Magpie's PR review SKILL to enhance our review capacity. Better selection options, more background tasks, speeding out automated verification and merging some kinds of PRs (backports, dependabot, different kinds of chores that should happen pretty much automatically during review—later automatable with, possibly, Airflow automated AI workflows). I found that with that AI-assisted review I can learn about new parts of code that I did not know and review 20-30 (easy) PRs in an hour (and without loosing focus/quality of the reviews) - getting all the "boilerplate" things such as rebasing, fixups. handling tasks like waiting for CI to be green before merging, all done by the agents. I even found out that what can bring a **lot** of speedup is simply applying nits and fixups and merging PRs without additional round-trip with authors. With agents at your disposal, it's simply fast and cheap and easy to ask your agent: "*Post inline comments about those nits: 1, 2, 3, skip 4, add fixups for the 3, resolve comments, then approve and merge when CI is green and move to the next PR now.*" when you review a bunch of PRs. All that work happens in the background then and you can quickly review many such PRs. The conversational interface of the agents is **fantastic** for those kind of workflows (especially if you have other things to do whil agent reviews next PR). You can easily command + click the PR to open it in browser etc. Of course there is potential bias that Ash mentioned, but I find that the more AGENTS.md instructions we add and the more reviews I do—while continuously adding things to either AGENTS.md or memory—the better the reviews get out-of-the-box and the language of the comments posted becomes more natural. This **might** increase our review capacity if many maintainers gets into similar workflows - and we might do it in parallel - this will impact trends, but impact of influx can be separated from increased review capacity. J. On Tue, Sep 22, 2026 at 8:25 AM Yuseok Jo <[email protected]> wrote: > Hello, > > Thanks Jarek for initiating this discussion with clear data. > > Even as a non-committer, seeing over 1,000 open PRs made it obvious how > tough it must be for maintainers to keep up with the queue. I agree that > addressing this review bottleneck is a timely and necessary step. > > Since much of the current count reflects existing PRs that have accumulated > due to review delays, starting with a cap of 7 or 10 should already be > quite effective at stopping rapid new growth and clearing the top heavy > backlog. I'd like to suggest starting there as an initial step, and then > re-evaluating the numbers as the queue drains to see if moving toward a > stricter limit like 5 makes sense for a smooth transition. > > Thanks for driving this effort. > > Thanks, > Yuseok > > On Tue, Sep 22, 2026 at 6:50 AM Christos Bisias <[email protected]> > wrote: > > > Hello, > > > > Currently there are 1024 open PRs which is crazy. Anything beyond 200 > isn’t > > manageable. > > > > I think 5 is a very reasonable limit. Based on the number of open PRs we > > shouldn’t be arguing over a higher number until the situation improves. > > > > There is no point in having 10 open PRs if no one has the time to review > > them. The longer it takes to get some feedback, the more time you have to > > move on to another issue and then open another PR which will then lead to > > even further delay for a review. Hopefully with a more strict limit, > > contributors will go for quality over quantity. > > The only problematic situation I can think of, is when someone has > reached > > the limit but needs to open a PR for an urgent fix for a bug, a security > > issue, a flaky test, etc. Github allows for a whitelist with users exempt > > from the limit. I think in that case, maintainers could temporarily add > the > > user to the list. > > > > +1 for 5 > > > > Thanks, > > Christos > > > > > > On Mon, 21 Sep 2026 at 22:51 Andrew Chang <[email protected]> wrote: > > > > > Thanks for pushing all of this, +1 on 7. > > > > > > To be clear, I am one of the group A contributors on Jarek's list, so I > > am > > > not a neutral party here. > > > Personally I would prefer a higher cap like 10... but I agree with > > Jarek's > > > and Vincent's point that reviewing and helping others is what Airflow > > needs > > > most right now. > > > > > > I ran some numbers for group A. Since drafts PR now count, here is > what a > > > cap of 7 means for the 9 people in that group: > > > ("typical / busy" = open PRs at p50 / p90 over the days they had any PR > > > open; "over 7" = share of those days above 7): > > > > > > - SameerMesiah97: typical 7, busy 10, over 7 on 43% of days > > > - shivaam: typical 4, busy 7, over 7 on 9% > > > - Vamsi-klu: typical 6, busy 13, over 7 on 45% > > > - Andrushika: typical 7, busy 11, over 7 on 48% > > > - yuseok89: typical 4, busy 10, over 7 on 18% > > > - steveahnahn: typical 2, busy 10, over 7 on 20% > > > - ColtenOuO: typical 5, busy 25, over 7 on 40% > > > - stephen-bracken: typical 1, busy 6, over 7 on 1% > > > - fat-catTW: typical 5, busy 17, over 7 on 42% > > > > > > With a cap of 7, about half of the group would be at or above the limit > > on > > > roughly 4 days in 10. > > > I am not raising this to argue for a higher number; completely fine > > > starting at 7 for the reason above. Just want it on record, so that if > we > > > revisit the number later we have a baseline. > > > > > > On a related note, I like Henry's trust list idea (the bypass list > Damian > > > mentioned). > > > The numbers above show that the number of good contributors (I assume > > that > > > is group A mentioned above) that would need it is small, so the bypass > > list > > > should be easy to maintain. > > > If we agree it is the right direction, I can look into the .asf.yaml > > side. > > > > > > > > > Thanks, > > > Andrew > > > > > >
