Revision as of 06:40, 31 May 2009

Issue記述のガイドライン Issue Writing Guidelines

原文:Issue Writing Guidelines

翻訳終了。査読作業中。

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

規則の考慮 Consider the rules

We strongly encourage you to read the Basic IssueTracker rules - for those who work with IssueTracker on a day-by-day base, they have proven to immensely reduce their work. It's really easy for you to report issues in a way which cost all others a lot of time, but if you invest a little more effort in the beginning, you save others a lot thereof afterwards.

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

Thus, if you're new to OpenOffice.org's IssueTracker, please read the rules. And, of course, please follow them :-), to make our all work easier, so we can concentrate on improving the product, instead of wasting time with bad issue reports.

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

And, please don't be offended if we ask you to follow some rules: Simply put, the more effectively you report an issue, the more likely an engineer will actually fix it, and this is what we all are interested in.

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

見やすい Issue 報告を IssueTracker に登録する方法 How to Write a Useful Issue Report

Useful issue reports are ones that get issues fixed. A useful issue report normally has two qualities:

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

1. Reproducible. If an engineer can't see it or conclusively prove that it exists, the engineer will probably stamp it "WORKSFORME" or "INVALID", and move on to the next issue. Every detail you can provide helps.

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

2. Specific. The quicker the engineer can isolate the issue to a specific problem, the more likely it'll be expediently fixed. (If a programmer or tester has to decipher an issue, they spend more time cursing the submitter than fixing or testing the problem.)

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

Let's say the application you're testing is a spreadsheet application. You crash at when you open the file foo.sxc, and want to write up an issue report:

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

Bad: "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."

悪い例: "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 も動作しません。全く動作しません。では。)

Good: "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."

良い例: "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 報告を登録する方法 How to enter a useful Issue Report into IssueTracker

In order to file an Issue, you must be a registered user of OpenOffice.org. Registering is easy: simply click on the "Join" link in the left navbar and follow the instructions. It takes all of a few minutes. If you are a registered user, click on the "My Issues" link in the left navbar or on the "Bugs and Issues" link on the navbar. The latter is a more comprehensive page which provides a explanation of IssueTracker and also has some useful IssueTracker links, such as a query link.

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

Go to the IssueTracker Query Page to determine whether the defect you've discovered is a known issue and has already been reported. (If your issue is the 37th duplicate of a known issue, you're more likely to annoy the engineer. Annoyed engineers fix fewer issues.)

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

Next, be sure that you've reproduced your issue using a recent build. (Engineers tend to be most interested in problems afflicting the code base that they're actively working on, rather than those in a code base that's hundreds of issue fixes obsolete.)

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

If you've discovered a new issue using a current build, report it in IssueTracker:

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

1. If you're not already logged in, please enter your username & password in the appropriate filds at the top of this page (or any other page on this site)

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

2. From your IssueTracker main page, choose "Enter a new issue".

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

3. Select the product that you've found an issue in.

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

regarding 2., there is a link "File Issue" as well, accessible from the "My Pages"-tab (When logging in you're automatically directed to "My Pages", you can then access IssueTracker using the links in the "My Tools" box on the left side of your screen)

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

フォームを記入してください。フォームには次のような項目があります。 Now, fill out the form. Here's what it all means:

Where did you find the issue?

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

Product: In which product did you find the issue?

You just filled this out on the last page.

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

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

Version: In which product version did you find the issue?

If applicable.

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

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

Component: In which component does the issue exist?

IssueTracker requires that you select a component to enter an issue. (If they all look meaningless, click on the Component link, which links to descriptions of each component, to help you make the best choice.)

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

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

Platform: On which hardware platform did you find this issue? (e.g., Sun, PC)

If you know the issue happens on all hardware platforms, choose 'All'. Otherwise, select the platform that you found the issue on, or "Other" if your platform isn't listed.

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

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

OS: On which Operating System (OS) did you find this issue? (e.g. Linux, Windows NT)

If you know the issue happens on all OSs, choose 'All'. Otherwise, select the OS that you found the issue on, or "Other" if your OS isn't listed.

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

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

How important is the issue?

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

Issue Type: Is this a defect, enhancement, feature-request, task or patch?

This item defaults to 'defect'. (To determine the most appropriate type of issue, click on the Issue Type link for a full explanation of each choice.)

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

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

Priority: How much does the problem affect the product's overall usefullness?

Developers use this field as one measure how to priorize their work.

This item defaults to '3'. 1 is the highest (rarely used), 5 the lowest priority.

Please read the definition of issue priorities carefully before attempting to use P2 or even P1.

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

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

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

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

Who will be following up on the issue?

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

Assigned To: Which engineer should be responsible for fixing this issue?

IssueTracker will automatically assign the issue to a default engineer upon submitting an issue report; the text box exists to allow you to manually assign it to a different engineer. (To see the list of default engineers for each component, click on the Component link.)

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

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

Cc: Who else should receive e-mail updates on changes to this issue?

List the full e-mail addresses of other individuals who should receive an e-mail update upon every change to the issue report. You can enter as many e-mail addresses as you'd like; e-mail addresses must be separated by commas, with no spaces between the addresses.

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

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

What else can you tell the engineer about the issue?

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

URL: On what URL did you discover this issue?

If you encountered the issue on a particular URL, please provide it (or, them) here.

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

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

Summary: How would you describe the issue, in approximately 60 or fewer characters?

A good summary should quickly and uniquely identify an issue report. Otherwise, developers cannot meaningfully query by issue summary, and will often fail to pay attention to your issue report when reviewing a 10 page issue list.

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

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

A summary of "Abort trying to install on RedHat 7.0, Kernel 2.2.14" is a useful title. "Software fails" or "install problem" would be examples of a bad title.

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

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

Description: What else can you tell the engineer about this issue?

Please provide as detailed of a problem diagnosis in this field as possible. A precise step-by-step description is the best way to do it.

For crashing issues it might help to have additional information in case you're able to provide that:

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

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

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

Target Milestone: Think of it as a deadline; targets are "not determined" or "next build"--for most issues, stipulate "not determined."

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

Attachments. It may be the case you need to add an attachment(s) to an Issue, either the one you file or another one. You can do it; the limit is 10MB, but please keep any attachment small, as most people use 56K connections. Attaching a file to an issue is a two-step procedure and is not obvious. You must first submit the issue or locate the issue to which you wish to attach the file. Then, you can add the file as an attachment to that issue. There will be a link in the issue body that reads:

Create a new attachment (proposed patch, testcase, etc.)

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

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

Note: You cannot add OpenOffice.org files natively. They must be added as "binary" files. This is a temporary problem.

注意: あなたは最適化された OpenOffice.org のファイルを加えることができません。それはバイナリファイルとして加えなければなりません。これは一時的な問題です。

Hints: Reduce the size of your file as much as possible. And, if you are uploading an HTML document, be sure to compress it first (Zip or tar it), otherwise it gets corrupted when others try to download it.

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

You're done! After double-checking your entries for any possible errors, press the "Commit" button, and your issue report will now be in the IssueTracker database.

これで終わりです。間違いがないか、すべての記入項目を再確認した後に、"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
--06:40, 31 May 2009 (UTC)

翻訳
Matayoshi

査読
Takizawa-san
Nakamoto-san
Okayama-san