Repository navigation
Configure pull request limit for users without write access #1084
Description
Activity
FWIW here's the evolution of number of open PRs on nodejs/node:
Reacted by Trivikram Kamat and Ruy AdornoI've implemented the 30 PR limits for Node.js due to a pressing need. We can revise it in the next meeting.
Reacted by James M Snell, Sebastian Beltran, Trivikram Kamat, Brian Muenzenmeyer, jakecastelli, Ethan Arrowood, Chengzhong Wu, Aviv Keller, Gürgün Dayıoğlu and Carlos FuentesI'd be happy with half that.
Reacted by Ethan Arrowood and Chengzhong WuThanks @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.
- linked a pull request that will close this issuedoc: document open pull request limit #65250
on Aug 12, 2026 The value was set to
30as 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 to10to 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.
Reacted by Mike McCreadyThanks 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.
Reacted by Mike McCready, Trivikram Kamat, René and Jacob SmithI 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
nodejsorg, 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.Reacted by Jacob SmithIn 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
nodejsorg, 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 -j16takes ~6min onv24.x-staging. Onmain, the same command takes more than 12min).
Reacted by Jacob Smith, Gürgün Dayıoğlu and Sebastian BeltranReacted by Mike McCready, Brian Muenzenmeyer, Beth Griggs, Chengzhong Wu, Jacob Smith, Gürgün Dayıoğlu and Sebastian BeltranThank 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 -j16takes ~6min onv24.x-staging. Onmain, 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. Forv22.xthat's in the 4000s.- the time it takes to run our test suites is getting larger and larger (On my machine,
I'm opening a PR to document the lowering of the limit to 10 for Node.js core
Reacted by Trivikram KamatI'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.
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.
The open pull request count on
nodejs/nodehas 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
Notes