I've had tremendous success by removing the "Issues" tab on a couple of my more popular and beginner-friendly Github repos[1] and just leave the "Pull Requests" open! Support tickets have gone down to almost 0 (I still get the odd email from time to time, to which I promptly quote a price and never get an answer), and most who contribute actually give back value.
As Alex says in this blog post though "it typically derails into a whiny tirade about me being a crappy two bit developer". Luckily this only happened twice for me, but it's funny because in here you can see it on the open[2] as someone opening a PR adding this text to the README:
> If you spot a bug or any other issue you may go to hell because this software is officially Bug Free(TM).
On a very perverse way I am kind of happy that happened, since it ratified my decision and I became a lot more strict about when I help people. Any sense of "guilt" I had remaining after closing the Issues for not providing free support totally left after that incident.
While I feel bad that you had people treat you without respect, I don't think turning issues off is a sign of a serious project that should be used by many people in production (even if the project itself is nearly a work of art).
The recent example is Gitea which was forked by a community from Gogs because a single maintainer there was very picky about which issues to resolve, was refusing or taking very long to review PRs etc. I think both Gogs and Gitea coexisting is a very fine example of open-source working. But I think Gitea model is how a non-toy software is to be developed.
I often look at how many issues are labeled 'bug' before considering adding a new dependency to my project as well as check how many old issues are unresolved.
You don't have to resolve all open issues but closing an issue tracker the outright signals "I don't care if you have problems and I do not intend for this software to be maintained in any sense of collaborative fashion here on Github". Above all, such behaviour signals to me that there is only 1 person making commits / merging PRs and they are kind of tired of OSS (which is fine, by the way).
> While I feel bad that you had people treat you without respect, I don't think turning issues off is a sign of a serious project that should be used by many people in production (even if the project itself is nearly a work of art).
For some people, this is a good thing.
> You don't have to resolve all open issues but closing an issue tracker the outright signals "I don't care if you have problems and I do not intend for this software to be maintained in any sense of collaborative fashion here on Github". Above all, such behaviour signals to me that there is only 1 person making commits / merging PRs and they are kind of tired of OSS (which is fine, by the way).
I think it's more nuanced than that. It's perhaps more "I care if you have problems only if you have put in the effort to try and fix them. Then we can work together on getting it fixed for everyone".
"Issues closed, PRs welcome" is a perfectly reasonable way to run a healthy project.
Most projects on GitHub don't have a mailing list. Turning off issues makes it hard to tell if a project is in good shape. It prevents users who have relevant knowledge from helping users who don't.
Solving a problem together means agreeing on the problem and the solution before someone spends days working on it.
It's a trade-off, for sure. But it's on the project owner to make that call. It's not always the case that one model is best for any given project/maintainer/set of users.
As for project health, I treat the git log as a far more reliable indicator than the issues list. That shows me what's actually getting done.
> I don't think turning issues off is a sign of a serious project that should be used by many people in production
> Above all, such behaviour signals to me that there is only 1 person making commits / merging PRs and they are kind of tired of OSS (which is fine, by the way).
The linux kernel doesn't have an issue page and PRs receive a polite comment on how to send their PRs as patches outside of github.
Also, having a mailing list does mean to have a communication channel open and AWS SREs (for the sake of argument only) do not need to pay to join that mailing list and post some questions.
Finally, I think this one of the few instances where "You Are Not Google" fully applies.
You should at least mention your policy of not accepting any bug report/feature request in the "contributing" section of the readme. It's fair enough but at least say it, because it's not the norm.
As Alex says in this blog post though "it typically derails into a whiny tirade about me being a crappy two bit developer". Luckily this only happened twice for me, but it's funny because in here you can see it on the open[2] as someone opening a PR adding this text to the README:
> If you spot a bug or any other issue you may go to hell because this software is officially Bug Free(TM).
On a very perverse way I am kind of happy that happened, since it ratified my decision and I became a lot more strict about when I help people. Any sense of "guilt" I had remaining after closing the Issues for not providing free support totally left after that incident.
[1] https://github.com/franciscop/picnic
[2] https://github.com/franciscop/picnic/pull/203