要約

  • Bugzilla 2.14は、投票設定の変更や別製品への移動で票を消していた処理を改め、利用者の選択を残すようにした。
  • 票の上限や状態変更の条件を決めるのは管理者。修正担当者には、優先順位や依存関係、目標の版を扱う仕事が残った。

書類を別の引き出しに入れただけで、そこに添えられた要望が消えたら困る。初期のBugzillaには、それに近い問題があった。バグの報告を別の製品に移すと、集まった票がすべて消える。報告された不具合は元気なままで、直してほしい人たちだけが帳簿から退場した。

2000年2月、Matthew Tuckは報告28882を登録した。投票ルールの変更後、自分が支持していた報告が上位10件から下がり、複数の利用者の票が取り除かれたという。求めた処置は控えめだった。上限を下げるなら、その数字まで減らしてほしい。全部消すのは、引き算として張り切りすぎていた。

この報告は2001年2月に無効として閉じられ、その日のうちに再開された。修正済みになったのは8月だ。途中の議論では、より難しい問いが出た。一つのバグに投じられる票を減らすなら、上限で切れば済む。製品全体で一人が使える票を減らす場合、その人が選んだどのバグから票を引けばよいのか。数える処理だけでは決められない。

少しはみ出しても、選択を残す

2001年の2.14版のリリースノートには、採用された方法が記されている。一人が一つのバグに投じた票が上限を超える場合は、上限まで減らし、本人に通知する。一方、製品内での合計が超過した場合は、その票を残す。利用者が投票を変更するときには、超過を解消する必要がある。この版では、それ以上の対応で解消を強制しなかった。

帳尻は一時的に合わなくても、すでに表明された希望は記録に残る。別製品への移動でも、全票を自動的に消す処理はなくなった。分類を整える仕事が、支持を集め直す仕事まで利用者に押し返すことを減らしたのだ。

2002年の2.16版に同梱された管理者向け手引きを読むと、投票の権限が具体的に見える。製品ごとに、一人の総票数、一つのバグに使える票数、UNCONFIRMEDからNEWへ自動的に進める得票数を設定できた。総票数をゼロにすれば投票は無効になる。状態変更の閾値をゼロにすれば、自動で進める処理が無効になる。参加の仕方をかなり細かく決める設定画面だった。

人気が集まっても、作業机は必要だ

同じ版の利用者向け手引きには、修正担当者、優先順位、深刻度、目標の版、他のバグとの依存関係が並ぶ。優先順位は担当者が自分の作業を並べるための項目だった。先に別の不具合を直さなければ進まない修正もある。票は要望を見えるようにし、人と時間の配分はその先で続く。

ウェブ上の報告は、不満に住所を与えた。利用者は同じ問題を見つけ、支持を足し、変化を追えるようになった。その便利さを支えたのは、移動しても記録を落とさない地味な処理だった。バグ管理の歴史には、バグを直す人たちが、直してほしいという声の扱いまで直していた時期がある。