バグ追跡システムのライフサイクルを再考するオープンソースソフトウェアの育て方(3/3 ページ)

» 2009年09月04日 08時00分 公開
[Karl Fogel, ]
前のページへ 1|2|3       

バグ追跡システムをあらかじめフィルタする

 ほとんどのバグ追跡システムは結局同じ課題に悩まされます。バグを報告した経験が少なかったり、肝心な部分を知らない善意のユーザーが、既に報告されている問題やバグではない問題を大量に報告してくるのです。この傾向に対処するはじめのステップとして、バグ追跡システムのトップページに目立つように注意書きを置いておく方法があります。そこで本当にバグかどうかを区別する方法や、既に報告されている問題かどうかを検索する方法、そして最後に、本当に新規のバグであった場合に効果的に報告する方法を説明しておくのです。

 こうすることでしばらくは報告されてくる問題のノイズは下げられますが、ユーザーが増えてくるにつれてこの課題は結局再燃します。このことでユーザーを責めることはできません。一人一人のユーザーはただプロジェクトをよくするために貢献しようとしているだけですし、たとえ彼らのバグ報告がはじめは役に立たなかったとしても、あなたは彼らにひき続きプロジェクトに参加してもらい、将来はよりよいバグ報告をして欲しいと思うでしょう。しばらくの間は、バグ追跡システムに自由にバグを報告させ続ける必要があります。

 この課題を避けるために何より実行すべきことが2つあります。バグではない問題や、重複したバグ報告を報告されたらすぐに処理済みとマークできる十分な知識がある人にバグ報告システムを見張ってもらうこと。そしてバグ報告システムにバグを報告する前に、ほかの人とバグかどうかを確認するようユーザーに求める(または強く勧める)ことです。

 はじめのテクニックはあらゆるところで使われているようです。巨大なバグデータベースを持つ(例えばDebianのバグ追跡システムは、執筆時点で31万5929個のバグ情報があります)プロジェクトでも、バグが報告されるたびに誰かが見張るようにシステムを改造しています。問題のカテゴリによって見張る人は違うかもしれません。

 例えばDebianプロジェクトはソフトウェアパッケージの集合体なので、自動的にそれぞれの問題を適切なパッケージメンテナに転送しています。もちろん、ユーザーがときどき問題のカテゴリを誤解することもありえます。そういう場合は、そのバグははじめは間違った人に転送されるので、転送された人が再度転送し直さなければなりません。しかし重要なのは、その負担が共有されているということです――ユーザーがバグを報告するときに正しいか間違っているかを推測しようがすまいが、報告されたバグを見張る役目は多かれ少なかれ開発者に分散されています。よって問題が報告されるたびに、適切なタイミングで応答できるのです。

 2つ目のテクニックは広く使われてはいませんが、これは恐らく自動化が難しいからでしょう。アイデアの要点は、新しく報告されてくる問題をデータベースに登録する前に、“仲間を”巻き込むことです。ユーザーが問題を見つけたと思ったときは、メーリングリストかIRCで説明するように求めます。そうすることで、誰かが本当にバグかどうかを確認するのです。

 別の人の目に早めにさらすことで、たくさんの間違った報告を避けることができます。別の人がその振る舞いはバグではないと分かったり、最近のリリースで解決済みだと分かる場合があります。または、別の人が以前報告された問題から報告されるバグの兆候に精通しているので、古い問題であるとユーザーに指摘することで重複した報告を防ぐことができる場合もあります。“既に報告された問題かどうかをバグ追跡システムで検索したかい?”とユーザーに聞くだけで十分なこともあります。多くの人はそんなことを考えてもいませんが、誰かがそうすることを期待していると分かれば、喜んで検索するものです。

 仲間を巻き込む仕組みはバグデータベースをきれいにしてくれますが、欠点も幾つかあります。多くの人が、新しくバグを報告するときに仲間を見つけなさいという指示を見ないか、軽視するかして、結局1人でバグ報告をしてしまうことです。よって、ボランティアにはやはりバグデータベースを見張ってもらう必要があります。

 さらに、ほとんどの新しい報告者はバグデータベースを維持するのがどれだけ難しいかを知らないので、ガイドラインを無視しているからといって厳しく注意するのはフェアではありません。よってボランティアは、誰にも見てもらっていないバグ報告を報告者にどう差し戻すのかは、用心深く、なおかつ慎重でなければなりません。これは、問題をフィルタする仕組みを理解する人々を増やせるように、ゆくゆくは仲間を巻き込んでバグ報告をしてもらうことが目的です。誰にも見てもらっていないバグ報告を見つけたら、取るべき理想的な対処のステップは次のようなものです。

1. すぐにバグ報告に応答し、ユーザーがバグ報告をしてくれたことに丁寧にお礼を言います。しかし、バグかどうかを誰かに見てもらうガイドラインがあることを指摘します(これはもちろん、Webサイトに目立つように投稿すべきです)。

2. 報告された問題が明らかに正しいもので重複していない場合は、取りあえずそれを受け入れて通常のライフサイクルを開始します。結局、報告した人はバグかどうかを誰かに見てもらうべきだといわれているので、正しいバグ報告を処理済みにするまで労力を無駄にする点はありません。

3. そうでない場合、つまり報告された明らかに正しくない場合は処理済みとマークしましょう。しかし、報告した人には誰かにバグであるかを確認した上で報告したのなら、再度保留中にして欲しいと伝えます。この場合、報告した人は確認をとったスレッドへの参照(e.g.メーリングリストアーカイブへのURLなど)を掲載するはずです。

 この方法はいずれバグ追跡システムのS/N比を改善してくれるでしょう。しかし、間違ったバグ報告は決してなくならないことを覚えておいてください。間違ったバグ報告を根絶する唯一の方法は、開発者以外の人にはバグ追跡システムを使わせないことです――しかし、この方法でよい結果が出ることはほとんどありません。間違ったバグ報告を取り除くことがプロジェクトのルーチンワークであることを受け入れ、できるだけ多くの人たちの助けを得ようとした方がよいでしょう。

 章8.ボランティアの管理バグマネージャ項も参照してください。

著者: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)


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


前のページへ 1|2|3       

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

注目のテーマ