> 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.
>From my experience and tests,- it's way better to ask agents for what we want before rather than verify it after. The thread that I started (with lazy consensus false start) "Human Summary section in agent-drafted PR descriptions" https://lists.apache.org/thread/5k06417wrbb10hkfk8ogz8py7qgcbpqz Does pretty much what you propose - byt BEFORE the PR is created. And it saves CI, time and effort for roundtrips, notifications about new PRs, etc. And even if **some** of those agentic contributions will not follow it - vast majority will. Over the last 4 months when I tested and tried different things (and I was learning how this whole agentic thing works) - I realized one thing - it took about a week, to get the agentic PRs to comply with what we asked them to do in our AGENTS.md and friends. Every single time I added a new expectation, week from then filtering about that expectation basically stopped working - because the expectations were fulfilled in most PRs. And it actually struck me how it works - when I tried to contribute to another project and my agent **actually** asked me to fill in the details by hand and refused to work without it. I could *of course* force it, but that was enough of a friction for me to pause, stop and actually "write" the description by hand. And my hypothesis is that most of those PRs and people behind them are not malicious at all. They just DO what we ask them to do. If we will ask them to write specicific paragraph by humans - vast majority of the cases humans who operate the agents will simply comply. I sincerely believe that most of the humanity is not evil or malicious, and my take from fighting with "AI Slop" so far is that most of those is not malicious either. There are plenty of well-meaning people out there, and they drive the majority of those issues. We just need to give them enough guardrails for them and their agents (for example limiting number of PRs and asking humans to provide a description upfront). I think we took a wrong approach in the past by treating those PRs as "malicious" and trying to "punish" those who drive it rather than incentivizing and inducing good behaviour as we understand it and need it. In a way - we were playing the reverse-centaur game [1]. We were driven by the AI rather than driving the AI ourselves. We need to get back and become centaurs. [1] https://doctorow.medium.com/https-pluralistic-net-2025-09-11-vulgar-thatcherism-there-is-an-alternative-f1428b42a8fd On Thu, Sep 24, 2026 at 4:32 AM Pratiksha Badheka < [email protected]> wrote: > +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] > > > > >> > > > > >> > > > > > > > > > >
