こんばんは 又吉です。 長いのでいくつかに分けて送ります。 査読よろしくお願いします。
-------------------- Issue Writing Guidelines Issue記述のガイドライン 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. そして、怒らないでその他の規則にも従ってください。簡単に言えば、あなたが より効果的に問題の報告をすることができるほどエンジニアが実際に問題を解決 しやすくなります。そして、その報告に私たちは興味を持っています。 How to Write a Useful Issue Report 役立つ Issue 報告の書き方 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." 悪い例:(省略)(参考訳:私のスプレッドシートはファイルを開こうとしていると きに異常終了しました。私はそのファイルがチャートを含んでいた気がします。 私のコンピュータは Windows です。私は、この問題が重大であり、あなたがこ れをすぐにでも修理すべきだと思います。ところで、このアイコンは実にむかつ きます。あなたが、こんな見にくいアイコンを使い続けるなら、だれもこのソフ トウェアを使用しないでしょう。そして、私の祖母の Writer も動作しません。 全く動作しません。では。) -------------------- ここでいったん区切ります。 査読お願いします。 -- --------------- N.Matayoshi --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
