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