It's hard to read the title here (or even the content) and not take it as a categorical statement, but I think this is aimed at a very particular subset of all

It's hard to read the title here (or even the content) and not take it as a categorical statement, but I think this is aimed at a very particular subset of all open source: projects that have one or few maintainers, with relatively little time to devote to maintenance, and that are primarily developer-facing libraries. For example, saying that you shouldn't allow a user to report an issue without an associated test for a project that is a UI tool isn't feasible, because there's no guarantee that the user is going to know how to write a test. The same goes of a developer-oriented tool that isn't strictly a code library. The reason a library or framework is a bit different is because these generally fit in the culture of a particular language. That means questions like where a test goes, what the directory structure is, etc, should be relatively understood by a contributor. If the contributor is too new to understand them, this does leave them out in the cold, in a sense---but it's also important not to ignore the value of the developer's time. Some may say, hey, you don't have to address all issues. And in a basic sense this is true. I have no obligation to respond to issues in my repo. But I'm a human being who likes to follow the golden rule. I want to interact with others if they are willing to engage me, but I also need to keep in mind that I have, say, 5 hours a week to devote to this project. Saying “bring some of your time and I will give you some of mine” doesn't seem rude in this context. Indeed, it seems natural. If you're just doing a side project and you don't have the time to invest, that's fine. Go use another library, and be well. No hard feelings. If you're using this professionally, you're using my code to save you time, which is to say money in this case. I have zero qualms about asking you to invest a modicum of that time to reduce the few cycles I have that must be devoted to reproducing your issue. Audience matters. And one must remember that choices like this shape the audience of one's project. If I decide to turn off GH issues and only accept pull requests, that means I've probably reduced my audience. But it also means I've set a tone for that audience. If that's the choice someone wants to make, I think they should be encouraged. After all, the more quality code that is out there to see and learn from, the more we all benefit---even if we don't use a given library directly because its interaction style isn't our own.