FirefoxなどMozillaの製品はBugzillaというシステムでバグを管理しているのだが、そのBugzilla@Mozillaではバグのステータスとして、次のようなものを割り当てている。
- UNCONFIRMED
- NEW
- ASSIGNED
- RESOLVED
- VERIFIED
- REOPENED
詳細を知りたい方は、MDCの『バグのライフサイクル』を参照してほしい。とりあえず、今までは「未確認→新規→担当者に割り当て→解決→検証済み→再開」という流れがあったことだけ押さえておけば足りる。
このステータスに変更を加えようという話が、mozilla.dev.planningで持ち上がっていて、現在も「bugzilla.mozilla.org workflow changes」と「Complete workflow reorganization」という二つのスレッドで、活発な議論が交わされている。
提案を出しているのは、主にMozilla FoundationのGervase Markham氏と、Mozilla CorporationのMichael Connor氏の二人で、その内容は次のようなものだ。
- UNCONFIRMED
- CONFIRMED
- READYTOFIX
- INPROGRESS
- RESOLVED
- VERIFIED
従来の「NEW」は、「CONFIRMED（確認）」と「READYTOFIX（修正準備完了）」の二つに分割される。また、「ASSIGNED」は「INPROGRESS（作業進行中）」に変わる。そして、「REOPENED」は廃止される。なお、新名称については複数の候補があり、ここでは代表的なものを取り上げた。
「NEW」を分割する理由は、現状でその中に多くのものが含まれすぎているからだ。単純にバグだと確認されただけのものから、テストケースが揃ってバグの原因がわかっているものまで、すべて「NEW」に含まれるのでは、ステータスを示すものとしてあまり役に立たないというのである。そこで、バグが再現し、明白な重複に当たらないものは「CONFIRMED」とし、テストケースが出てリグレッションの範囲が画定するなどした時点で「READYTOFIX」にセットする。
「ASSIGNED」を「INPROGRESS」に変えるのは、従来の「割り当て」が、必ずしも作業開始を意味せず、「とりあえず担当者を決めた」とか、「将来用にいちおう自分で受け持っておく」といったケースでも使われているためだ。バグのステータスに「ASSIGNED」を含めなくても、担当者（Assignee）という独立の項目があるので、受け持ちの有無はそちらを見ればいい。ステータスに関しては、修正作業が現に行われているかどうかを判別できるようにするほうがよい。
「REOPENED」は、パッチがバックアウト（撤回）された場合によく使われるが、それ自体で意味するものはさほどない。たとえば「RESOLVED」を「INPROGRESS」に戻しつつ、バックアウトされたことをWhiteboard欄に付記するといった手法でも対応は可能だ。また、Mozilla Corporationの技術担当副社長Mike Shaver氏は、「zero-net-complexity rule（複雑さの差し引きゼロルール）」ということを述べていて、ステータスを一つ足すなら、既存のものを一つ削って、総数が変わらないようにすべきだと主張している。理由は、ステータスを増やすことで複雑になるのを避けるためだ。提案では「NEW」が二つに分割されたので、「REOPENED」を削ると差し引きゼロになる。
Bugzillaの変更はFirefoxだけでなく、Thunderbirdその他の製品開発にも影響が出るが、スレッドの議論の流れからすると、Firefoxだけ先行して新ステータスセットに移行することもありそうだ。ただ、Bugzilla開発者のMax Kanat-Alexander氏も、基本的には提案に賛成している（Bug 486292）。Bugzillaを使う製品全般に波及していく可能性は高い。
なお、いまだ議論中であるため、提案内容はさらに変わるかもしれない。また、提案が通ったとして、それをいつから実施するかは別に議論されるべき問題だ。少なくとも現時点では、時期について明言した投稿は見当たらない。
（09/04/07追記）
Bugzilla@Mozillaと書くべきであった点を訂正した。詳細については、コメント欄の あ さんのご指摘を参照していただきたい。
