Comment by jerf
7 years ago
"(Yes, I am that maintainer with dozens of open PRs on his repo, none so bad they must be closed, but also not good enough to merge.)"
Go ahead and close them with notes that they can be re-opened if they come up to standards, but that you don't have the time or interest or capability to do it yourself, and that you are not judging them beyond this comment.
Closing a PR doesn't mean as much as people kinda think it does; they can be re-opened. Closing them without comment is harsh, but it correctly represents the current state of the world, which is that without changes, they aren't going in. Closing them with comment is the best compromise between all the issues.
As a maintainer, you need the "open PR" list to be a list of meaningful, actionable items. You don't have all that many tools to use, and the ones you do have need to be kept sharp. It's OK.
This. If you have 20 open PRs and all of them are old, they should be closed. Same for issues if they don't appear to have any resolution or are too stale.
If people keep asking for a feature that isn't ready, you can make an issue that depends on the PR that describes the acceptance criteria for the feature, and send them the link. Or you can edit the top of the PR description with the acceptance criteria/status so new people see it immediately.
A third option is to refuse issues and PRs entirely and just use mailing lists. Less people will ask for a feature because it takes a lot more work to dig through mailing lists, and by that time you've already found the thread and know why it isn't accepted yet.
On a technical level, I think this encourages the contributor to delete the branch, in which case it's gone for good and benefits no one.
If GitHub automatically saved a copy of each PR branch, I would be more receptive to this advice. This would potentially cause a lot of other problems...