QA/BugReport/ja

こちらまでお越しいただき、ありがとうございます. あなたは、LibreOfficeにとって非常に大切な協力をしようとしています. 良いバグ報告は開発者にとって、とても役立ちます. 以下に報告を楽に進めるためのガイダンスがあります.

Bugzillaですべてのバグは扱わない
、バグの中にはBugzilla以外に報告すべきものがあります. それには以下が含まれます:

バグ報告を送る前に
それが本当にバグであることを確かめてください. たいていの場合、バグとは、ソフトウェアがまともなユーザが望まないことをすることです. これは、ソフトウェアがあなたの望んでない動きや要求外の動きをしたり、普通に使っている時にクラッシュすることを含みます. バグは、ソフトウェアの実行に必要以上に時間がかかったり、リソースを使う原因になることがあります.

一部の不具合は、実際には破損したユーザプロファイルの結果かもしれません. OpenGLやOpenCLの問題は、たいてい有効なバグです. バグ報告をする前にOpenGLとOpenCLの設定を確認すれば非常に役に立ちます.

ある時点でバグのように見えるものは、実際には機能要求に近いものです. 私たちは望む機能が実装されていなくても、理想的な世界ではソフトウェアがどのように動作すべきか知っています. 幸いなことに、機能要求からバグを分離することをそれほど心配する必要はありません（訳注：Bugzillaに間違ってバグとして報告したとしても、誰かが機能要求に分類してくれるでしょう）.

あなたがLibreOfficeの使い方を知っていれば、とても役に立ちます. 何が普通なのか、正しい使い方が分かります. まだ特定機能の使い方がわからない時は、バグと思われるものを報告するのに多くの時間を使う必要はありません. ユーザドキュメントを読んだり、慣れるために普段からアプリケーションを使うことを検討してください.

あなたがLibreOfficeをよく知っていて、バグの可能性があって理解できないことがある場合は、LibreOfficeユーザメーリングリスト（英語）（日本語でのユーザメーリングリスト）や Ask LibreOffice（英語）（ 日本語の公式フォーラム）に質問することができます. （訳注：こんなことが起こりましたが、これはバグだと思いますか？他の人の環境だと発生しますか？などを質問するのは有効な手段です）

あなたが見つけたものが本当にバグのようなら、次の手順を行います:


 * 1) バグ発生時に起こったことを忘れないようにメモする. 何をしていたか、何が起こることを期待していたか、実際に何が起こったか、間違ったことだとどうやって知ったか、その問題を再現できるか
 * 2) 既存のバグ報告をチェックする:
 * 3) Componentsページへ移動して、該当するコンポーネント（もしくはサブコンポーネント）を選ぶ
 * 4) コンポーネントを選択した場合: 該当するサブコンポーネントを選択するか、そのページにサブコンポーネントがない場合はExtended Helpを選択する
 * 1) Extended Helpを選択した場合: 該当するサブコンポーネントを選択するか、該当するコンポーネントがないか不明な場合はリストの最後にある[1]をクリックする
 * 2) そのサブコンポーネントのバグ一覧が表示される. ページの一番下のEdit Searchをクリックして、必要に応じて検索を変更できる
 * 3) 問題に関するバグ報告を見つけたら、それに貢献することができる. 問題に関するバグ報告が見つからない場合は、新しくバグ報告を登録する
 * 4) そのバグがUbuntuでのみ発生するか、印刷に関連する場合へ移動する
 * 5) 結局、その問題に関するバグ報告が見つからないならの指示に従う

バグを提出する
ユーザの観点からみた症状が同じに見える場合でも、起こったバグごとに個別にバグ報告をします. 異なるLibreOfficeのバージョンによる、異なる原因の異なる問題は、異なる人、異なるバージョン、異なる時に修正する必要があります. 1つのバグ報告で、それを追跡することは不可能です.

Go to.

サインイン
サインインをするように求められた場合は、Bugzillaアカウントでログインします. （訳注：アカウントは、こちらからメールアドレスを入力して作成してください. ）

コンポーネント
Componentの中からコンポーネントを選択します.

If you are not sure what component your problem is about, choose the LibreOffice component. Someone will review the bug report later and will choose a more precise component. (For more information about triage, which is reviewing bugs to get the important onces to the top of the list, have a look at "BugTriage".)

