「issueを立てるな！」 #OSS

要約

OSS プロジェクトに issue を立てる事について。「最適化するな！」と同程度に「issueを立てるな！」を守りましょう。

導入

OSS プロジェクトに対して気軽に issue を立てられる事が良い事だと思ってる人が存外多いようで、その事に危機感を覚え、この記事を書き殴りました。
OSS プロジェクトに対して気軽に issue を立てられる事が良い事だとする認識は「地獄への道は善意で舗装されている」を地で行ってます、、、

見えてる景色の違い

世の中、無数に OSS プロジェクトが存在しますが、恐らく、、、

90% の OSS プロジェクトは作ってる本人以外誰にも見向きされてない。
9% の OSS プロジェクトは作ってる本人以外にも多少は興味を持たれている。
0.9% の OSS プロジェクトは普通に人気がある。
0.1% の OSS プロジェクトは大人気。

、、、細かい数字の精度はともかく、ノリとしてはパレートの法則よろしくこんな感じでしょう。

枯れ木も山の賑わい

貴方のプロジェクトは十中八九、人気が無いでしょう。素晴らしいソフトウェアであれば必ず人気が出ると言うモノでもありませんし、元より９割方のプロジェクトは人気が無いモノなので、別にそれを貴方が気に病む必要ありません。

人気のないプロジェクトにおいては、本来的には「そんなの README の一番最初に書いてあんだろうが！💢」ってブチ切れてもいいような内容の問い合わせの issue が立てられても、自分のプロジェクトに興味を持ってもらえた！ってだけで嬉しいモノでしょう。そしてそういうノリから、「みんなで互いに気軽に issue を立て合っていけばいいよね！」みたいな感じに考えてしまうかもしれません。

「最適化するな！」

貴方が立てようとしてる issue は本当に必要なモノですか？　ちゃんとドキュメントには目を通しましたか？　レポート内容は正確ですか？　貴方は自分の立てる issue の品質に自信を持てますか？
特に個人でやってるプロジェクトだと、貴方が立てたクソ issue １つが切っ掛けでその OSS プロジェクトが終わりかねません。

最適化に関する「最適化するな！」と言うベストプラクティスに倣い、issue も「issueを立てるな！」がベストプラクティスだと思われます。

issueを立てよう！

パフォーマンスがそのプロジェクトの至上命題である場合ですら「最適化するな！」というベストプラクティスは有効です。
無闇に最適化を施せばメンテナンス性を損ない競争力を失い、結局はパフォーマンスも出せなくなる為です。
もちろん、最適化が必要な場面はあります。しかし、それには事前にプロファイリングを行い、また、最適化を施したコードの速度が、犠牲にしたメンテナンス性に見合うモノであるか慎重に判断する必要があります。

issueも同じです。本当に必要なissueは立てましょう。過去issueに類似したモノはないか？　関連する範囲のドキュメントには全て目を通したか？　バグ報告ならバージョン、 expected(こうなる事が期待されるが), result(こうなった), 再現環境が適切に記述されてますか？　等々抜かりが無いように慌てず慎重にissueを立てましょう。

そして、 立てたissueには責任を持ちましょう。 プロジェクトの運営者からの応答に対して、必ずなんらかのリアクションを行いましょう。

個人的見解

「ルールを作るな、ツールを作れ！」とも言われますし「人の善意やモラルに強く依存するシステムはクソ」だとも考えているので、現行の issue 周りのシステムには大胆な改善が必要だと考えてます。ただ、それが簡単にできる話なら、誰も苦労してねぇよ！ってところですが、、、

追記

いくつかの反応を頂いて、いろいろ補足が必要なように思いましたし、もっと色々言及しておきたい気持ちにもなりましたが、蛇足にもなりそうなので少しだけ追記しておきます。

OSS はフラジャイルで儚い

大半の OSS は個人で且つプライベートの時間で作成されています。そのプロジェクトが貴方の目に留まった時点で、すでにかなりのボリュームのプライベートでの労力が投入されてるハズです。
そしてその OSS は言わば個人のプライベートでの時間的負担と精神的負担の犠牲の上に運営されています。
貴方や他の誰かが issue を立てて関わる関わらないに関係なく元よりいつ終了してもおかしくないフラジャイルで儚い存在です。
大半の OSS はクソ issue １つで簡単に終わりかねない前提にあります。「やってらんね」って思われたらそれで終わるんです。

「issueを立てるな！」

要約

導入