Mozilla サイト・エバンジェリズムにおける Bugzilla フィールドの意味を明示します。
| 使われる場所 | コード | 定義 |
|---|---|---|
Product (プロダクト) |
Tech Evangelism |
テクノロジー・エバンジェリズム・バグは、すべて Bugzilla の「テクノロジー・エバンジェリズム」プロダクトに登録されます。 |
Component (コンポーネント) |
言語別 |
テクノロジー・エバンジェリズムは言語別に コンポーネント に整理されています。サイトの言語によって、最も適当なコンポーネントを選んでください。 |
Priority (優先順位) |
P1 |
有名サイト、重要な問題 - 最優先に処理します。各コンポーネントオーナーには、有名サイトの一覧を管理し、それらの有名サイトに関するバグに evang500 キーワードを付ける責任があります。 |
Priority |
P2 |
有名サイト、ささいな問題 - 特に、簡単に問題を解決できる場合は、できるだけ P1 のバグと同列に扱います。 |
Priority |
P3 |
中小サイト、重大な問題 - これらのサイトは時間があるときに扱います。私たちは、自分たちの時間の投資という観点から、これらのバグがどれだけ努力に見合うだけの価値があるかを確かめる必要があります。そのサイトに対するエバンジェリズムの実施が、他のサイトでも活用できるような役に立つドキュメントを開発する上で有用なら、他の優先順位が高い問題より先に解決される場合もあります。 |
Priority |
P4 |
中小サイト、ささいな問題 - 残念ながら、私たちは現在これらのバグに時間を割く余裕はありません。また後日解決したいと思います。 |
Keywords (キーワード) |
evang500 |
この evang500 キーワードを用いて、注意深く最優先に扱うべき重要なサイトを区別します。各コンポーネントの有名サイト一覧を利用して、各言語でトップのエバンジェリズム・サイトを見つけます。 |
Severity (優先度) |
Major |
|
Severity |
Normal |
|
Severity |
Minor |
|
Status (ステータス) |
UNCONFIRMED |
UNCONFIRMED ステータスは、まだ実績のある開発をしたことがないコミュニティの新メンバーによって登録されたバグに割り当てられます。 バグが登録されたら、このドキュメントに書かれている考えに従って、品質保証を実施します。 |
Status |
NEW |
確認済み、あるいは誰かが Bugzilla の自動確認権で登録した新しいバグです。 |
Status |
ASSIGNED |
エバンジェリズム・バグのステータスは、サイトの分析が完了し、そのサイトにエバンジェリズム・レターを送った場合のみ ASSIGNED に変更します。初めてサイトを分析する場合は、最初に報告されたページを確認するだけではいけません。いくつかのページを見て、そのサイトにおける問題の全体的な本質を突き止め、最初に報告された URL に加えて、たいていの場合は自分でテストした他のページの一覧と具体的に修正すべき箇所の説明をまとめた エバンジェリズム・レター を送ってください。 このドキュメントで後ほど説明するステータス・ホワイトボードの修飾語句を付けてバグをアップデートし、そのサイトの問題についての具体的な説明を要約に加えてください。例えば、LAYER タグ、LAYER API、IE4 限定 API、間違ったネストタグ、などです。 自分たちが相手に余計な作業をお願いしているということを忘れてはいけません。丁寧に、礼儀正しく、相手に敬意を表しましょう。私たちは誰かを怒らせたりしたくはありません。 |
| Target Milestones (ターゲットマイルストーン) | 再調査を実施する月 / Future |
ターゲットマイルストーンは、そのエバンジェリズム・バグをいつ再調査すべきかを決めるために用います。テクノロジー・エバンジェリズムのマイルストーンは月ごとに設定するようになっています。エバンジェリズムを実施した (ステータスが ASSIGNED となっている) バグは再確認してください。そのバグを担当してサイトにエバンジェリズムを実施した人以外は、ターゲットマイルストーンを設定してはいけません。 エバンジェリズム・レターを 2 回出してもサイトから返事がなく、問題が修正されない場合は、ターゲットマイルストーンを Future に設定してください。 |
Resolution (処理方法) |
WORKSFORME |
問題を再現できませんでした。 |
Resolution |
DUPLICATE |
このサイトは既に同様の問題で報告されています。 |
Resolution |
FIXED |
問題は修正されました。 |
Resolution |
WONTFIX |
テクノロジー・エバンジェリズム・バグの処理方法に WONTFIX は使わないでください。その代わり、コンテンツをアップデートするつもりはないという返事をしてきたサイトには、ステータス・ホワイトボードに not-responsive と書き込んでください。 |
Resolution |
INVALID |
通常、テクノロジー・エバンジェリズム・バグの処理方法に INVALID は使わないでください。ただし、コンポーネントオーナーの判断で INVALID とされる場合もあります。 |
Summary (要約) |
サイトのドメイン - ユーザ体験の視点で見た、そのサイトの問題に関する簡潔で具体的な説明 |
要約を入力する場合は以下の形式を用いてください。例えば、http://mail.netscape.com/ に LAYER ベースの JavaScript に関する問題があった場合、要約は次のようになります。 netscape.com - mail uses document.layers |
Status Whiteboard (ステータス・ホワイトボード) |
not-responsive |
反応がないサイトについては、ステータス・ホワイトボードに not-responsive と書き込んでください。 |
Status Whiteboard |
technote-needed |
ドキュメント化することで大きなメリットを得られるような、よくある問題の場合、そのバグのステータス・ホワイトボードに technote-needed と書き込んでください。テクニカルノートが完成したら technote-needed の注釈を削除してください。 |
Status Whiteboard |
plugin |
プラグインメーカーと連絡・協力が必要な問題に印を付けるには、ステータス・ホワイトボードに plugin と書き込んでください。 |
Status Whiteboard |
author |
ツール、エディタなどの作者やベンダーと連絡・協力が必要な問題に印を付けるには、ステータス・ホワイトボードに author と書き込んでください。 |
バグを新規登録する前に、必ず 参加するには のページをご覧ください。
Mozilla テクノロジー・エバンジェリズムは、あなたの苦情受付サービスとして存在しているわけではありません。あるサイトについてテクノロジー・エバンジェリズム・バグを登録する前に、まずそのサイトに苦情を訴えて、Mozilla に対するサポートが欠如していることを伝えてください。
自分が報告しようとしている問題がテクノロジー・エバンジェリズムの問題によるものなのかどうかを 確信 してください。その問題がテクノロジー・エバンジェリズム・バグだと確信できない場合は、最も適切だと思われるプロダクトに対してバグを登録してください。
Bugzilla の Tech Evangelism プロダクトに エバンジェリズム・バグを新規登録してください。
そのバグがどの言語に属するか、コンポーネント を選択してください。
プラットフォームとオペレーティングシステム (OS) を選択
そのサイトの問題が、プラットフォームや OS 特有のものではないと確信できる場合は、プラットフォームと OS を All に設定してください。
初期状態を選択
初期状態 UNCONFIRMED は、Mozilla とサイトの互換性を調査するよう Mozilla エバンジェリズム・コミュニティに依頼するときに使ってください。初期状態 NEW は、Mozilla のサポートに問題があると分かっているサイトを記録する場合に使ってください。
優先度を選択
エバンジェリズム・バグを報告するときは、優先度を Major あるいは Normal、Minor に設定してください。その他の優先度は、私たちのバグの場合に関しては、まったく本来の意味を持ちません。その問題がどれほど深刻か、最良の判断を下してください。
担当者を指定
サイトへの連絡を自分で担当したい場合は、Assigned To (担当者) フィールドに自分のメールアドレスを入力してください。特に担当者を指定せず空白のままにした場合、そのバグはあなたが選んだコンポーネントのオーナーに割り当てられます。
URL を入力
Mozilla のサポートについて問題が見られるページまたはサイトの URL を入力してください。サイト上の特定のページで問題が見られる場合は、そのサイトの他のページでも同じような問題が再現するはずです。サイトのトップページを見て、そこでも問題が見られないか、またそれがどのようなものかを判断してください。もしサイトの大半のコンテンツに問題がある場合は、サイトのトップページの URL を入力してください。
要約を入力
サイトの URL の「主要部分」に続けて、あなたがそのサイトでどのような問題を経験したのかについて、問題の簡潔な説明を分かりやすく入力してください。説明の中に技術的なことを書く必要はありません。
例えば、Web ページ http://www.foo.bar.com/help/support/ について報告する場合、URL の「主要部分」は bar.com になります。これによって、エバンジェリズム・バグの検索結果を要約で分類したり、同じ企業に対するバグをひとまとめにすることが可能になります。
この要約は、エンドユーザが書けて、なおかつ理解できるものでなければなりません。問題のより技術的な説明は、バグが選別され、割り当てられたあとで、ステータス・ホワイトボードに追加してください。
問題の概要を入力
サイトで見られた問題を、適度に詳しく説明してください。私たちが Bugzilla でバグの追跡に利用するフィールドの多くは、バグが登録されてから初めて使えるようになります。そのため、適度に簡潔な説明をここに書き込んでおいて、バグの登録後により詳しい情報を追加してください。
初めてサイトと連絡を取ったことに関して、何か情報があればそれを入力してください。匿名の Mozilla テクノロジー・エバンジェリストが送るメールよりも、顧客からの苦情の方がより効果的です。そのサイトに Mozilla をサポートして欲しいなら、まず顧客として苦情を申し立てるべきです!
バグを送信
バグは送信しないと保存されません!
登録したばかりのバグを編集
ページが正しく表示されない場合、そのページのスクリーンショットをバグに添付してください。画像を添付する際、適切な MIME タイプが設定されているかどうか確認してください。画像のサイズはなるべく小さくしてください。JPEG で 1MB もするスクリーンショットは必要ありません。スクリーンショットに含まれる色数や範囲を小さくして、サイズを削減してください。このとき必ずすべきことは、添付した画像で自分が報告した問題が分かるかどうかを確かめることです。
ページが不正な HTML や JavaScript で記述されている場合は、その HTML や JavaScript をコンピュータのローカルファイルに保存し、それを text/plain としてバグに添付してください。これで、そのページがもともとどう記述されていたのかを記録しておけば、その後のバージョンと問題が報告されたときのバージョンを比較することができます。
バグをレビューして、必要なら 品質保証の手順 に従います。
サイト管理者の特定
サイト内の情報を利用して、そのサイトに連絡を取るための正確な人物を特定します。適当な連絡先が見つからなかった場合、Internic の Whois を利用して、必要な情報を割り出します。
エバンジェリズム・レターを送る
Mozilla エバンジェリズム・レター を利用して、サイト管理者にメールを送ります。ここには、そのサイトで見られる問題と、どうすれば Mozilla や標準をサポートするためにコンテンツをアップデートできるかを記述します。
サイトに連絡を取るときは、常に 礼儀正しい態度を取るよう心掛けてください。メールメッセージは個人のメールアカウントで送信し、自分の書いたことにはすべて責任を負うべきです。
連絡の内容を記録する
エバンジェリズム・レターの基本テンプレートに追加したコメントの概要や連絡情報を含めて、エバンジェリズム・レターを送信したことをバグに記録してください。ただし、サイト管理者に送ったメールをそのまま添付してはいけません。
バグのマイルストーンを、少なくともサイトに連絡を取った 1 か月後に設定します。こうすれば、月ごとにマイルストーンを検索して、再テストの必要があるサイトをフォローすることができます。
そのバグを自分に割り当て、ステータスを ASSIGNED に変更します。
エバンジェリズム・レターが宛先不明で戻ってきた場合...
連絡が取れなかったことをバグに記録します。
もしサイト上で他に連絡先を特定できれば、エバンジェリズム・レターを再送信します。他に連絡先が見つからなければ、そのことをバグに記録して、マイルストーンを Future に変更してください。
サイトの反応が消極的だった場合...
バグのステータス・ホワイトボードに not-responsive と書き込み、他のバグに取り掛かってください。連絡を取るべきサイトは他にもたくさんあり、最初に Mozilla のサポートを拒んだサイトはいつでも再度取り上げることができます。
バグの品質保証を実施するには、Bugzilla でバグを承認するための権限が必要です。また、手続きを進める前に、エバンジェリズムのプロセスに精通し、エバンジェリズム・コミュニティの Zach Lipton (irc: zach)、Asa Dotzler (irc: asa) あるいは他のアクティブなメンバーの誰かと、一連の手続きについて話し合うべきです。irc.mozilla.org の #evangelism または #mozillazine チャンネルを訪れて、コミュニティの他のメンバーを探してください。
Bugzilla を検索して、重複がないか確認する
同じサイトに関するエバンジェリズム・バグが既に登録されていて、そのバグがまだ VERIFIED になっていない場合は、この (新規登録された) バグに対する重複としたいバグのナンバーを入力して、処理方法を DUPLICATE に変更してください。
そのサイトの問題について何か新しい情報があれば、その問題が再現するかどうか確認し、元のバグのコメントに情報を記録してください。
サイトを訪れる
サイトを訪れて、Mozilla のサポートにどのような問題があるのか突き止めてください。特に問題なく Mozilla をサポートしている場合は、バグの処理方法を WORKSFORME としてください。
実際に問題が見つかり、そのバグが UNCONFIRMED となっている場合は、バグを承認してステータスを NEW に変更してください。
サイトを分析する
元のバグレポートに間違いがないか判断します。必要に応じて追加コメントを入力してください。
当月より前にマイルストーンが設定してある割り当て済みバグのレビュー
サイトを訪れて、まだ問題が再現するかどうか判断してください。いくつかのページを見て、サイト全体がアップデートされたか確認してください。まだ問題が見られる場合は、ステータスを REOPENED とします。Mozilla で正しく表示される (動作する) 場合は、ステータスを FIXED に変更します。
処理方法が FIXED または WORKSFORME の場合
サイトを訪れて、まだ問題が再現するかどうか判断してください。いくつかのページを見て、サイト全体がアップデートされたか確認してください。まだ問題が見られる場合は、ステータスを REOPENED とします。Mozilla で正しく表示される (動作する) 場合は、ステータスを VERIFIED に変更します。
処理方法が DUPLICATE の場合
サイトを訪れて、重複とされたバグが本当に元のバグの重複かどうかを判断してください。元のバグに、重複とされたバグで報告された情報がすべて含まれているか確認してください。