Just Say No
I need to read through this more thoroughly, but upon a first read, I feel I pretty strongly disagree with the approach and advice but not necessarily the sentiment.<p>This is mainly coming from a user of open source projects who is both trying to contribute more and start projects where I&#x27;d be the maintainer. As a user, I can&#x27;t think of anything more frustrating to spend hours or even days on an issue on an open source project that &quot;welcomes&quot; issues and contributions and then creating a detailed GitHub Issue only for it to be responded with with author&#x27;s &quot;No&quot; and immediately closed. Just because the maintainers do not have time to fix the issue does not mean it isn&#x27;t an issue! Too many times has this happened. It just means that users get a false sense of the tool&#x27;s maintainability, reliability, etc. by looking at a &quot;clean&quot; issue listing only to find out that tons of issues still exist. How many times have you found an issue only to find several issues have already been reported, not fixed, but closed due to automated bots or maintainers just blindly closing? The issue still exists, but now its history is spread across a half dozen issue reports. This complicates what the issue actually is and contributions for it.<p>The response to an issue of &quot;contributions are welcome&quot; or &quot;you can fork it&quot; are inappropriate because the filing of an issue is not a request to fix. It is an issue reporting mechanism. But too often, maintainers become chippy about reported issues.<p>On another note, many maintainers will report how much of an open source developer they are on their resume or talks they give, when in reality their open source projects are just that, open source. They are often just open sourced personal fiefdoms. Which is honestly fine, if they are marketed as such, but they rarely are so.<p>As I think about possibly open sourcing a personal project or two, I am thinking deeply about this. I think it&#x27;s much better for expectations that if an open source project is going to be dictated by the maintainer, it should be explicitly stated so as to set expectations. Even then, I would not blindly close actual issues that are reported.<p>Saying no is fine but please be honest and upfront on a repository&#x27;s README. If someone says &quot;this is open source but it&#x27;s mainly a personal project and&#x2F;or library and I will aggressively close issues&quot;, then that does wonders to set expectations. And I think that&#x27;s the key idea. Setting expectations, upfront, is the key to effective communication.