+1 for a PR limit of 5 I have observed many issues has 2 or more PRs (more than one ) and had same logic and same type of code one ex - https://github.com/apache/airflow/issues/68382 has 7 + PRs and maintainer (here ash) also tried to discussed it first but had many PRs and it will increase the burden on maintainers
I'd like to discuss this approach : when a new contributor opens a PR, the bot auto-converts it to draft and leaves a message asking them to first explain, in their own words, what they're changing and why it's needed. A maintainer then reviews that explanation and either approves or rejects it.In this way contributor also learn something new - main goal of conribution . If approved, the contributor is added to a trusted list - the list : contributors on this list can open PRs directly without needing to discuss first, since they've already shown they understand what they're doing. . New contributors not yet on the list keep going through the draft-and-explain step until the bot auto-undrafts their PR once approved (or a maintainer does it manually ) Yes maintainer have to spend time to review the discussion and have to approved but it will save time to review " only" human in loop PRs - close and review - maintain duplicate 2 or more and increase time to contributor aware PR One the ghostty has this type of vouch system - https://github.com/ghostty-org/ghostty/pull/8289 and doc : https://github.com/ghostty-org/ghostty/blob/main/AI_POLICY.md Would love to hear from the community ! On Wed, Sep 23, 2026 at 8:05 PM Sean Muth <[email protected]> wrote: > +1 for a PR limit at 5, with an exclusion list/override for folks that > makes sense for > > On Wed, Sep 23, 2026 at 8:05 AM Zach Gottesman via dev < > [email protected]> wrote: > > > 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] > > > >> > > > >> > > > > > >
