Why you must not ask questions on Github issues

Inada Naoki
3 min readAug 9, 2016

TL;DR

Asking questions on issue tracker may be a DoS attack to developers. Use user forum for discussion, if it exists.

Background

Before the Github era, many OSS projects had issue trackers and forums (BBS or ML). Users discuss on forum and report bugs to issue tracker. Issue tracker was place for issue tracking.

When a user asks a question on the forum, other users helped them. It breeds “user community”. Asking question is one form of contribute.

But, since Github doesn’t provide a forum, many OSS users start asking questions on issue tracker in recent days. At first, a small project started mixing issue trackers and forums. And now, there are many users ask questions on issue tracker even if there is a link to the forum in README.

If a maintainer has enough time and mental energy, and the number of users are small enough, there is no problem.
But when the developer lacks time or energy, asking questions on issue tracker may cause “burn-out”.

Why asking questions on issue tracker cause “burn-out”?

Organizing issue has cost

If important bugs are left for a long time, the quality of the project will become worse.
So developers pay significant efforts to organize and triage issues.

And sometimes it’s difficult to distinguish between question and real issue by reading the only title. That’s why an issue for a question robs the time and energy of the developer.

Maintainer : User ratio

If the ratio of maintainers : expert users : normal or new users is 1 : 10 : 1000,
the maintainers’ time is 1000x important than normal users.

Most of expert user doesn’t check issue tracker often as developers.
When asking a question on the issue tracker, developer will reply to it even if other users can reply to it.

So, asking questions on issue tracker not only robs maintainers’ time but also robs chance of growing user community too.

Maintainers maybe not good at English

I’m not good at English. Reading English is far harder than reading Go, Python, and even C code.

There are many OSS developers like me. We use English with significant effort. Replying to an easy question maybe not as easy as you think.

Sometimes, I took 10 minutes to read a question, 3 minutes to read Python code to reply to the question, and 15 minutes to write a response.
(If they tried to read source code, they might get an answer sooner, and they could learn more than reading my poor English response!)

After I lost mental energy by private reason, I stopped paying my energy and time to be kind to not malicious easy questions.

What should users do?

When you want to ask a question, keep followings:

  • Read README carefully
  • If there is user forum, don’t use the issue tracker to ask a question
  • If there is no user forum, consider StackOverflow.
  • Pay your own time and effort to solve your problem
  • Write complete information at first as possible: reproducible code, OS, version, full stack trace, etc…

FAQ

Q. I don’t know is this a bug or my usage is wrong

A. Until you have confidence it’s a bug, it’s a question, not a bug report.
Ask in a forum, and if it seems bug after discussion, file a bug report to
issue tracker with URL and summary of the discussion.

What I want to maintainers think about

Even if you have enough energy and time at the moment, set up user forum is good because:

  • When you’re like to burn-out, you may not have enough energy to set up a user forum.
  • Educating OSS users to not use issue tracker as the forum may help other OSS developers.

Possible solutions for a user forum

Stackoverflow is designed to polish questions and answers. Polished questions and answers are reusable knowledge. If there are much knowledge in the StackOverflow, many users can solve their problem by Googling.

gitter is chat service. Unlike slack, a group in the gitter is lightweight and bound to Github organization.

Google groups is an easy to use ML. But young people don’t like using mail. And it’s not Markdown friendly. So it may be difficult to navigate users to Google groups.

--

--