この記事は個人ブログで海外向けに書きかけの記事の日本語版です。そのため、一部日本人向けではない記述が含まれます。
英語版はこちらです Why you must not ask questions on Github issues
現在は GitHub は Discussions を提供しています。 Issue Template から Discussion へと誘導するのがおすすめです。
2023-06-14 追記
TL;DR: Issue Tracker で質問するのは開発者に対する DoS 攻撃になるかもしれない。 Forum がある場合は Issue Tracker で質問してはいけない。
背景
Github の時代になる前は、ある程度の規模のOSSプロジェクトはみんな Issue Tracker と別に フォーラム (BBS, ML など) を持っていました。ユーザーはフォーラムでディスカッションし、 Issue Tracker は Issue Tracking のために利用されていました。
ユーザーがフォーラムで質問した場合、他の回答できるユーザーが回答することが頻繁にありました。
そうやってユーザーコミュニティーが自然発生し、育っていくことができました。
しかし、 Github の時代が来て、 Github が forum 機能を提供しなかったために、 Issue Tracker が質問の場として使われるようになってきました。最初はフォーラムを開設する手間を惜しむプロジェクトが Issue Tracker を forum としても使うようになり、今では「Issue Tracker に質問を投げるのはマナー違反」という常識がなくなり、 forum があるプロジェクトでも Issue Tracker に質問するユーザーを多数目撃するようになりました。
もし開発者の時間と精神力が十分にあり、ユーザー数が小さいなら、このモデルでもうまく行きます。
でも開発者の時間や精神力が足りなくなったとき、このモデルは開発者の燃え尽きを招きます。
なぜ Issue Tracker で質問すると「燃え尽き」るのか
Issue の整理には労力がいる
重要なバグの issue が長期間放置されてしまうと、プロジェクトの品質が悪化します。
なので開発者は issue tracker に目を通し整理するために、（気軽に簡単な質問をする人が想像する以上の）労力を使っています。
そして、 issue のタイトルだけを見ても、それが質問なのかバグ報告なのかを判断できないこともあります。
こうして、質問のための issue が開発者の時間と精神力を奪います。
開発者 : ユーザー比
開発者 : ベテランユーザー : 初心者〜一般ユーザーの比率が 1 : 10 : 1000 とすると、開発者の時間は一般ユーザーの1000倍貴重です。
そしてベテランユーザーといっても、 Issue Tracker に subscribe してすべての issue に目を通しているユーザーは稀です。そのため、ユーザー同士で教え合うことができたはずの質問も、 Issue Tracker にポストされると開発者が回答することになりがちです。
こうして、 issue tracker で質問すると、単に開発者の時間を奪うだけでなく、ユーザーコミュニティーが成長する機会を失うことにもなります。
開発者はネイティブの英語ユーザーではないかもしれない
私も英語が得意ではありません。英語を読むことは、 Go や Python, C言語のコードと比べてさえ、より労力を必要とします。
私のような OSS 開発者はたくさんいます。私達はオープンであるために努力して英語を使っています。
簡単な質問に回答することは、ネイティブの英語ユーザーが想像しているよりずっと難しいことがあります。
例えば、質問を10分かけてよみ、その質問に正確に回答するために3分かけて Python のコードを見直し、そして15分かけて回答を書く、といったことをなんどか経験しました。
(質問者が質問する前に自分でコードを読んだほうが早かったかもしれませんし、私の拙い英語の回答を読むよりもずっと勉強になったでしょう！)
プライベートな事情で時間と、特にメンタル面での余裕を失ってから、私はこういった「悪気のない」簡単な質問に対して親切にするのをやめました。
ユーザーがするべきこと
質問をしたい場合は次の点を守りましょう
- まずは README を注意深く読みましょう。
- ユーザーフォーラムが用意されている場合は、 issue tracker に質問を投げてはいけません
- ユーザーフォーラムが無い場合も、 StackOverflow で質問することを検討してみてください
- 質問する前に、ある程度は自分の時間と労力を使って調査しましょう
- そして、最初から必要な情報がそろった質問を書くようにしましょう: 再現コード、OS、各種バージョン、完全なスタックトレースなど
Q: 質問なのかバグなのか分からないんだけど
A. 分からない間は、それはバグ報告ではなく質問です。まず forum で質問し、どうもバグらしいということになったら、そのディスカッションのURLとサマリを書いて Issue Tracker にバグ報告しましょう。
開発者に考えてほしいこと
もしいま十分な時間と精神力があったとしても、ユーザーフォーラムを用意することにはメリットがあります
- 将来燃え尽きかけた時、すでにユーザーフォーラムを立ち上げる余裕すらなくなっているかもしれません
- 新しいOSSユーザーに、 issue tracker で質問しないというマナーを教えることは、他のOSS開発者の助けになるかもしれません
今時のユーザーフォーラムのセットアップ
Stackoverflow は質問とその回答を（長い「OSは？バージョンは？」というやり取りを省いた）品質の高い状態に磨き上げるように設計されています。
そういった質問と回答は再利用可能なノウハウとなり、「ググって解決」できるユーザーを増やします。
gitter はチャットサービスです。 Slack と比べて、 Github の Organization に紐付いたオープンなグループを手軽に作れるのが特徴です。
Google groups は簡単にセットアップできるMLです。
ですが、最近のユーザーはメールを使いたがりませんし、 Markdown フレンドリーじゃないサービスも使いたがらないので、ユーザーに使ってもらうのは難しいかもしれません。
その代わりに提案したい方法が、 "プロジェクト名-forum" という名前の空の Github リポジトリを作ることです。そのリポジトリの issue tracker をフォーラムとして使えば、 Github 以外のサービスを使いたがらないユーザーにも使ってもらいやすいはずです。
さらに、熱心なユーザーが見つかったら、そのフォーラムリポジトリの管理者に追加することができるかもしれません。