🚀 New release for open source maintainers: Pull Request limits are now available

[moraesc]

Open source maintainers are dealing with a growing volume of contributions that existing workflows weren’t designed to handle. It’s become dramatically easier to generate pull requests, issues, comments, and bug reports, but the cost of reviewing them hasn’t gone down. We've been focused on building new tools to help maintainers better manage their incoming contributions at scale.

What's new

Today we’re introducing pull request limits for repositories.

With this new setting, maintainers can set a maximum number of open pull requests a non-collaborator can have at one time. Once someone reaches that limit, they’ll need to close or merge one of their existing PRs before opening another.

We’re also adding a bypass list, so trusted contributors can be exempt from the limit without needing full collaborator access.

For maintainers dealing with noisy or high-volume contribution patterns, this offers a more practical way to manage the flow of incoming PRs before the queue gets out of hand. And for repeat contributors who are working closely with a project, the bypass list gives maintainers a lighter-weight way to recognize trust.

What's next

This is just the first step and is one part of a broader effort to give maintainers more tools for handling contribution volume and protecting their time.

👉 For more context on what’s shipping now and what’s next, read the discussion post: https://github.com/orgs/community/discussions/197319

This is just the beginning - a full blog with even more details is coming soon. Stay tuned 👀

We'd love to hear from you

If you’re a maintainer dealing with a busy PR queue, we’d really love to hear from you. Leave a comment with any questions, let us know is this is helping in your repository, or share what else would make contribution management easier. This work came directly from maintainer feedback, and we’d love to keep learning from you as we keep improving these tools. 🙏

[apparentlymart]

This seems pretty great!

Out of curiosity: did you consider a variant which treats assignment to at least one issue as eligibility to open a PR?

I work in a repository where the process for community contributions is to first ask to be assigned to an issue and only then open a non-draft PR, but of course today we have to manage that process manually instead of it being built in to GitHub. Since we're already maintaining the assignments on issues as part of this process, it would be nice for the system to use that information as part of deciding eligibility to open a PR, instead of us having to separately maintain a bypass list.

(To be clear: I don't mean that this would imply that any PR opened by an assigned person would be required to be associated with the issue they were assigned to. Only that having at least one assignment to any issue in the repository makes it possible for the person to open any PRs in that same repository. It'd still be up to the maintainers to handle any requirement that the PR must be related to a previously-assigned issue.)

Thanks!

[moraesc]

@apparentlymart that makes a lot of sense. Just left a comment below explaining what we're thinking for next steps to make these settings more granular, and I think what you're suggesting could definitely fit within the realms of that:

@diofeher We can definitely look into that! We’re planning to add more granular limit controls so you can choose which users automatically bypass limits based on trust signals like account age, number of merged PRs in the repository, and organization status. We can also explore using issue assignment as an additional signal.

[diofeher]

Thanks for this feature!

Do you think it would be possible to add a similar setting that allows only users assigned to an issue to open a pull request?

[moraesc]

@diofeher We can definitely look into that! We’re planning to add more granular limit controls so you can choose which users automatically bypass limits based on trust signals like account age, number of merged PRs in the repository, and organization status. We can also explore using issue assignment as an additional signal.

[trueberryless]

First of all: Thank you very much for adding this feature. It is really appreciated 💚

May I ask why draft PRs do not count towards the new limitation? I'm generally curious in which case a user with non-write access should be allowed to open as many draft PRs as they want, but only a certain number can be active for review. In my opinion this still pollutes the PR list. While it is possible to only show "ready for review" PRs thanks to the amazing search functionality, it feels like this could be used as a workaround to keep creating low-quality PRs.

Thanks for any explanation in advance!

[moraesc]

Thank you for the feedback!

We chose not to count draft PRs toward the limit because maintainers can clearly identify drafts and easily filter them out of the main PR review flow. Given that, we didn’t think including drafts would address the primary pain point. Also, so far the feedback we’ve received has mostly been about limiting open PRs that are ready for review, rather than drafts specifically. That said, we're definitely open to revisiting this if feedback trends in a different direction.

[mdrxy]

Can the bypass list be managed programmatically?

[moraesc]

@mdrxy yep, you can update it through the API

[kannon92]

Hello. For Kubernetes we would really like this feature but we limit write access to very few. Is there a way to expand this to org members and allow this per org?