> Why? Does it apply for everyone? Yes. Even if it's a stupid question in the docs maybe that means the docs are not as good as they could be. Or maybe it's a

> Why? Does it apply for everyone? Yes. Even if it's a stupid question in the docs maybe that means the docs are not as good as they could be. Or maybe it's a lazy developer / user. It doesn't really matter; most questions are going to be asked multiple times. Saving it in an issue will help those users who use GitHub or Google search and come across it. > If a developer is so saturated that they can only look at 1 issue/day, wouldn't it be better for that issue to be of substance than a random, one-off question? This is a pipe dream. You're never going to get issues of substance. Even if the proposed gist you're going to get a lot of PR garbage that maybe wouldn't have been a PR in the first place. > I also think you are looking at it from the point of view of a maintainer with lots of time I don't see why. My position isn't A maintainer has to answer all questions in an expedient fashion. When you add friction you're going to get less of both the good and the bad. If that's a trade off you want to make, fine, but that's not how you make a good product IMO. It's an important skill to learn to take a lot of incoming noise and filtering it out to find the signal. It may be a good time to work on it if you have a OSS project people are using frequently enough to file issues. Don't forget there are other resources available to you. You may find people in the community to help answer questions, maybe you already answered a question in the past and you can quickly search for it and reply, etc.