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]
