バグ追跡システムで議論を始めてしまう人たち:オープンソースソフトウェアの育て方
バグ追跡システムを積極的に活用しているプロジェクトでは、バグ追跡システムで議論そのものを進めてしまうようになる危険が常にあります。しかし、バグ追跡システムは議論に適していない場所です。ここでは、適切な選択ができるように一般的な原則を中心に紹介します。
バグ追跡システムでは議論しない
バグ追跡システムを積極的に活用しているプロジェクトでは、バグ追跡システムで議論そのものを進めてしまうようになる危険が常にあります。議論を行うための場所としてはメーリングリストの方が適しているのにもかかわらずです。きっかけはささいなことです。誰かが問題点を投稿する際に、何らかの提案やパッチをつけ加えたとしましょう。それを見たほかの人が、その解決策には何らかの問題があると考え、指摘します。それを見た元の投稿者がさらに反論をします……このような具合です。
問題なのは、まずバグ追跡システムは議論に適していない場所だということです。そしてもう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)
よいフリーソフトウェアを作ることは本質的に価値のある目標です。その方法を模索している読者の皆さんが、本連載「オープンソースソフトウェアの育て方」で何かのヒントを得てくだされば幸いです。
関連記事
- 臨界点を超えた先のコミュニケーションモデル
オープンソースプロジェクトのメンバー間でのコミュニケーションは人数が増えれば増えるほど面倒になります。それが臨界点に達するとき、負の反応は静かに出てくることになります。ここでは、巨大化したプロジェクトに適したコミュニケーションモデルを考えます。 - 足を引っ張りたがる人たち――その深層心理と対処法
あからさまに失礼な態度ではないがプロジェクトの進み具合に悪影響を与えている人たち――こうした人たちは実に扱いにくい存在です。ここでは、彼らはなぜそうするのかを考え、最良の対応について実例を挙げつつ考えます。 - 「空気が読める」開発者への道
あなたがオンラインのプロジェクトに参加しようとする場合、陥りがちなわなをうまく避けていく必要があります。ここでは、ケーススタディを交えながら、開発プロジェクトにおける最高の処世術を伝授しましょう。 - あなたの言葉はなぜ他人の心に響かないのか?
プログラマーとしては二流でもコミュニケーションスキルが優れている人は、結果としてプロジェクトをよい方向に引っ張ることになります。ここでは、オープンソースの世界で暮らす上で、あなた自身がうまくコミュニケーションを行う方法とプロジェクト内での円滑なコミュニケーションを維持する方法を説明します。 - 華やかな開発を支える無視されがちな活動
- オープンソース開発者との好ましい“契約”
- カネと開発者とプロジェクトの不思議な関係
- 開発プロジェクトをめぐるお金の流れ、その真相
- 合意と投票で構築されるOSS開発の社会構造
- “優しい独裁者”はこんな仕事に追われている
- 開発プロジェクトを支える名脇役たち
- バグ追跡システムのライフサイクルを再考する
- バージョン管理システムのすすめ
- バージョン管理システムが分かる13のキーワード
- メーリングリストを120%活用するテクニック
- コミュニケーションを促進する技術的な仕組み
- フリーソフトウェアの公開、その心構え
- フリーソフトウェアプロジェクトはなぜ失敗するのか
- 今日のフリーソフトウェア文化の始まった背景を知る
- 「フリー」と「オープンソース」の違い
- 新しいフリーソフトウェアプロジェクトをスタートさせる方法――概論
- 新しいフリーソフトウェアプロジェクトをスタートさせる方法――各論
- OSSライセンスの選択と適用――クイックスタート
- OSS開発、“はじめの一歩”で抑えておくべきポイント
content on this article is licensed under a Creative Commons License.