バグ追跡システムで議論を始めてしまう人たちオープンソースソフトウェアの育て方

バグ追跡システムを積極的に活用しているプロジェクトでは、バグ追跡システムで議論そのものを進めてしまうようになる危険が常にあります。しかし、バグ追跡システムは議論に適していない場所です。ここでは、適切な選択ができるように一般的な原則を中心に紹介します。

» 2009年10月28日 08時00分 公開
[Karl Fogel, ]

バグ追跡システムでは議論しない

 バグ追跡システムを積極的に活用しているプロジェクトでは、バグ追跡システムで議論そのものを進めてしまうようになる危険が常にあります。議論を行うための場所としてはメーリングリストの方が適しているのにもかかわらずです。きっかけはささいなことです。誰かが問題点を投稿する際に、何らかの提案やパッチをつけ加えたとしましょう。それを見たほかの人が、その解決策には何らかの問題があると考え、指摘します。それを見た元の投稿者がさらに反論をします……このような具合です。

 問題なのは、まずバグ追跡システムは議論に適していない場所だということです。そしてもう1つ。他人の目が届かないこともあります。開発に関する議論は開発者向けメーリングリストで行うものと考えられているので、議論に参加したい人は開発者向けメーリングリストの方をチェックしているのです。彼らは、バグ追跡システムの状況を扱うメーリングリストには参加していないかもしれません。仮に参加していたとしても、その中身はそれほど真剣にチェックしていない可能性があります。

 いったいどこがマズかったのでしょう? 最初にバグを報告した人が自分なりの解決策を示したのがそもそもの問題? はじめからメーリングリストに投稿すべきだった? それとも、最初の報告に対して反応した人の方に問題がある?

 この問いに対する正解はありませんが、一般的な原則はあります。問題の報告に単なるデータを追加したい場合は、バグ報告システムを使用するようにし、何らかの会話を始めるつもりならメーリングリストを使用するということです。どちらが適切かがはっきりしない場合もあるでしょうが、自己判断でできるだけ適切な方を選択してください。例えば、何らかの議論を呼びそうなパッチを添付する際には、恐らくそれについて何らかの質問が返されるであろうと予測できます。

 通常は問題を報告する際にパッチも添付するのでしょうが(自分で直接コミットする気がない、あるいはコミット権がない場合を仮定しています)、議論を呼びそうなパッチの場合はメーリングリストを使用した方がいいでしょう。いずれにせよ、単なるデータの追加から実際の対話に移行しはじめる段階は誰かが気付くことでしょう。このセクションの最初で挙げた例の場合、パッチに問題があることに気づいた2番目の投稿者がそれに当たります。パッチに問題があることに気づいたということは、その後何らかの議論が始まることも予測できるでしょうし、その後の会話は適切な場所で続けるべきだということも分かるでしょう。

 数学に例えてみましょう。もしその情報がすぐに収束していきそうなら、バグ追跡システムに直接投稿するようにします。一方その情報が発散しそうなら、メーリングリストやIRCチャンネルを使った方がいいでしょう。

 これは決して、バグ追跡システムで一切の意見交換を禁じるということではありません。例えば、元の報告者に対しての詳細な再現手順の問い合わせなどは、たいていすぐに収束するものです。その問いに対する答えが新たな問題を発生させることなどまずないでしょう。単にこれまでにまとめられている情報を補足するものとなるだけです。その程度の内容のやり取りで、わざわざメーリングリストをにぎわせることはありません。必ず、一連のやり取りはバグ追跡システムの中で済ませてください。同様に、そのバグ報告が間違い(バグではない)ことが明らかだというのなら、そのバグ報告に対して直接そのように言うといいでしょう。また、提案内容にちょっとした問題(問題の解決を妨げるほどには重大でない問題)があったときに、それを指摘するくらいならかまいません。

 一方、「バグか仕様か」や「そのソフトウェアのあるべき振る舞い」といった思想的な話題を扱う場合は、きっとほかのメンバーも議論に参加したくなることでしょう。その手の話題は、一点に収束するのではなくあちこちに寄り道しがちです。ということで、これはメーリングリストの方に振るようにしましょう。

 バグ追跡システムへの報告に関する議論をメーリングリストに移した場合は、メーリングリストのスレッドへのリンクをバグ報告に追加しましょう。たとえそのバグ報告でその後議論が展開することがないとしても、後日そのバグ報告を参照した人が議論に参加したい場合などにそのリンクが重要となります。最初にスレッドを立ち上げる人の負担が少し増えることになりますが、オープンソースの世界には「言いだしっぺの法則」という文化があります。後からそのバグを参照するであろう何千何万の人たちが利益を受けることを思えば、議論に参加している数人の手間が増えることも我慢できるでしょう。

 メーリングリストでの議論の結果得られた結論や議論のまとめは、元のバグ報告にもコピーしましょう。後でそれを読む人たちにとって役立ちます。議論をメーリングリストへ移行させるときの手順は、次のようになります。まずそのスレッドへのリンクをバグ報告に追加し、メーリングリストでの議論が収束したらその結論をバグ報告にコピーする(そして、メーリングリスト上での結論のメッセージへのリンクを付加する)。そうすれば、後でそのバグ報告を見た人は、あちこちたどらなくてもそのバグがすでに収束していることを把握できます。結論をコピーしても、よくある「どちらが正しい情報か分からない」という情報重複の問題を引き起こすことはありません。メーリングリストのアーカイブやバグ追跡システムのコメントは通常は静的なものであり、後で変化することがないからです。

著者:Fogel Karl

翻訳者:高木 正弘

翻訳者:Takaoka Yoshinari(a.k.a mumumu)

製作著作 © 2005, 2006, 2007, 2008, 2009 Karl Fogel, 高木正弘, Yoshinari Takaoka(a.k.a mumumu), under a CreativeCommons Attribution-ShareAlike (表示・継承) license (3.0, 2.1-jp)


よいフリーソフトウェアを作ることは本質的に価値のある目標です。その方法を模索している読者の皆さんが、本連載「オープンソースソフトウェアの育て方」で何かのヒントを得てくだされば幸いです。


content on this article is licensed under a Creative Commons License.

注目のテーマ