| > As a user, I can't think of anything more frustrating to spend hours or even days on an issue on an open source project that "welcomes" issues and contributions and then creating a detailed GitHub Issue only for it to be responded with with author's "No" and immediately closed. The article also discusses that. Of course there are better ways to do this than just closing it wihtout comment, even though the end result is still saying "no" to it. I have open-sourced a library that I wrote for an in-production app at work, and it got a little too popular for me to handle like most open source "consumers" (even though they don't pay me) expect. Every time there's a feature/pull request, I not only have to think about if the code is correct, but also if it would introduce breaking changes in the way it is used in that production app. It's very mentally draining to visit the issues page of that repository, because it's full of people needing help or wanting to contribute work. But I can't handle them all within an acceptable timespan. Every few months I take half an hour to clean up there, and then the issues list is already filled with disgruntled users. > The response to an issue of "contributions are welcome" or "you can fork it" 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. I agree in hindsight that it probably would've been better to just turn off the pull requests feature when creating a repository if you can't commit yourself to the potential workload it creates. > Saying no is fine but please be honest and upfront on a repository's README. If someone says "this is open source but it's mainly a personal project and/or library and I will aggressively close issues", then that does wonders to set expectations. And I think that's the key idea. Setting expectations, upfront, is the key to effective communication. Most of the time you don't realize that you really can't handle all that workload when you're still in the "honeymoon" phase of the thing you're open-sourcing. What are you supposed to do when it gets to the point where it's just overwhelming you to even look at the issues list? |
> The article also discusses that
They mention that but they don't really discuss it, and I disagree with the conclusion and advice.
GitHub allows disabling issues altogether. Just do that snd save everyone trouble.
> What are you supposed to do when it gets to the point where it's just overwhelming you to even look at the issues list?
My thoughts are my overall opinion and approach: clear communication. Just update the README, appropriately comment on issues that are closed as a result, and maybe even disable issues.