FirefoxをはじめとするMozilla製品に対しては、毎日活発なバグ登録が行われている。ここでいう「バグ」は、動作の不具合に限らず、新機能の要望なども含む広い概念だ。その数は膨大だが、開発リソースには限りがあるため、取り組むべきバグを選別する必要が出てくる。取り組むべきバグは、正しくバグであるもののグループからピックアップされねばならない。
しかし、「正しくバグであるもの」をより分けるという第一段階の作業はたいへんだ。ふつう、Bugzilla@Mozillaに登録されたバグは、まず「UNCONFIRMED」（未確認）の状態に置かれ、重複ではないか、再現性があるかなどのチェックを経て、「NEW」（新規）のステータスを獲得する。ただ、NEWになったバグでも、必ずしも修正作業は行われない。優先順位の低いものは放置されがちだ。
つまり、二つのルートが問題になる。UNCONFIRMED→NEWと、NEW→UNCONFIRMEDである。このうち、NEW→UNCONFIRMEDのルートでは、誰も関心を持たないまま長く放置されたバグをグレードダウンさせることになる。かつてはそうした処置をとれなかったが、2009年3月31日から可能になった（Bug 486144）。
これを受けて、最近、SeaMonkeyプロジェクトで古いバグの整理が提案された。Mozilla Suite開発の後継となる同プロジェクトでは、とりわけたくさんの古いバグを受け継いでいる。しかし、プロジェクト開始以来一度もコメントがついていないバグが約2800個もある。そこで、2005年3月10日以降コメントが付いていないSeaMonkeyコンポーネントのバグは、NEWからUNCONFIRMEDへとステータスを引き下げてはどうかというのが今回の提案である。
SeaMonkeyで混乱なく提案が実施されれば、FirefoxやThunderbirdでも当然考慮されてよい。もちろん、問答無用で引き下げるのではなく、事前にバグ報告者らにメールで連絡がいくので、必要ならば該当するバグにコメントを付けて措置を回避することが可能だ。それでも、この引き下げ措置でまとまった数のバグを整理できるだろう。
もう一つのルートであるUNCONFIRMED→NEWでは、選別にかかる作業量を減らしつつ、良質なバグがNEW（あるいは新ステータス案ではCONFIRMED）のグループに入ってくるようにするにはどうしたらいいかが検討の課題だ。現在Core/Toolkit/Firefoxのカテゴリーに含まれる未確認バグは1万5千もあり、今後も増え続けることが予想されるため、選別コストの削減は極めて重要なのである。
ここで、Mozilla CorporationのMichael Connor氏は、「大多数のUNCONFIRMEDバグは『悪い』バグである」という認識を示しており、同氏が提案する対策は、なかなかに先鋭的なものとなっている。
Connor氏は、ただちに選別可能なものを除きUNCONFIRMEDバグに「NEEDINFO」（要追加情報）のフラグをセットし、二週間以内に応答がなければ「RESOLVED INCOMPLETE」として終局処理すべきと主張する。NEWに昇格する機会を逸した以上、解決すべきバグとは認められないというわけだ。重要なバグであれば繰り返し報告されるはずなので、見落としのリスクはごく小さいという判断である。
また、シンプルなフォームを提供することで最初のバグ報告を簡略化してはどうかとも述べている。バグを見定める側が読む量を減らすことができるし、情報不足だと思えば「NEEDINFO」で追加情報を求めればいい。
加えて、Connor氏はUNCONFIRMEDのバグを別コンポーネントして扱い、データベースを分けてはどうかとも提案している。これによって、たとえば、Firefoxを構成するコンポーネントにバグが登録されるためには、チェックをクリアしたNEWの状態であることが必須となる。前記の主張とも親和的で、専用のフォームで登録されたUNCONFIRMEDバグが独立したデータベースに集められても不自然ではない。
なお、新フォームを嫌う人のため、バイパスは用意する。最初からバグをNEWとして登録できるcanconfirm権限というものが従来から存在しているので、その有無で判断する。繰り返し有用なバグを報告してくれる貢献者には権限の取得申請を促すべき（Bug 487791）という意見も出ている。
さすがに新フォームの提供やデータベースを分ける話になるとシステム開発に時間がかかるだろうが、「NEEDINFO」をWhiteboard欄にセットするだけなら、現行のままで可能である。Connor氏は自動的に「RESOLVED INCOMPLETE」するようなシステム変更を構想しているが、これも労を厭わなければ手動でできる。
前半のNEW→UNCONFIRMEDの話と組み合わせると、バグを大幅に整理する道筋が見えてくる。長らく放置されたNEWをひとまずUNCONFIRMEDに戻し、Whiteboard欄にNEEDINFOと記入。二週間以内に応答がなければ「RESOLVED INCOMPLETE」で処理してしまうのだ。この間、ステータスの変更を防ごうと思うなら関係者が適切なコメントを書き込めばよく、さほど難しくない。
過激に感じられるかもしれないが、どこかで思い切ったことをしないと、宙に浮いたままのバグが増えるばかりだ。Makoto Kato氏も、ソフトウェア開発の経験を踏まえ、『BTSに登録したから、誰かが見てくれると思っているのは間違い』の中で、「ゴミくずのようなバグ」に対処するには、メジャーバージョンのリリースが行われた時点でとりあえずクローズすることと、優秀なテスターにのみバグ報告を許すことが有効だと述べている。Connor氏の意見と似ているのは、合理的に考えるとそこに行き着くからだろう。あとは、開発責任者たちが大なたを振るう決断ができるかどうかにかかっているように思う。
