GitHub Community
New release: new repository settings to configure pull request access #187038
Replies: 9 comments 17 replies
-
|
The fact that this new feature on GitHub is so anti-OSS that there isn't enough words to explain how backwards this is. Let's be honest, this feature only rolled out because maintainers (whose job is to triage PRs and Issues) can't and don't want to deal with their responsibilities with maintaining their repo. While we do live in a world with AI Agents, I think this feature steps over the line and takes it a bit too far. As it not only gatekeeps new members from contributing to Open Source Software, but it further perpetuates an already gatekept culture of software development. I would call on GitHub to find a middle ground of detecting when an AI Agent creates a PR and allow Repo Owners to block that instead of a broad global block. |
Beta Was this translation helpful? Give feedback.
-
If honesty is truly what's wanted: I'm extremely disappointed that the first comment here seems to be an ill-informed complaint. The information below might help to paint a picture, for people who are not aware of the gamut of opinions over the past decade: |
Beta Was this translation helpful? Give feedback.
-
|
It seems obvious we have 2 different definitions of the word "job", meaning task or responsibility of work, and "gatekeep" meaning acting as a filter for what is and isn't allowed. For the sake of ending this conversation, we can agree to disagree without implying that people are self entitled to someone's software. All I stated was that this feature would further gatekeep future contributors who want to contribute to the original repo. Not a fork. You and the folks on this thread would probably retort with, if you can't contribute to the original repo because of being gatekept, why not just make a fork and do it their own way? But that's not the point I'm trying to make and proves once again why the open source community isn't so truly open. That's all I have to say about this matter. |
Beta Was this translation helpful? Give feedback.
-
|
This feature is just a tool. It does nothing by itself. The choice to accept outside contributions or not has always been the decision of a project's maintainers. I understand the point that you are trying to make. You are misunderstanding what open source maintainers 'owe' you from their projects. They don't 'owe' you having to accept your PRs. Again, this feature is just a tool that helps maintainers who already wouldn't have accepted PRs. It does not force any projects to stop accepting PRs. If you don't like the implication that you are acting entitled to someone else's work then don't make accusations that the community is not 'truly open' just because a project won't accept PRs. |
Beta Was this translation helpful? Give feedback.
-
Ok you clearly don't get it and you never will 😄 |
Beta Was this translation helpful? Give feedback.
-
|
@Wayne-Jones I haven't managed to stay on-board as a maintainer in many open source projects for a long duration of time, despite sometimes being granted those privileges, because I begin stressing a lot about whether contributions are genuine -- and, conversely, whether I'm being unfair to what I think is an AI contributor, when actually it's a human -- whether there might be important bugs that I didn't notice (regardless of human/AI), and so on. Partly I also have problems believing that I am welcome in any particular community.. but neither of those is the only factor involved. People are free to copy, run, learn from and adapt open source software -- but that doesn't mean that the authors/maintainers have any duty to read and accept any mixture of inbound problems or suggestions in return; maybe they had a bad time with some of those and want to pause until they unpick that, or they'd prefer simply to continue on developing it on their own. I think that's OK, and that these changes help make those options possible. |
Beta Was this translation helpful? Give feedback.
-
Are there any plans to roll out a modified version of this? Been thinking something like an allow list would be helpful - not just collaborators but anyone who's commented in the issue such that we have some confidence that their PR isn't (going to be) spam. I guess I'm asking for a modification of the "allow folks assigned to issues" request, but this would give space for prs not attached to issues/folks we know through other comms channels. |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
@story645 yes! we're looking into releasing some additional settings so maintainer have more granularity over who can make contributions |
Beta Was this translation helpful? Give feedback.
-
|
Giving me the choice to disable completely any setting I did not want was always on my wishlist. I knew I could disable Issues and Wikis. I never thought GitHub would let me disable PRs. Yet the unthinkable happened. Now my wishlist is complete. Thank you! |
Beta Was this translation helpful? Give feedback.
-
|
Very glad to hear that @0xMF ! |
Beta Was this translation helpful? Give feedback.
-
|
I would like to see a setting to disable Copilot globally on GitHub. |
Beta Was this translation helpful? Give feedback.
-
|
It seems like a vuvuzela problem. To explain: people want to participate in the action (supporting their sports teams, or contributing to open source projects). To be more likely to be heard/involved, they'll accept or bring ways to amplify their voice (the vuvuzela, or a generative AI code agent). Some brands with plenty of funds are willing to provide free amplifying support at a loss, because they want their vuvuzela to be the one that is most audible during the sport/broadcast (or an AI agent in commit logs, or comments). Unfortunately, too many free vuvuzelas in the stadium cases an incredibly unpleasant experience for everyone. The analogy to the repository settings here is that some stadiums can choose not to allow people in to observe the game at all -- without altering the policy on vuvuzela usage within the stadium. I think a more practical solution is generally to disallow vuvuzelas. The sports teams (the project maintainers and developers) shouldn't have to be the ones enforcing that, it should stadium policy (repository settings). However, the stadiums here aren't independent - they all have to work within the policy options provided by the governing body (GitHub). |
Beta Was this translation helpful? Give feedback.
-
|
In the case where would-be contributors are restricted by these settings, I'd anticipate that they will be able to continue to create forks of the source repositories on GitHub and to work on features in their own branches -- it's only the pull request step in the source repo that these settings adjust. I'll need to think about this more (and I imagine GitHub staff has already discussed this), but I'd hope that additional ways to discover and surface useful contributions (and contributors!) from the network/forks of repos might emerge in future (I'd imagine this is something that advanced projects/maintainers may already look for). |
Beta Was this translation helpful? Give feedback.
-
|
@jayaddison confirming users will still be able to create forks of repositories even if PRs are disabled in that repository.
We're looking into a bunch of different approaches that we could implement down the line. Please share any thoughts that come to mind! |
Beta Was this translation helpful? Give feedback.
-
|
Excellent! Thank you. Can we please now also add the ability to limit the opening of new issues to collaborators only? It would really help cut down on AI slop burnout. I know I can disable issues entirely, but projects still need to track issues. People should still be able to see issues, but just not participate. |
Beta Was this translation helpful? Give feedback.
-
|
@moraesc how does "Restrict Pull Requests to Collaborators" relate to bots like Dependabot? Do we have to invite Dependabot to be a collaborator on those repos? |
Beta Was this translation helpful? Give feedback.
-
|
@br3ndonland Dependabot can still create PRs if PRs are restricted to collaborators only. It's technically considered a collaborator since it has write access to the repo |
Beta Was this translation helpful? Give feedback.
-
|
Any chance to add |
Beta Was this translation helpful? Give feedback.
-
|
@beutlich , it should be available on the repository endpoint under |
Beta Was this translation helpful? Give feedback.
-
|
Neither the sample response nor the documentation mention it at https://docs.github.com/en/rest/repos/repos?apiVersion=2022-11-28#get-a-repository |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Today, we’re introducing two new repository settings that give maintainers greater control over how their projects accept contributions: the ability to disable pull requests entirely, and the option to restrict pull requests to collaborators only.
Open Source is not One-Size-Fits-All
Maintainers are at the heart of GitHub’s ecosystem. You shape your communities, your project’s scope and technical direction, and define what processes contributors should follow. For years, we’ve operated on a default assumption that if a repository is public, it should accept pull requests from anyone. But that’s not how all projects work. Some projects want to share code without managing contributions. Others need to restrict collaboration during critical development phases. Many repositories, like mirrors or read-only reference implementations, simply have no need for pull requests at all.
More granular pull request permissions have been one of our most consistently requested features, and that need has become more urgent as the nature of contributions has evolved. We're committed to supporting maintainers and open source projects of all types, and we're excited to deliver these foundational tools to the community.
What’s New
1. Disable pull requests entirely
Just like you can with issues, wikis, projects, and discussions, maintainers can now turn off pull requests completely from your repository's Settings.
When disabled, the pull requests tab will be not be visible. This means no one can see existing pull requests or open new ones.
2. Restrict Pull Requests to Collaborators
When enabled, the pull requests tab remains visible. All pull requests can be seen, but only collaborators (users with write access) can create new ones. Collaborators can be added or removed by going to the Collaborators tab in a repository’s Settings.
What’s Next
As the open source landscape evolves, we’re committed to evolving our tools to ensure that the important work of open source maintainers remains enjoyable and sustainable. To learn more about some of the ideas we’re exploring, check out our latest blog post.
For teams that need highly customized contribution policies today, Agentic Workflows, a research project from GitHub Next, are designed to enforce virtually any project-specific rules you define. While this approach requires more technical setup and comes with usage costs, it provides significant flexibility. You can explore example workflows here.
Your Feedback Shapes our Roadmap
We’re extremely grateful for the feedback we’ve received from the community. The discussion threads, feature requests, and conversations with maintainers have been instrumental in helping us understand what to build and why it matters.
Now, we’d love to hear how these settings work for your project in practice, what challenges remain, and what additional controls would make managing pull requests easier. Your input will inform our next steps and ensure we’re building the right tools to address your needs.
Thank you so much for your collaboration and helping us improve the open source community on GitHub.
Beta Was this translation helpful? Give feedback.
All reactions