I think the proposal makes sense. In particular, I think Jarek’s point quoted below especially true:
“ *We also need to adapt to the reality where generating code is fast andcheap, meaning a submitted PR no longer guarantees that someone understandsAirflow or is genuinely invested.*” To that point: in my experience (anecdotal), I’ve noticed in the past 6 months there’s a large shift in focus for contributors of any project - Airflow or otherwise - towards adding shiny new features. That is not necessarily a bad thing, but IMO the increase in “fun feature” PRs tends to increase the projects’ complexity while making it more difficult for maintainers to review important maintenance/stability contributions. As a contributor (non-committer + non-maintainer), I don’t have any issue with the PR limit. I cannot imagine the current status quo is sustainable from a maintainer’s perspective, and yet somehow you all have remained by far the most responsive and thorough maintainers of any open source project I’ve worked on. To me it seems like PR limits are the least gate-keeping, most practical solution. On Wed, Sep 23, 2026 at 6:39 AM Jarek Potiuk <[email protected]> wrote: > For now - it looks like we are heading towards consensus, and 5 is the most > popular choice. > > On Tue, Sep 22, 2026 at 12:15 PM Jarek Potiuk <[email protected]> wrote: > > > > You can still create the branches in your fork, you just can’t hit the > > “create PR” button yet. > > > > And when we implement "CI in your fork" - you will even get CI run on > that > > branch. > > > > On Tue, Sep 22, 2026 at 12:11 PM Ash Berlin-Taylor <[email protected]> > wrote: > > > >> I would say +1 to this at a limit of 5. > >> > >> Yes, that might affect one or two contributors, but as Christos said, > the > >> current bottle neck is getting PRs reviewed and merged, so opening more > PRs > >> doesn’t really do anything to help you get things merged quicker. > >> > >> You can still create the branches in your fork, you just can’t hit the > >> “create PR” button yet. > >> > >> And then once the .asf.yaml exclude lands then each contributor could > >> make a case of why they should be added to the cap bypass list. > >> > >> -ash > >> > >> > On 22 Sep 2026, at 08:49, Jarek Potiuk <[email protected]> wrote: > >> > > >> >> GitHub already has a bypass list for the cap, so I opened a draft in > >> >> infrastructure-asfyaml to make it configurable: > >> >> github.com/apache/infrastructure-asfyaml/pull/135 > >> > > >> > COOL! I ran it through my "sandbox-test" SKILL and it looks great - > all > >> > checks out, and all edge cases pass. There is only one nit: checking > if > >> the > >> > login is a GitHub account. One unknown login discards the whole batch, > >> so > >> > it would be worth checking the logins before calling the API. Comment > >> > posted: > >> > > >> > https://github.com/apache/infrastructure-asfyaml/pull/135#issuecomment-5772952423 > >> > > >> > J. > >> > > >> > > >> > On Tue, Sep 22, 2026 at 9:14 AM Andrew Chang <[email protected]> > >> wrote: > >> > > >> >> Thanks Jarek. I agree that trust should come with responsibility. > >> >> > >> >> I looked into collaborators' role. Seems like they only get triage, > not > >> >> write access, so the cap still applies to them. > >> >> And the collaborators list has a hard limit of 10 per repo (ASF > >> policy), > >> >> which Airflow already uses up. Still, I think reusing collaborators > is > >> a > >> >> good starting point. > >> >> > >> >> GitHub already has a bypass list for the cap, so I opened a draft in > >> >> infrastructure-asfyaml to make it configurable: > >> >> github.com/apache/infrastructure-asfyaml/pull/135 > >> >> > >> >> Or we could simply sync the bypass list with the collaborators list > >> >> automatically. It would be easier to maintain, though the > collaborators > >> >> list would then need to be revisited more often. > >> >> > >> >> This could be a way to recognise people who review and help others. > >> >> Not sure this is the right direction, but wanted to have something > >> concrete > >> >> to look at. Looking forward to hearing your thoughts. > >> >> > >> >> Thanks, > >> >> Andrew > >> >> > >> >> Yuseok Jo <[email protected]> 於 2026年9月22日週二 下午2:25寫道： > >> >> > >> >>> 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 > >> >>>>> > >> >>>> > >> >>> > >> >> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> >
