I've been yelled at for reporting what I saw as a bug (coz I thought the behavior was bizarre and unexpected) and the author saw as a support request (coz he saw it as expected).
Another common pattern is this "no man's land" of bug responsibility between projects. Project A interacts with project B and that interaction causes a bug or awful problem. Project A and B both wash their hands of it.
I don't particularly mind support requests via the bug tracker - particularly since a pattern of support requests often highlights a UX issue or a lack of clarity in the docs.
Some people view them as irritating annoyances that should be pushed to some forum like stack overflow though.
> Some people view them as irritating annoyances that should be pushed to some forum like stack overflow though.
I maintain a fairly large open source project. We close "issues" that are support requests on sight, with a more-or-less automatic message telling the person that they should use Stack Overflow or Gitter for questions.
This is not because they are irritating annoyances. I in fact do support people on Stack Overflow and Gitter about the project. But there are at least two reasons for keeping things separate:
a) In terms of organization, I need the issue list to be about things that are actionable in the repo.
b) More importantly: only the core developers and some very enthusiastic people follow the GitHub repo. There are many more people available for and willing to support on Stack Overflow and Gitter. It is important that support requests reach these people so that support can be distributed. A lot of users even have more practical experience with the project than the core developers.
Personally, I don't like Gitter or Slack as I find them much harder to search or find already answered questions. Stack Overflow works very well though, a question-answer format is perfect for support requests. Its also much easier to search or link to. I think that Github issues feel closer to that for many people.
Its also important that the project clearly specifies where to ask for help. I'm often reluctant to open issues that aren't bug reports, but the project isn't clear where I should ask.
I wonder if it would be beneficial if github added a support forum to each repo, though having to deal with spam may turn into a major overhead. It would give the opportunity to contribute to a project to those with less technical skills and all the information would be in one place. Gitlab and other products may already have this, I don't tend to use them.
GitHub has "Discussions" on the way[1] which seem like they will greatly help the situation. You can see one in action here[2], which is where I first saw it. Doesn't seem to be generally available yet though, but when it is, I think it will improve issues greatly.
The worst is when project B is a closed source project. I have such an open-source project A that interacts with such a project B. That is the worst. Then I get a bug report, project B got a new version and your project A does not work anymore. Fix it! Then I ask what was changed in the new version of project B. Then they say, they do not know. Then I ask the company of project B. They do not respond. Then I get another email from a user, you need to fix it for the new project B version. Then I send 5 emails to the company of project B. Then they respond, "we do not support project A". And I do not have access to project B myself
Another common pattern is this "no man's land" of bug responsibility between projects. Project A interacts with project B and that interaction causes a bug or awful problem. Project A and B both wash their hands of it.
I don't particularly mind support requests via the bug tracker - particularly since a pattern of support requests often highlights a UX issue or a lack of clarity in the docs.
Some people view them as irritating annoyances that should be pushed to some forum like stack overflow though.