Pull request limits for CPython repo

Core Development
,
1

We’ve set a limit for the maximum number of PRs you can open at python/cpython to 3, including drafts.

  • This does not affect members of the core or triage teams.

  • If you have more than 3 PRs already open, they stay open, but you won’t be able to open another before dropping below the limit.

We have done this following several recent incidents of bulk PR creation in a short amount of time, and we’re struggling to handle them. For example:

  • Today: 21 CPython PRs opened in a single two-hour burst across about 19 unrelated stdlib areas, as part of 177 template-written PRs sent to 13 repos in three weeks. Account banned by one project.

  • October: 19 CPython PRs opened plus 13 companion issues in a 20-minute burst across about 22 unrelated stdlib modules.

  • October: 7 CPython issues opened, then then 7 matching PRs within a single minute across unrelated modules, all 14 still untouched by a reviewer, from an account with 60 PRs spread over 18 repos.

  • September: 17 CPython PRs opened over three days across unrelated modules, as part of 225 PRs across ~50 repos.

  • September: A user whose profile boasts a “117 PRs merged upstream” badge, opened 6 CPython PRs in two hours against unrelated modules, as part of 487 PRs across ~40 repos, about half of those closed unmerged since August.

Yes, these do look LLM generated, and no, we don’t want to be the first humans to read that code.

(We also get mass issue reports, but unfortunately GitHub has no configurable limit for this.)

A reminder from our AI policy:

Authors must review the work done by AI tooling in detail to ensure it actually makes sense before proposing it as a PR or filing it as an issue.

We expect PR authors and those filing issues to be able to explain their proposed changes in their own words.

And:

Maintainers may close issues and PRs that are not useful or productive, without explanation, regardless of whether AI tools were used or not.

If a contributor repeatedly opens unproductive issues or PRs, they may be blocked from contributing to the project because it is disruptive and disrespectful of the maintainers time.

29 Likes
2

This is certainly a good decision. That said, at least in this latest case all PRs don’t seem to be slop. I noticed that one of them fixes an issue I had submitted, and based on a quick look on a mobile screen the fix looks good.

3

Yeah, some PRs by these particular contributors have already been merged. But the main thing is we can’t deal with this volume.

And thanks for reviewing that PR, it helps.

(Let’s avoid the term slop as there’s no settled definition: for some it means all LLM-generated content, for others only low-quality content.)

6 Likes
4

What about regular contributors (outside the triage / core team)? With a cap of 3 they can’t send new fixes, or even backports

5 Likes
5

Is there a mechanism to short term override when doing backports that require conflict resolution? I have 3 open right now just with having to have done manual backports to handle conflicts which was done so that the Core team didn’t have to do it.

I do agree with the general direction though as I also get waves of PRs from LLMs that are hard to keep up with.

1 Like
6

Things are still new, so nothing is set in stone. I get the feeling that we’re going to be pretty free with the exclusion list for known contributors, so I wouldn’t worry about it too much. Do mention to your reviewer if you’re having issues with the limit.

There are also further tweaks to the system apparently in development at GitHub that should hopefully improve things as well.

5 Likes