If it is an urgent issue (broken parts, regression, etc.), and you are an experienced user who knows the development team, you can assign the bug report to one of the developers listed on the FindTheExpert page.

詳細
Sub-componentセクションがある場合は、サブコンポーネントを選択します.

If you don’t know the appropriate subcomponent, go to Components. On that page, click on the appropriate component. Read the descriptions of the all the subcomponents on the page of that component. If you don’t see a suitable subcomponent, click on Extended Help, and read the descriptions of the subcomponents on that page.

Choose the version of the application in which the bug appeared. To check what version of LibreOffice you are using, select

In Operating system or OS, choose the operating system of the computer you were using when you met the bug.

If there is a Hardware section, fill it in.

If there is a Severity section, ignore it unless you are experienced. Selecting Blocker will not get the bug fixed faster. If you want to know the definitions of the items in the Severity section, see this chart.

You can ignore the section latest known-working version.

件名
Check in possibly related Bugs table on the bug-reporting page and additionally in the Duplicates Table to see whether the problem really has not been reported yet.

In the Subject section (also known as the Summary):
 * Do not include information already known from the fields.
 * Include the names of subcomponents from Components.
 * Make the subcomponents uppercase.
 * If the subcomponent can be confused with parts of a word (for example, UI is part of the word quit), surround the subcomponent with square brackets.
 * Use at most two subcomponents.
 * Use subcomponents exactly as they appear in the list, but you may integrate them into the subject line sentence like “WIKIHELP [UI] not available in all languages”.
 * Summarize the problem fairly precisely.
 * bad example: “File is broken”
 * better example: “Menu File > Save as not available (greyed out)”
 * Avoid short forms like “doesn’t” or “isn’t” to ease queries for strings in the Summary; instead, use the full form, such as “does not” or “is not”.
 * If the problem written in the report is that LibreOffice crashes or stops responding (“hangs”), add the word CRASH to the Summary, so that these bugs can be located and tracked easily.

説明と添付ファイル
In the Long Description or Description section, give a lengthier, factual description of the problem:


 * list the steps to reproduce the bug;
 * use a numbered list; and
 * state the exact method to make something happen. For example, instead of writing “Open document”, write instead “In new empty LibO Spreadsheet document, use menu File > Open (LibO dialog) > file type “Text documents” > select attached sample document > double click”.

If you’re using a pre-built LibreOffice on Linux, list the exact versions of LibreOffice packages in your package management system. If you’re using Windows, list the exact filename of the installer, and from where it was downloaded.
 * Including information about installed and used localization (UI language, document language) might be useful.
 * Include whether a 32-bit LibreOffice is used on a 64-bit (Linux) system.
 * Include the package source if it’s not the official LibreOffice build.

Write the expected behavior and the actual behavior.

You can include an attachment, such as a screenshot or a sample document. The typical way to take a screenshot is to press the "Print Screen/PrtScn" button on your keyboard. Depending on your operating system, you might have to then open an image editing application (such as Paint on Windows) and do Edit - Paste in it.
 * If you create screenshots, switch the language to English before making the screenshot. You can do so in.
 * You can make screenshots more useful by adding comments and marking relevant areas with LibreOffice Draw.
 * If you want to attach more than one screenshot, you should collect them all in one document (copy / paste to a LibreOffice Draw document) and attach as a PDF. Please add a short comment to each screenshot to tell what you want to demonstrate with it.
 * If you attach a sample document that exhibits the bug you are reporting, please make the document as minimal as possible. For example, for Writer bugs, the document should ideally have just a single paragraph. To make it easy to find the text from your document in debug tracing, use some very easily recognizable text, like AAAAAAAAAA ₂ ZZZZZZZZZZ for a bug that is triggered by that character.
 * It is preferable to upload attachments individually. However, if you want to attach more than half a dozen documents, create a .zip file containing all documents and attach that .zip.
 * If your attachment is too big to be attached in Bugzilla (bigger than 1 MB) you can use the Experimental upload page.

状態
The only time you should change the status to NEW is, if someone already confirmed the bug elsewhere (Ask, mailing list, some forum). In these cases, provide a link to the discussion with the confirmation.

