GitHub Community
New release: new repository settings to configure pull request access #187038
Replies: 3 comments 6 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.
-
OSS has nothing to do with accepting pull requests or not, it is purely about licensing with an OSI-approved license. It's about the license, not the workflow.
The vast majority of OSS maintainers are not employed to do it; in other words it's quite literally not their job.
Not at all. New contributors can, as always, continue to start their own projects and fork existing projects to build up their skills and experience. They don't, and never did, need to have PRs merged into others' repos to do that.
Not accepting PRs is not 'gatekeeping' by any reasonable definition. Many repos today already don't accept PRs, they just have to manually close them or set up bots to do it. This much-awaited feature is just making it easier.
It's not reasonable to make people wait for GitHub to solve the 'Turing Test' problem to disable PRs, and in fact for many it's not even relevant as they simply don't accept PRs via GitHub (AI or not), eg the Linux kernel. |
Beta Was this translation helpful? Give feedback.
-
|
I came here from a link in an A11y Slack post and I have open-source projects. I have no issue with the new feature; it is just that - a feature you can choose to use or not. My new project deals with accessibility and I make no claims about being an expert; in fact, I am merely a beginner in this domain, but I fully research and manually test everything I do prior to release. I was a little concerned about the PR aspect, given that if someone makes a request, the time I would need to fully vet it, not the code, but the accessibility implications could be enormous, which would likely hinder the overall progress of the project. I think having this feature, which I may enable so that PRs only come from like-minded developers who I know would have fully tested for accessibility (which is more manual than automatic), is a win for the community overall. I completely understand your points and respect them, but from my perspective, I am comfortable with this feature. Paul |
Beta Was this translation helpful? Give feedback.
-
I never said they were employed. But it is their role as maintainers to manage the software they produce which includes triaging issues and pull requests.
What is a contributor if they can't contribute to the original open source repo? Please explain.
It is very much the definition of gatekeeping. |
Beta Was this translation helpful? Give feedback.
-
You quite literally said 'job'. 'Job' means 'employment'.
You don't get to define the role of maintainers for others. That's up to them.
Someone who contributes. Contributing has nothing to do with the original repo. Are people who maintain, eg, Linux kernel forks not contributors? That would be absurd.
If someone doesn't let you enter their house, they are quite literally gatekeeping. But you have no right to enter their house in the first place. So the idea of using 'gatekeeping' as a criticism in this context is absurd in itself. You have no right nor expectation of pushing contributions into others' projects in the first place. The fact that this needs to be explained to you, is an indication that there is a deep malaise of entitlement in the open source world. |
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.
-
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.
-
|
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.
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