I am a maintainer in multiple repos this is implemented, FYI IMO one big downside is that it doesn't limit the number of draft PRs users can open, or separately control, but something to be aware of as a workaround for when opening multiple PRs as a user without write access.
Also, I'm not sure how it will work for Airflow as a repo, but you can explicitly list users to exclude from this limit. Regards, Damian -----Original Message----- From: Sameer Mesiah <[email protected]> Sent: Monday, September 21, 2026 1:43 PM To: [email protected] Subject: Re: [LAZY CONSENSUS] Limiting number of opened pull requests for users without write access Hi, I completely understand the motivation behind imposing a limit on the number of open pull requests. Having a random account open 50 low quality PRs is a drain on maintainer’s time. But I really have to raise 2 objections here: 1) 5 is far too low of a limit. A lot of active non-committer contributors are likely to have significantly more than 5 PRs at any one point. You might counter and say that one could consolidate a body of work into a massive PR but then this increases the burden on maintainers as PRs with multi-thousand line diffs are much more tiresome to review. Maybe it’s possible that we could pull some statistics on AI spam attempts by specific accounts? My understanding that such attempts are not batches of 5 PRs but 25-50 PRs. I think we can refrain from setting a low number arbitrarily. 2) I think lumping all contributors without write access into one category is a bit unfair. Sure, a lot of occasional non-committer contributors won’t be affected by this but there is a sizeable cohort of regular non-committer contributors who might face unnecessary friction if they want to contribute broadly across the code base with many PRs open in parallel. These aren’t necessarily attempts to spam the project with AI slop but often some of their PRs might be awaiting review so they work on other things to keep themselves engaged. Perhaps we could consider only applying these limits to very new contributors but once they have proven they are genuine high value contributors, this limit could be removed? Of course, this will be at the discretion of the PMC who will have observed them for some time. I think we should be very careful with policies like this because they can affect contributor experience. Thanks. Sameer Mesiah. On Mon, 21 Sep 2026 at 18:04, Jarek Potiuk <[email protected]> wrote: > The .The .asfyaml PR that I created has been merged - after testing > with the workflow I contributed earlier to .asfyaml for infra to test changes. > > This thread calls for lazy consensus to enable this feature and > configure the limit to 5. > > https://github.com/apache/airflow/pull/73469 > > The feature in GH is described in > > > https://docs.github.com/en/communities/moderating-comments-and-convers > ations/limiting-interactions-in-your-repository#limiting-concurrent-op > en-pull-requests-for-users-without-write-access > > If others would like to use another value, I guess we can change it > without invalidating lazy consensus, I just think 5 is a reasonable > starting point and we can adapt as needed later. > > J. > ________________________________ Strike Technologies, LLC (“Strike”) is part of the GTS corporate family. Strike is a technology solutions provider, and is not a broker or dealer and does not engage in securities transactions. This communication does not constitute an offer to sell or the solicitation of an offer to buy any security in any jurisdiction.. ________________________________ CONFIDENTIALITY / PRIVILEGE NOTICE: This communication and any attachments are intended solely for the addressee. The information contained in this communication may be proprietary, privileged, confidential, and/or protected from unauthorized use or disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution, copying, or other use or disclosure of this information is strictly prohibited, and may be unlawful. If you have received this transmission in error, please delete this message and all copies from your system and notify the sender via return transmittal. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
