25

I'm a collaborator in a pretty popular open source project hosted on GitHub. We have a problem where people constantly show up in the issue tracker and post questions about the library.

Dealing with these questions is time consuming, it pings a lot of people and is generally annoying.

How can I easily direct people to the right support channels?

We already have a contributing.md file that suggests the right channels and that hasn't been working out too well for us.

| improve this question | |
  • 7
    What is the right support channel? – user114 Jun 23 '15 at 20:02
  • 1
    A question is also an issue. – Vi. Jul 9 '15 at 10:45
13

Closing them on sight should give a clear signal that asking in the wrong places is not appreciated. From there, it is possible to guide the users making an honest effort to look in the contributing.md file.

| improve this answer | |
  • 2
    "should give a clear signal that asking in the wrong places is not appreciated" - unless you don't care about alienating parts of your user base, do take good care that it isn't misunderstood as "asking is not appreciated". – O. R. Mapper Oct 20 '18 at 15:43
  • Obviously this applies on a case by case basis. I don't. Some people might, in which case you might want to add a response instead of closing without one. – Unihedron Oct 23 '18 at 11:33
6

When people start abusing your issue tracker to get support, then obviously your other support channels are not accessible enough.

Make sure you have a separate support system which is both easy to find and easy to use.

When I would have a problem with your software, a text file called contributing.md would not be the first place to look. In fact I would likely not look at it at all, because I don't want to contribute. I want to ask a question. When you are lucky, I might look at a text file called FAQ or README or whatever documents I find in a sub-directory called /doc/. But very likely the first place I would look would be your website, and when the only interactive feature I find there is the issue tracker, I would see no other choice.

Mailing lists and IRC channels are nice, but they don't help when they aren't accessible from the web browser. With either medium I have no idea if they are even active.

Do you have a mailing list archive which is searchable from the web and which can be easily found? That would allow people to see if the mailing list is active and if support questions are welcome there. They could also use the search function to check if their question is already answered which saves you a lot of time handling duplicate questions (a problem with a medium like IRC which has no persistence at all).

What about a web-based support forum? Did you consider creating one?

| improve this answer | |
4

It sounds like you need to provide an outlet - some acceptable place - for questions to be asked. That could be a mailing list, online group, IRC and so on.

| improve this answer | |
  • 1
    We have IRC and a stack overflow tag we monitor daily. – Benjamin Gruenbaum Jun 24 '15 at 6:15
  • 6
    @BenjaminGruenbaum But obviously your users seem to find the issue tracker before finding either of these. Maybe this is more of a UX problem? – Philipp Jun 24 '15 at 7:47
  • 3
    I agree with @Philipp, I think you're probably not directing traffic as well as you could. – Paul Beckingham Jun 24 '15 at 15:33
2

On Github, you can use issue templates.

These templates are shown to users while they open an issue, which means that a simple warning like Please don't ask questions here, but use https://example.com is presented to all users, even if they didn't check the repository wiki or readme.

| improve this answer | |
0

Your real problem is that GitHub issues is a lightweight issue tracker that doesn't allow fine-grained access control, and it is being used as both a public Q&A forum and a development issue tracker. Fundamentally, you need to separate the two.

Here are some options:

  • Use a real issue tracker. One that restricts public access, or has things like approval, selective notifications etc.
  • Use a separate, private repo for issues. This repo only contains issues for your project and is accessible to the project collaborators only. If the public questions are still bothering you, you can then disable issues in the main project.
| improve this answer | |
  • 6
    Private issue trackers do not encourage collaboration, they are a wall against new contributors. – Nicolas Raoul Jun 24 '15 at 5:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.