Configure pull request limit for users without write access

The open pull request count on nodejs/node has grown beyond 1000+. A portion of these are from individual contributors who have a high number of open PRs at the same time, which places demands on finite collaborator review capacity.

GitHub provides a setting to limit the number of open pull requests from users without write access. This helps balance the need for open contribution with the reality of limited human review resources.

Proposal

Should we set a pull request limit for users without write access?

This idea was discussed among collaborators, and 5 was suggested as a reasonable starting point.
We'd like to hear broader community input before making a decision.

Rationale

Every open PR requires collaborator time for review, feedback, and follow-up. A high volume of open PRs from a single contributor can reduce the time available to review contributions from others.
With the rise of AI-assisted tooling, it is now easier than ever to generate pull requests at a higher frequency, which can outpace the capacity of human reviewers.
A limit encourages contributors to prioritize their most impactful changes and work with collaborators to get existing PRs merged or closed before opening new ones.
It also serves as a backstop against automated spamming attacks that open multiple PRs.
Contributors who are consistently engaged at a level that requires more open PRs would be candidates for collaborator status, which is not subject to the limit.

Notes

The limit applies only to users without write access. Collaborators are not affected.
We can start with 5 (or some other number based on consensus) and re-evaluate based on feedback.
GitHub also provides a "bypass list" but we propose not using it to avoid the overhead of managing additions and removals.

FWIW here's the evolution of number of open PRs on nodejs/node:

I've implemented the 30 PR limits for Node.js due to a pressing need. We can revise it in the next meeting.

I'd be happy with half that.

@mcollina

Thanks @mcollina - I appreciate the bias for action here - there were calls for the moderation team to have some say in implementing that limit, which I think is inappropriate unless this is a new written part of the team's scope.

The value was set to 30 as an immediate response for moderation in #1084 (comment)

This issue has a tsc-agenda, so it's likely going to be discussed during the TSC Meeting on 2026-08-19.
If any TSC member reads this message before the meeting, consider lowering the limit to 10 to align with the documentation.

We discussed it briefly on today's TSC call. We didn't have a quorum to make a decision today. I have shared my thoughts on this, but it needs to be discussed:

Set the limit to 10
nodejs/collaborators should not fall under this policy
We should have a separate action that would close (even draft PRs) that pass the limit (from people outside nodejs/collaborators).

These are my thoughts on this, not the TSC discussion result.

Thanks for getting the limit set to 10 in the GitHub UI, so that is now consistent!

We should have a separate action that would close (even draft PRs) that pass the limit (from people outside nodejs/collaborators).

If it is possible to enforce a limit using tools prepared by Node.js, there is another limit implied by https://github.com/nodejs/node/blob/main/doc/contributing/first-contributions.md#what-not-to-do-for-your-first-contributions which says for First-time contributors:

Refrain from opening new Pull Requests before the first one has been approved.

Setting such a limit is not an option available from GitHub, and it may be better to handle it under a different topic. It is however all part of ensuring that reviewer capacity can focus on meaningful work, and not get distracted, overworked and overwhelmed by high volumes.

In the TSC meeting we are proposing 5 as a limit. If there are no objections, we will set this up next week. We will apply this org-wide.

I just listened to the TSC Meeting where this issue was discussed.

Since this limit is org-wide, i.e. applies across all repos in the nodejs org, I think 5 might be too low.
I would prefer it to be 10 to start with, and we can later reduce to 5 if needed.

In the TSC meeting we are proposing 5 as a limit. If there are no objections, we will set this up next week. We will apply this org-wide.

Since this limit is org-wide, i.e. applies across all repos in the nodejs org, I think 5 might be too low. I would prefer it to be 10 to start with, and we can later reduce to 5 if needed.

According to the screenshot on https://github.blog/changelog/2026-08-06-set-pull-request-limits-at-the-organization-level/ the org level limit overrides any individual settings, thus removing the ability to make any individual adjustments.

For this reason it may be less disruptive to set a limit only on nodejs/node instead of at the org level.

Continually moving the limits would be organizationally confusing. The limit needs to settle down so that everybody can adjust their work accordingly.

I believe that a limit of 5 PRs is a good choice for queue stability on nodejs/node and for focusing on important changes.

I also listened to the TSC recording, and it didn't seem that there was really an in-depth discussion of the impact of an org-wide setting.

Here's an updated version of the graph, the trend is still worryingly on the rise:

Another topic we are likely going to need to address: the inflation of commits is getting out of control, which is making releaser job harder and harder. Node.js 26 is already an obvious outlier:

That's obviously not just "users without write access" problem, many of those commits are coming from existing contributors. That increase of PRs seems to be correlated to a decrease of the number of reviewers per commit:

Another adjacent topic is that CI is getting overwhelmed:

there are more PRs to test than ever
the time it takes to run our test suites is getting larger and larger (On my machine, make jstest -j16 takes ~6min on v24.x-staging. On main, the same command takes more than 12min).

@aduh95

@aduh95

Thank you very much for providing the graphic displays! They make it clear that the incoming rate of new PRs is increasingly unmanageable, even just from June 2026 to August 2026, given that the resource pool of collaborators / triagers available to do reviews has stayed the same size. I wonder if the reduction to 5 open PRs is going to be enough, or if it needs to be reduced even further?

the time it takes to run our test suites is getting larger and larger (On my machine, make jstest -j16 takes ~6min on v24.x-staging. On main, the same command takes more than 12min).

I remarked recently to a colleague that we're now running more than 6000 Javascript tests for main. For v22.x that's in the 4000s.

I'm opening a PR to document the lowering of the limit to 10 for Node.js core

I'm opening a PR to document the lowering of the limit to 10 for Node.js core

You already did x) nodejs/node#65250

GitHub changelog announced Draft pull requests count toward pull request limits Oct 8, 2026 as an optional setting.

Draft pull requests count toward pull request limits

I haven't seen any user posting draft PRs to cheat the PR limit on Node.js core.
But we should enable it to avoid future draft PRs, while retaining the current limit.

Navigation Menu

Repository navigation

Configure pull request limit for users without write access #1084

Proposal

Rationale

Notes

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Configure pull request limit for users without write access #1084

Description

Proposal

Rationale

Notes

Activity

aduh95 commented on Aug 7, 2026

mcollina commented on Aug 8, 2026

jasnell commented on Aug 8, 2026

bmuenzenmeyer commented on Aug 8, 2026

MikeMcC399 commented on Aug 15, 2026

trivikr commented on Aug 18, 2026

MikeMcC399 commented on Aug 18, 2026

RafaelGSS commented on Aug 19, 2026

MikeMcC399 commented on Aug 19, 2026

MikeMcC399 commented on Aug 19, 2026

mcollina commented on Sep 2, 2026

trivikr commented on Sep 2, 2026

MikeMcC399 commented on Sep 3, 2026

aduh95 commented on Sep 8, 2026

MikeMcC399 commented on Sep 8, 2026

richardlau commented on Sep 8, 2026

mcollina commented on Sep 16, 2026

aduh95 commented on Sep 16, 2026

MikeMcC399 commented on Oct 9, 2026

trivikr commented on Oct 9, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions