My friend Michael Jackson turned off github issues on one of his smaller projects. It got me thinking...
Maintainers getting burned out is a problem. Not just for the users of a project but the mental health of the maintainer. It's a big deal for both parties. Consumers want great tools, maintainers want to create them, but maintainers don't want to be L1 tech support, that's why they burn out and everybody suffers.
The solution is to get more people involved, but how? Some of us think that letting people open issues helps. I don't. Most issues opened are bogus: an incorrect module import, not knowing that promises swallow errors and incorrectly assuming it's the project's problem, or they're questions that are already answered in the README or docs.
This isn't a rigorous statistic, but I'm pretty sure these are 99% of the issues on Github.
Issues aren't creating contributors, and they aren't really helping the project's code either. You're either spending time closing bogus issues or you're trying to find other people to do it, either way it's not healthy for any of you.
What if we just turned off the issues tab?
Consider this: issues are for powerless customers. You open an issue with your software vendor because you don't have the power to fix the problem. But programmers, using open source, do.
Opening a Github issues doesn't require you to learn anything new, write any code, or even see the source code of the project. If we turn off issues, then the only feedback mechanism is a pull request. Let's explore the only use-cases I can think of for issues, and how they can be handled with pull requests.
Fork the repo, add a failing test. This will encourage devs to learn how to write tests, and in the process, maybe discover that the test passes and something is broken in their app.
Too early in your career to take on writing a test case? Add an
example in the repo that illustrates the bug. If you are able to write
enough code to think you've found a bug and open an issue, you are able
to open the examples/ directory of a project and make a new one that
shows the bug. You may, again, find that the bug is in your app, saving
the mental health of the maintainers from wild goose chases for bugs
that don't exist. Or, you'll make the pull request, the maintainer can
run your example and see "ah there is a bug" and then fix it.
Using issues for this doesn't give the developer any new experience and usually leads to the maintainers chasing down bugs that don't exist.
Using a pull requests with a test case or an example gives the developer new experience, puts the project's code into their editor, and validates or invalidates their bug before ever asking for the free time of the maintainers.
If we want to include more people in open source, I can't think of a better way than getting open source code on their machines and into their editors.
Talking about code is often fruitless until there's some actual code to talk about. Pull requests require some code in order to start a conversation.
Write a proof of concept and make a pull request. Nothing is better than code that kind of works when discussing features. It reveals shortcomings of the current code and helps everybody understand better what it's going take.
Don't have time or know-how to write a PoC? write some tests that illustrate the feature. You don't need an implementation, just write some assertions that show the API you think would be good. Or, write an example that doesn't work. These options let everybody involved know exactly what you're trying to do and the conversation will go way faster.
It's social coding. Let's have our conversations start with code, working or otherwise. Let's build up contributors by getting some OSS in their editor, and get them writing some code.
Okay, we can't do pull requests for this. But issues are a terrible place for questions anyway. Read the docs, read the examples, go to stack overflow. Questions aren't issues.
Whatever community of folks answering questions you want to build you can build on a platform designed for it. Maintainers can look at the questions over there to get a feel for where their documentation is lacking, but you don't need the issue tracker cluttered up overwhelming maintainers. Turning off issues forces this optimal scenario.
I dont agree with this philosophy. This assumes that the maintainer that built the project created it with perfectly logical syntax, and perfect documentation. One thing I have learned, is that software engineers generally tend to not be very good at exactly these two things. Getting rid of Issues means the only mechanism to clear up what is ultimately poorly written or poorly documented code is to fix it yourself via a pull request. If I had time to stop and clean up every bit of code that I have to utilize on a daily basis I would literally be cleaning up the open source libraries that I use all day every day. For an especially confusing project, and in the absence of Issues, I am guessing many people would just opt out of using the project out of frustration.
Additionally, I think the maintainer, who has the domain knowledge seems like the better person to address issues or at least have a first shot at it, rather than someone that has only just started using it and may not be using it for more than a very limited use case. Communicating without issues and just PRs could result in a timely, and largely fruitless back and forth at an unecessary level of detail. You've just pushed the problem over to PR's only you've made it worse because now you have to read through a full PR rather than 2 sentences asking a basic question.
Think of how we approach development in general, we don't validate concepts by implementing them first in code, we discuss first because discussions are cheap, code is expensive. Tests are also cheap (though not as cheap as discussions), so I have no qualms with communicating via means of broken tests, but an issue seems like a more appropriate place for this, rather than a PR which is intended to be a completed change set ready to merge.
We are software engineers but we are also people. Its ok, we can use our words. The maintainer always reserves the right to make a quick response and say "this is really basic for reasons X,Y,Z" and close it, but many times even in these cases I think its a smell for a hole in documentation somewhere.