JA/QA/Issue Writing Guidelines

Issue記述のガイドライン

原文:Issue Writing Guidelines

$Date: 2007/02/23 11:26:39 $ (訳注:原文の更新日時)

規則の考慮

私たちは、あなたが Basic IssueTracker rules を読むよう強く奨励します。それは、毎日 IssueTracker で働いている人たちの仕事を減らすためです。あなたが彼らに多くの時間を費やす報告をすることは簡単ですが、報告する際に努力をもう少し注ぎ込んでくれると彼らの時間を節約することができます。

したがって、 OpenOffice.org の IssueTracker に慣れていないなら、規則を読んでください。そして、私たちの仕事を簡単にするためにそれに従ってください。そうすれば、良くない issue 報告に時間を費やす代わりに、私たちは製品を改良するために集中することができます。

そして、怒らないでその他の規則にも従ってください。簡単に言えば、あなたがより効果的に問題の報告をすることができるほどエンジニアが実際に問題を解決しやすくなります。そして、その報告に私たちは興味を持っています。

見やすい Issue 報告を IssueTracker に登録する方法

役立つ issue 報告は問題を解決するための一つの手段です。役立つ issue 報告は通常２つの性質を持っています。

1. 再現できること。エンジニアがその問題を再現することができないか、それが存在するときちんと証明できないと、その問題を "WROKSFORME"(再現せず) か "INVALID"(無効) として扱い、別の問題の解決に移るでしょう。あなたが問題のあらゆる詳細を提供できれば問題解決の手助けになります。

2. 特定できること。エンジニアがその問題の原因を特定することが早くできれば、より早く問題を解決することができます。(プログラマーかテスターが問題を判読することになれば、彼らは問題を修正するかテストするよりも報告者に文句を言うのに余計な時間を多く費やします。)

たとえば、あなたがテストしているアプリケーションがスプレッドシート (Calc) だとします。あなたが foo.sxc ファイルを開いているときにアプリケーションが異常終了して、 issue 報告を書きたいとしましょう。

悪い例: "My spreadsheet crashed when I tried to open a document. I think it contained a chart. My computer uses Windows. I think that this is a really bad problem and you should fix it now. By the way, your icons really suck. Nobody will use your software if you keep those ugly icons. Oh, and my grandmother's has a problem with the word processor. Nothing works right, either. Good luck."(参考訳:私のスプレッドシートはファイルを開こうとしているときに異常終了しました。私はそのファイルがチャートを含んでいた気がします。私のコンピュータは Windows です。私は、この問題が重大であり、あなたがこれをすぐにでも修理すべきだと思います。ところで、このアイコンは実にむかつきます。あなたが、こんな見にくいアイコンを使い続けるなら、だれもこのソフトウェアを使用しないでしょう。そして、私の祖母の Writer も動作しません。全く動作しません。では。)

良い例: "I crashed each time when I opened the attached spreadsheet document using the 10.13.00 build on a Win NT 4.0 (Service Pack 5) system. I also rebooted into Linux (RedHat 6.2), and reproduced this problem using the 10.13.00 Linux build.

When I removed the chart from the document I was able to load it without any trouble."(参考訳:私が Windows NT 4.0 (Service Pack 5) 上で10.13.00ビルドで添付のスプレッドシート文書を開いたときに異常終了します。また、 Linux (RedHat 6.2) でも Linux 版の10.13.00ビルドでもこの問題が発生しました。

その文書からチャートを取り除いたときは、問題なくソフトは動作しました。)

IssueTracker に役立つ Issue 報告を登録する方法

Issue を登録するために、あなたは OpenOffice.org の登録ユーザーでなければなりません。登録は簡単です。右上の "Register"(訳注:現在は"Log in / create account") をクリックして指示に従ってください。２～３分で登録できます。もし、あなたが登録ユーザーなら左のペインにある "Bugs and Issues"(訳注:現在は"File issuse") をクリックしてください。このリンクからは IssueTracker の説明など何かの役に立つ関連事項や、検索ボタンがある包括的なページに行きます。

あなたの発見した問題が既知の問題ですでに報告されていないか判断するために IssueTracker Query Page へ行ってください。 (せっかく登録しても、実は同一報告第37号になってしまうかもしれません。こうなるとエンジニアは報告対応の事務処理に追われて、問題を直す時間がなくなってしまいます。)

次に最近のバージョンでその問題が発生するか確認してください。 (エンジニアは数百も問題のある過去のコードベースよりも彼らが活発に取り組んでいるコードベースにある問題にもっとも関心を持つ傾向があります。)

もしあなたが、現行のバージョンで新しい問題を見つけた場合、 IssueTracker に報告してください。

1. もしまだログインしていないなら、このページ (またはこのサイトのほかのページ) の上部の適切なフィールドにユーザー名とパスワードを入力してログインしてください。 ログインページ

2. IssueTracker のメインページから、 "Enter a new issue"(訳注:現在は"Go on - submit the issue") を選んでください。

3. あなたが問題を発見した製品名を選択してください。

2. に関して"マイページ"タグから"File Issue"にアクセスできます。 (ログインするとき、あなたは自動的に"マイページ"に移動します。その後、画面左側の"マイツール"ボックスにあるリンクを使用することで、 IssueTracker にアクセスできます。)

フォームを記入してください。フォームには次のような項目があります。

どこで問題を見つけましたか?

Product:どの製品で問題を見つけましたか?

前のページで選択済みです。(訳注:実際にはこの項目はありません。代わりにコンポーネントを選択します。)

