I agree with Sameer here, I think it’s somewhat brute-force to bucket folks into “committer” and “non-committer”, especially for folks who are actively engaged with the project (triage team members, etc.). I’d be more inclined to have more aggressive PR closure policies if there is no traction, etc.
Jake On Sep 21, 2026 at 1:43:19 PM, Sameer Mesiah <[email protected]> wrote: > 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-conversations/limiting-interactions-in-your-repository#limiting-concurrent-open-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. > > >
