Disable pull requests while keeping issues for a repository
cirosantilli opened this issue · 9 comments
Under settings, you can disable issues.
Also allow disabling only pull requests but not issues for projects that prefer other review mechanisms like Gerrit, but still want the GH issue tracker.
Related: dear-github/dear-github#84
Edit: reply:
Hi Ciro,Thanks for writing in! We've definitely heard some users requesting this feature over the last couple of years, and it's currently on our feature request list. I can't make any promises about if or when we may add this ability in the future, but I'll add your +1 to that feature request so the team can see it.Please let us know if there's anything else we can do for you in the meantime!All the best,Nick@nickcannariatoGitHub
This is pretty much the standard meaningless reply from GitHub which I've seen with every feature request I've proposed - the request vanishes into their black box system and we have no clue when or even if it will ever be implemented.
For now it seems that a workaround is required. Here are a few options:
- Reuse OpenStack's script for auto-closing all PRs. They run it periodically from
cron. - Build a ProBot app to auto-close PRs (or if you can find an existing one, reuse it here and please share the link here!)
- Set up a pull request template which tells people not to submit PRs.
Of course you could combine the template approach with the auto-closer approach.
I've made a new app that immediately closes and locks new and existing issues or pull requests and also supports posting a comment and labeling. It is perfect for forks and mirrors, and you can configure it to your liking. Let me know how it works for you!
See the recent discussion on Hacker News that mentions this issue: https://news.ycombinator.com/item?id=25940195
One problem I see with this, is that it would prevent people to see/use patches other people made available through pull requests.
It happened to me in the past: a given bug fix or feature wasn't in master because the project was abandoned, but was available in a PR by someone that took the time to fix it. In these cases it's useful to have this code available so you can use in your own fork or patch locally.
I think it'd be better to just lock the ability of external contributors to open new pull requests, without making the existing ones unavailable, nor preventing official contributors to open new ones..
One problem I see with this, is that it would prevent people to see/use patches other people made available through pull requests.
It happened to me in the past: a given bug fix or feature wasn't in master because the project was abandoned, but was available in a PR by someone that took the time to fix it. In these cases it's useful to have this code available so you can use in your own fork or patch locally.
I think it'd be better to just lock the ability of external contributors to open new pull requests, without making the existing ones unavailable, nor preventing official contributors to open new ones..
I think that case is still handled if issues are open, and the person posts a link to their fork that fixes the issue.
GitHub is suffering from the choices GitHub made: https://github.com/github/dmca/blob/master/.github/pull_request_template.md
Their roadmap repo does actually seem to have PRs restricted to collaborators.
I went to a random fork and tried to create a PR and got this:
Maybe they plan on opening this toggle to everyone in the future?
They also have this enabled for creating issues (without disabling them):
@nihaals That's from "Interaction limits" in settings. But this also prevents users from making issues or even comments on issues. (Which could work for read-only mirrors on GitHub, but that's not the use case for this issue.)
I can see the interaction limits on one of my repos. I would love to have some more granular control with interaction limits, for example in my case I want to restrict pull requests but leave issues open.