バージョン:どの製品バージョンで問題を見つけましたか?

該当する場合は記入してください。

コンポーネント:どのコンポーネントで問題を見つけましたか?

IssueTracker は問題を登録するためにコンポーネントを選択する必要があります。(適切な選択肢がわからない場合は、 Component リンクをクリックしてください。リンク先には各要素の説明があり、あなたがもっとも適切な選択を行うための手助けになります。)(訳注:前のページで選択済です。)

プラットフォーム: どのハードウェアプラットフォームで問題を見つけましたか? (例えば Sun、PC)

あなたが問題がすべてのハードウェアプラットホームで発生することを知っている場合は "All" を選択してください。そうでなければ、あなたのプラットホームか、リストにない場合は "Other" を選択してください。

OS: どのオペレーティングシステム (OS) で問題を見つけましたか? (例えば Linux、Windows NT)

あなたが問題がすべての OS で発生することを知っている場合は "All" を選択してください。そうでなければ、あなたの OS か、リストにない場合は "Other" を選択してください。

問題はどれくらい深刻ですか?

課題のタイプ:不具合、機能追加、新機能要望、タスク、パッチから選択します。

この項目はデフォルトで 'defact'(不具合) になります。 (IssueTracker リンクの説明を見て、適したタイプを選択してしてください。)

優先度:この問題は製品全体の価値にどれほど影響しますか?

開発者は仕事の順序を決めるとき、この項目を手がかりの一つにしています。

この項目は P3 がデフォルトです。P1 は最も高く (まれにしか使用しません)、P5 が最も低い優先度です。

P2 を選択するときは、問題優先順位の説明をよく読んで慎重に使うようにしてください。P1 は、さらに慎重な扱いが必要です。

誰がこの問題に対応しますか?

担当者:担当エンジニアの名前

issue 報告を登録するとき、 IssueTracker では自動的に担当エンジニアが割り当てられます。別の担当者を割り当てる場合はこのテキストボックスを使用します。 (各コンポーネントを担当するエンジニアのリストは Component リンクで見ることができます。)

Cc:他の誰がこの issue の最新の変更に関する電子メールを受け取りますか?

issue 報告のあらゆる最新の変更に関する電子メールを受け取る他の完全な電子メールアドレスをリストアップしてください。あなたは好きなだけ多くの電子メールアドレスを入力できます。アドレスの間には空白を挟まず、コンマ(,)で区切ってください。

あなたはこの問題に関してエンジニアに伝えることが他にありますか?

URL:この問題が発生する URL を記入します。

特定の URL で問題がおきるなら、その URL をここに入力します。2つ以上でも入力できます。

要約: 問題を英語で60文字前後か、できればもっと短く説明してください。

issue 報告を早く、そして、確実に特定できるのが良い要約です。要約がうまくないと開発者が検索しても見つかりません。不具合報告が10ページも並んでいる中で、気付かれかないかもしれません。

良い例:"Abort trying to install on RedHat 7.0, Kernel 2.2.14"(参考訳:RadHat 7.0 の Kernel 2.2.14 上でインストール中に失敗)

悪い例:"Software fails" or "install problem"(参考訳:ソフトウェアが動かない、インストールの問題)

説明:この問題に関してエンジニアへ伝えたい詳細を記入します。

問題点をできる限り詳細に入力してください。問題が発生するまでのステップを正確に説明するのが一番良いでしょう。

クラッシュの問題の場合、次の追加情報も提供できれば役立ちます。

ターゲットマイルストーン: それを最終期限と見なしてください。目標は "not determined"(未定)もしくは、 "next build"(次のビルド) -- ほとんどの問題には、 "not determined"を指定してください。

添付ファイル。 issue にファイルを添付する必要がある場合はここを使います。2個以上の添付もできます。記入している報告だけでなく、他の報告にファイルを添付することもできます。サイズ制限は10MBですが、ほとんどの人が56Kの接続を使用するので添付は小さくしておいてください。 ファイルを報告に添付する手順は2段階ですが、少し説明が必要です。第1段階は報告を登録するか、またはファイルを添付したい報告を見つけなければなりません。第2段階で実際にファイルを添付します。報告の表示に、次のようなリンクがあります。

新規添付の作成 (パッチ案、テストケース等)

ヒント:ファイルのサイズをできるだけ減らしてください。それが、HTML文書ならば先に圧縮してください(Zip または tar)。他の人がダウンロードするときに壊れます。

これで終わりです。間違いがないか、すべての記入項目を再確認した後に、"Commit"(訳注:課題の実行)ボタンを押してください。 issue 報告は IssueTracker データベースに登録されます。

(These Bug Writing Guidelines were originally written for Mozilla by Eli Goldberg. Thanks to Claudius Gayle, Peter Mock, Chris Pratt, Louis Suarez-Potts, Tom Schutter, and Chris Yeh for contributing to this document. Constructive suggestions and feedback is welcome. In this case just post your suggestions to the dev@qa mailing list.)

(これらの Bug Writing Guidelines はもともとは Mozilla のために Eli Goldberg によって書かれました。この文書に貢献してくれた Claudius Gayle, Peter Mock, Chris Pratt, Louis Suarez-Potts, Tom Schutter, and Chris Yeh に感謝します。有益な意見とフィードバックを歓迎します。この場合 dev@qa メーリングリストにあなたの提案を提示してください。)

原文:Issue Writing Guidelines
--10:07, 4 June 2009 (UTC)

翻訳
Matayoshi

査読
Takizawa-san
Nakamoto-san
Okayama-san
Kubota-san
Hirano-san