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