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