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 > > >
