Browser-General なバグをあらかじめ選別するには

この文書を読むべき理由

Mozilla が使い易い製品となるにつれて、様々な品質の多岐にわたる膨大な量のバグの報告を受け取るようになってきています。 Mozilla の技術者はバクの奔流の中で限られた時間しかその評価に使えません。 つまり、致命的であるとすでに確定しているバグを修正し、機能を実装する事しかできません。これらのバグの多くは、Browser-General と呼ばれる Bugzilla コンポーネントの範囲に入ります。

私たちが行うべきことは、Mozilla の技術者に各バグが届く前に、バグを最新の状態にし、完全なものにし、適切に関連付けられたものにする事であり、こうする事で技術者はもっと重大なバグを修正しさらに素敵な機能を実装できるようになります。

同意します。が、どうすれば区別できますか?

事前チェックを必要としている未着手のブラウザの汎用的バクの一覧 を最初に参照して下さい。これらのバグの各々はあなた自身のように誠実で思慮深い人によって、バクのメリットと技術的到達点を見極めてもらう事が必要です。

以下にその方法を述べます。

Bugzilla は多くの"役に立つほどでないレベルの"バク報告を受け取ります。このバク報告は、技術者を効率的にバクの修正へと導くものではありません。 Bugzilla はまた事業の開始から退職Netscape 技術支援の要請および手当たりしだいの Netscape のガス抜きから個人広告までに及ぶ"バク報告" を受け取ります!

どのバグが技術者の貴重な時間を費やすのに値するか誰でも直ぐに感触をつかむことが出来ます。つまり通常以下の 4 つのポイントに集約されます:

現在のビルド上でバグ報告の内容を簡単に再現出来ますか?

・・・あるいは、バグ記入の手引きに定められているように、予想される結果と現実の結果が明瞭であるとともに、再現する正確な方法が欠けていないか? mozilla がクラッシュするとかブラウザ問題など、バグの説明が曖昧でないかどうか、また正確に現実の問題を説明しているかどうか?

もしバグを再現可能であれば、自分自身でバグ報告書を補強して不足している情報を補う事を試みて下さい。またバグ報告者に不足する情報の提供を依頼したり、将来のバグに備えてバグ記入の手引きを参照させたり、Bugzilla 入力フォーム手引きの使用を勧める事もできます。もしバグの再現ができないならば、そしてバグ報告者が協力できない、あるいは協力しようとしないのであれば、INVALIDWORKSFORME としてバグを廃棄する事も自由です。

バグ報告書が固有の問題を特定しているか?

経験の少ないバグ報告者は関連のない多くの異なる問題を提起する一枚のバグ報告書を書くことで時間を節約しようとします。これらのバグを自由に INVALID として決定していただいて結構です。そして、バグ報告者に、複数の問題は別々のバグに登録するよう説明してください。バグ報告書が複数の問題を含むべきではない理由は、いくつもあります(John Morrison の好意による):

  • レイアウトのバグはレイアウトのプロへ、ネットワークのバグはネットワークのプロへ行くべき。個別のバグは並行的に処理可能となる。
  • バグが修正されると、特定の試験に対して検証されるべきである。複数の条件や問題を列挙しているバク報告書は検証するのが困難である。
  • 複数のバグを列挙するバグ報告書は、重要な問題を見逃す可能性がある。
  • 単一のバグのみを挙げるバグ報告書は、より速く解決される事が多い。
・・・そして、技術者はバグを実際修正できるでしょうか?

経験の少ないバグ報告者は Mozilla についての一般的なクレームをバグとして提出しがちで、この事で修正可能なバグが導かれません。これらもまた、INVALID として扱うことができます。

例として、2 つの性能に関するバグを見ましょう。役立たないバグが単に Mozilla のインターフェイスが遅すぎると言うのに対して、役立つバグは、特定の再現可能なタスクと、それがどれだけ遅いかの度合いまで識別できます。

このバグは既知の問題の重複報告でしょうか?

何度も何度も繰り返し報告されるバグがあります。もし重複しているとお考えならば、頻繁に報告されるバグのリストと Bugzilla の検索 を使用してください。

もし、それが重複しているかもしれないが自信がない場合は、バグ報告書にコメントを追加だけお願いします。やがて誰かがその配慮を感謝する時が来るでしょう。

よくある重要でないバグへの対応の提案

以下は、バグ対応者がよく出会うレベルの低いバグ報告に対する対応の例文です。これらは Mozilla を使って上手にコピーアンドペーストできます。5 日経っても報告者から回答がない場合は、バグを排除して結構です。

バグ報告が古いビルドを使って作られた場合・・(例えば 3 週間以上前の、現在のビルドでは再現できないようなもの)
<reporter e-mail> - <buildID> は古すぎるビルドで今はバグを報告できません。あなたがいま報告されている
問題はすでに修正されている可能性が強いです。 <http://www.mozilla.org/releases/nightly.html>より最新のナイトリービルドをダウンロードしてください。
そしてそれでも、問題があるかどうか私たちにご連絡をお願いします 以上 <署名>
バグ報告書があまり役立たない場合
<reporter e-mail> - 
<http://www.mozilla.org/quality/bug-writing-guidelines.html> でバグ記入手引きを読んで、バグ報告書に
おいて必要とされる情報の種類を調べて下さい。手引きを読まれた後で、情報(ビルド ID や再現方法)などを
加えて再び報告をして下さい。将来のバクを報告するために手引き付きフォームを使うことも出来ます。 手引き付き入力フォームは <https://bugzilla.mozilla.org/enter_bug.cgi?format=guided> にあります。
Mozilla を試験いただきありがとうございました。 <署名>
バグ報告が Netscape 6 や 7 のバグ用であり、報告者が Mozilla を試験していず、Mozilla では問題が再現されない場合・・・
<reporter e-mail>  - ご入力ありがとうございました。しかし、Netscape 6 や 7 のバグ報告用の正しい場所
は <http://home.netscape.com/browsers/6/feedback/> です。残念ながら、mozilla.org は 私どものバグ
に加えて Netscape のバクにも対応できるだけの資源を確保しておりません。:-) その上、Netscape のバー
ジョンで問題である多くの件が Mozilla ではすでに修正されています。 しかし、この問題を Mozilla の最新のビルドで見る事があれば、お気軽にご連絡いただきこのバグの再開を
ご依頼下さい。 INVALID と扱います。(ご無礼お許し下さい。 Bugzilla では、このように表現いたしております ;-) <署名>

チュートリアル原著者: Eli Goldberg。John Morrison、Sean Richardson、Matthew Thomas、Jan Leger、およびその他このチュートリアルへご意見をいただいた全ての方に御礼を申し上げます。