Why GitHub Is Adding Guardrails to the PR Queue
Open-source contribution volume has exploded in recent years. Creating a pull request takes seconds; reviewing one still takes a human, well, human time. When solid work and rough drafts land in the same queue, the signal gets buried. That imbalance is the driver behind a new feature: pull request limits for GitHub repositories.
The core mechanic is simple. As a repository admin, you can set a maximum number of open pull requests allowed at once from users without write access. Once a contributor hits that cap, they must close or merge an existing PR before opening another. Notably, draft pull requests don't count toward the limit, and AI-generated pull requests—such as those from Copilot—do.
For trusted contributors who shouldn't be gated, GitHub provides a bypass list. Being on this list exempts a user from the limit but doesn’t grant full contributor access. This addresses a gap maintainers have long flagged: GitHub’s existing interaction limits are temporary cooldowns, whereas these new limits are persistent and configurable at the repository level.
Beyond simple queue control, the cap nudges contributor behavior. When openings are unlimited, a polished change and a rough sketch carry the same weight in the list. With a limited number of open PR slots, contributors must prioritize which of their changes merit maintainer attention. That pre-submission vetting reduces the noise before it reaches reviewers, making the path to good work clearer and the act of reviewing less burdensome.
It’s helped us want to review pull requests again. Knowing that someone hasn’t just opened 5–10 pull requests that are slop makes it much easier to want to look. Going forward we expect it to help us manage our backlog and ensure the things people are working on are the things we need.
Nicholas Tindle, AutoGPT
This feature is great. We’ve had problems on Homebrew for a while with enthusiastic users submitting many pull requests that need near identical review. AI further accelerated it. This allows us to still have outside contribution and maintainers contribute more while gating users to a level of pull requests we can cope with.
Mike McQuaid, Homebrew
The Ecosystem Shift Beneath the Backlog
The timing of this feature tracks a major shift in development volume. In January 2023, developers merged about 25 million pull requests monthly across GitHub. Today, that figure exceeds 90 million—a roughly 3.6x increase. The surge is not purely a matter of scale; it also reflects an influx of well-intentioned contributors whose volume can outpace a volunteer maintainer’s capacity to respond.
GitHub has referred to this dynamic as an "Eternal September" for open source, a nod to a moment when an overwhelming influx of newcomers permanently changes a community’s character. The pull request limit is designed to give maintainers a measure of control without shutting the door on those contributors entirely.
What’s Next for Contribution Management
Pull request limits are the first piece of a larger roadmap aimed at giving maintainers more granular, flexible control over how work flows into their projects.
Archiving pull requests is expected to ship soon. Repository admins will be able to archive low-quality or spammy PRs, moving them out of the main view but keeping them accessible for admins. Archive is deliberately favored over deletion in many cases—some organizations have legal or compliance requirements that prevent permanent erasure, and maintainers may want to retain context for future discussion.
Issue limits are in active development. This would apply the same logic used for pull requests to issues: per-repository caps on open issues from users without write access, a bypass list option, and a way to restrict issue creation to collaborators only. The goal is to bring the PR queue’s newfound calm to the issue tracker.
Smarter bypass signals are next on the list. The ambition is to move beyond manual trust lists. Instead of hand-curating who gets exempted, a contributor could clear a limit automatically based on criteria like having a previously merged pull request in that repository, account age, or organization membership. This would reduce the overhead of list maintenance and free maintainers for review work.
Cross-repository controls are under exploration. A per-repo cap handles repeat offenses in a single project but doesn’t stop contributors who open PRs across hundreds of repositories at once. GitHub is evaluating approaches—trust signals, rate limiting, or other global controls—to catch that kind of cross-project activity.
The new pull request limits are available in repository settings today. GitHub is soliciting feedback on where the feature works and where it doesn't as it iterates on the broader contribution management toolkit.
