2016 は 10 年くらいサバ読んでるかもしれない。がそれはさておき・・・。

Bug tracker はバグが主役なので、一番目につくところにはバグの症状が書いてある。そして症状覧を書くのはふつうバグを報告する人である。バグを登録した直後は報告された症状が一番大切だから、それが一等地にあっていい。でも時間が経つほど必要な情報と一等地にある情報がズレていく。

修正中のバグなら、たとえば「いつ治る」とか「一時的な workaround」が知りたい。複合的なバグなら「他の症状」が知りたいこともある。修正されたバグなら「どのバージョンで治ったか」「どのように治ったか」「原因が何だったか」などを知りたい。

最初のバグ報告が正確でなかったり、情報が不十分だったりすることもある。開発者はバグの報告者と対話しながら情報を集めたり、正したりしていく。そうやって集めた情報の snapshot がほしい。あるいは紛糾した議論の最中に適当な三行まとめがほしい。

最初のバグ報告のあと時間をかけて集まってくるこうした情報は bug tracker のスレッドの中に埋もれている。現状を理解するためにはスレッドを通して読まないといけない。そしてスレッドには数十のコメントがあったりする。つらい。特に原因解明や責任の所在が二転三転したあと突然自分に assign されてきたりするとつらい。

ほぼ全ての bug tracker は bug の summary line を書き換えることができる。最近の bug tracker は一等地のレポート本文を更新することもできる。でもそれが生かされることはすくなく、大切な情報はスレッドに埋もれている。GitHub なんかはスレッド内の色使いを工夫して必要な情報を見つけやすくしている。でもさ、できれば一等地に大切なことをまとめて書いておいてほしいよね。

Bug tracker のテンプレ項目を増やせという話、ではないとおもう。Stack Overflow は質問と回答の対を添削する文化をつくり、それがサービスの価値になった。同じことが bug tracker にも起きてほしい: 追記ではなく書き直しを促してほしい。バグの初期症状と open/close だけじゃなく、workaround や原因なんかも書かせておくれ。商用製品の KB にはそんな面があるけれど、あの簡易版を開発者が草の根で作れたらいい。 bug tracker はユーザにそれを促してほしい。機械的に支援してくれるとなおいい。もう長いスレッド読むの疲れた・・・というのは大規模プロジェクトで働くとある友人の弁。

まあ Stack Overflow が bug tracker 業界に進出してくればそれでいいのかもしれない。誰でもいいからがんばれ。