I don’t find anything wrong with the authors approach. I just think he should make it clear that he’s not interested in issues or PRs on the project readme or contribution guide. It’s hard to have it both ways - where you say issues and PRs are welcome but say no when someone reports or makes a contribution.
I agree that making it clear is important, and I think I edited my post at the same time as your comment to say the same.
However, I think I still disagree with closing issues, particularly with a bot, even if expectations are set. On GitHub, I think labeling the issue is more appropriate. Labeling it as "maintainer-wont-fix-contributions-welcome" with a detailed "I will only accept a PR if these conditions are met" in the README is much better than just swatting away things by closing and saying "won't fix" or "this is not a bug". If PRs and issues truly will be ignored, then that really needs to be explicitly stated. Because otherwise, why even open source or release it? I have seen quite a few presentations with "I maintain all these projects" instead of the truth of "I open sourced all of these personal projects". There is a difference.
Society generally disagrees that unclear or unresponsive communication is welcomed. If someone speaks to me, I believe giving and them expecting a respectful response is not entitlement on their part.
> Because they can.
That's not really an answer to basically any question. Yes, a person can do anything, but actions also have consequences. Also, frustration is a legitimate emotion for anyone. It's okay for someone to be frustrated and admit so in a respectful manner. Being frustrated does not make one an evil or entitled person by default.
Lastly, there are different approaches and perspectives, which is also fine. For open source development, there is no one true approach that everyone is going to agree with. But I do think clear communication will reduce a lot of friction no matter the approach.
I once came across a project where the maintainer clearly stated that they will never adjust the license. Is it frustrating? Yes. Do I disagree? Yes. But it's their choice, and they clearly stated it. So I grunt to myself and move on.
> Society generally disagrees that unclear or unresponsive communication is welcomed. If someone speaks to me, I believe giving and them expecting a respectful response is not entitlement on their part.
That only works because meatspace limits the number of people who can impinge on your time.
That's not true for Github. Any maintainer is heavily outnumbered by the number of people who can file issues against their project.
I blame the fact that we centralized bug reporting. Back when everybody had to create an account on a different Bugzilla, there was enough friction that you had to want to file that bug report very badly--especially if there was a 24 hour waiting period to sign up. That kept the ratio under control so the maintainers weren't too outnumbered.
(Side note: I suspect there is also some level of "Filing bug reports on Github is a corporate metric" somewhere also creating extra static.)
The amount of people who read through a README is probably in the single digit percentage of users who post issues (judging by the fact that so many issues have their resolution in part of the README).
The number of people (especially those who post issues, not PRs necessarily) who read a contribution guide is probably less than 1%.
GitHub issue templates can help in that regard, but it's still pretty minimal the amount of work 80% of people who post issues will put in towards solving it themselves first.
Normally if the README contains the restrictions on contribution and PRs right at the top I think it should catch everyone’s attention (well, hopefully…).
IMHO, the ideal solution is for GitHub to allow restrictions on issues and PRs for public repositories. You could always make the repo private though. I don’t think there is a restriction on private repo’s right now in GitHub.
