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.)
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.