送信
送信ボタンをクリックすると、あなたのレポートがBugzillaデータベースに追加されます.

Bugzillaへの報告がつらい場合
Bugzillaのバグ追跡システムへの報告がつらい場合や理解できないと思った場合は、こちらへ問題を投稿してください:


 * ask LibreOffice -- ユーザーによるユーザーサポート掲示板
 * users@ja.libreoffice.org ユーザーサポート・メーリングリスト

Even if you post your problem on those channels, your goal should be to get a good bug report on bugzilla. These channels might help you with that. Note, that reporting problems on social media (Facebook, Twitter etc.) is not productive in general as it will rarely lead to a good bug report ending up in bugzilla (see also: 99 ways to ruin an open source project, top 5).

バグを報告した後
If nobody has reviewed your report within an appropriate time (24 hours for a critical bug, 14 days for an enhancement request), consider asking someone else to reproduce your bug report on the users@global.libreoffice.org mailing list or IRC channel.

バグにコメントを追加する

 * Avoid posting “me too” comments which contain no additionally useful information. The exception to this is when you comment on a bug that has been UNCONFIRMED so far. In that case, please provide reproduction steps (or confirm the ones given by the original reporter) and move the issue to status NEW. Note that if there are no clear reproduction steps, the issue might quickly move back to NEEDINFO, so finding a good and simple reproduction scenario is essential.
 * Refrain from adding comments along the line of “we have 1000 seats here and only this bug prevents us from migrating”, as it contains no additional information relevant to QA or to the priority of the issue.

LibreOffice is open source and your help in fixing issues that are relevant to your particular situation is most welcome. You can:


 * Employ and/or teach your own developers to work on LibreOffice. We are most happy to mentor them: see the developer’s pages.
 * Fund individuals or companies to work on specific issues - see the list of certified developers.
 * [mailto:info@documentfoundation.org Contact] The Document Foundation to help you if you have only a small amount of funding, and want to collaborate, coordinate or pool your resources with others in the same situation to fund specific fixes or enhancements.

最小要件

 * 1) OS/LibreOfficeのバージョン;
 * 2) 再現可能手順を列挙する;
 * 3) 適切かつシンプルな 添付ファイル. そして
 * 4) 気づいた点/期待された結果.

良い例

 * - Writer: Crash when clicking the Reminder icon on the Navigation toolbar
 * - DIALOG: Page preview in print dialog refreshes when opening print details
 * - EDITING: Position of connectors connected to a group aren't updated when editing group content

悪い例
Reports can be less than ideal for a number of reasons. Below are some of the common problems:

文章で記述する
Describing a bug report in paragraphs of text is one of the most common problems. Developers do not have the time to read paragraphs of text. Clear, succinct, enumerated steps are always better.

1つの報告に5つのバグを書く
One report should only have a single bug in it. Grouping bugs, or listing a whole list of issues with a single document, is utterly unhelpful. In order to find developers to tackle issues, it is best to give them a single issue to focus on. They are unlikely to take on a bug that has multiple issues listed

詳細や手順が欠けている
All bug reports should have at minimum:

現在、デバッグシンボルを含んだテストシンボルサーバーと共に、LibreOfficeの開発デバッグ・バージョンのインストーラーがあります. デバッグ環境を設定するため、How to get a backtrace with WinDbg(英語) を読んでみてください.

不要な情報を追加する
Adding a lot of extra details that aren’t relevant is another common problem. Examples include:


 * 1) “this is a blocker”;
 * 2) a long list of reasons why it’s a blocker;
 * 3) “I can’t use LibreOffice because of this bug”;
 * 4) “LibreOffice sucks” (or any variation of that); and
 * 5) I’m going to start using your competitor unless you fix it.

複雑な添付ファイル
Attachments should be as simple as possible. Take the time to prune your examples to the bare minimum. This helps tremendously in diagnosing problems.

対応する人が全部知っていると思い込む
Do not assume contributors know what you’re talking about. Describe your steps clearly, each step of the way.

さらなる情報

 * Reporting Ubuntu Bugs
 * Troubleshooting and Reporting Printing Bugs
 * Regular and Confidential Attachments
 * Sanitizing Files Before Submission
 * ADVANCED: Providing extra information for the developers