QA/バグ報告
TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate
こちらまでお越しいただき、ありがとうございます。あなたは、LibreOfficeにとって非常に大切な協力をしようとしています。良いバグ報告は開発者にとって、とても役立ちます。以下に報告を楽に進めるためのガイダンスがあります。
Bugzillaですべてのバグは扱わない
（「天国から来たわんちゃん」では）すべての犬は天国に行けますが
、バグの中にはBugzilla以外に報告すべきものがあります。それには以下が含まれます:
| バグの種類 | バグを報告する場所 |
|---|---|
| LibreOffice拡張機能 | 拡張機能の作者と共に |
| TDF/LibreOfficeインフラ (Webサイト、メーリングリスト、その他) | Redmine |
| LibreOfficeのビルド | 開発者向けメーリングリスト |
| LibreOfficeユニットテスト | 開発者向けメーリングリスト |
| 辞書に登録されていない単語 | 辞書のメンテナーまたはリポジトリ担当者へ |
| 翻訳の誤り | それらをBugzillaで報告することも可能ですが、Weblateに提案として追加する方が効率的です（登録不要）。 |
バグ報告を送る前に
それが本当にバグであることを確かめてください。たいていの場合、バグとは、ソフトウェアがまともなユーザが望まないことをすることです。これは、ソフトウェアがあなたの望んでない動きや要求外の動きをしたり、普通に使っている時にクラッシュすることを含みます。バグは、ソフトウェアの実行に必要以上に時間がかかったり、リソースを使う原因になることがあります。
一部の不具合は、ユーザープロファイルの破損が原因である可能性があります。OpenGL（新しいバージョンではSkiaを参照）およびOpenCLに関する問題は通常、有効なバグとみなされます。バグ報告を書く前に、OpenGLおよびOpenCLの設定による影響を確認すると、大いに役立ちます。
ある時点でバグのように見えるものは、実際には機能要求に近いものです。私たちは望む機能が実装されていなくても、理想的な世界ではソフトウェアがどのように動作すべきか知っています。幸いなことに、機能要求からバグを分離することをそれほど心配する必要はありません（訳注：Bugzillaに間違ってバグとして報告したとしても、誰かが機能要求に分類してくれるでしょう）。
あなたがLibreOfficeの使い方を知っていれば、とても役に立ちます。何が普通なのか、正しい使い方が分かります。まだ特定機能の使い方がわからない時は、バグと思われるものを報告するのに多くの時間を使う必要はありません。ユーザドキュメントを読んだり、慣れるために普段からアプリケーションを使うことを検討してください。
あなたがLibreOfficeをよく知っていて、バグの可能性があって理解できないことがある場合は、LibreOfficeユーザメーリングリスト（英語）（日本語でのユーザメーリングリスト）や Ask LibreOffice（英語）（ 日本語の公式フォーラム）に質問することができます。（訳注：こんなことが起こりましたが、これはバグだと思いますか？他の人の環境だと発生しますか？などを質問するのは有効な手段です）
あなたが見つけたものが本当にバグのようなら、次の手順を行います:
- メモを取る - バグが発生したときの状況を忘れないようにしてください。何をしていたのか、どうなることを期待していたのか、実際に何が起こったのか、そして何が問題だと分かったのか。問題の動作を再現できますか？
- 可能であれば、類似の既存のバグ報告を確認してください（ただし、あまり時間をかけすぎず、諦めるよりは重複しても報告した方が良いです）。
- Componentsにアクセスし、適切なコンポーネント（またはサブコンポーネント）を選択してください。
- コンポーネントを選択した場合：該当するサブコンポーネント、またはそのページにサブコンポーネントがない場合はExtended Helpを選択します。
- Extended Helpを選択した場合: 該当するサブコンポーネントを選択するか、該当するコンポーネントがないか不明な場合はリストの最後にある[1]をクリックする
- そのサブコンポーネントのバグ一覧が表示される。ページの一番下のEdit Searchをクリックして、必要に応じて検索を変更できる
- 問題に関するバグ報告を見つけたら、それに貢献することができる。問題に関するバグ報告が見つからない場合は、新しくバグ報告を登録する
- そのバグがUbuntuでのみ発生するか、印刷に関連する場合#さらなる情報へ移動する
- 結局、その問題に関するバグ報告が見つからないなら#バグを提出するの指示に従う
バグを提出する
ユーザの観点からみた症状が同じに見える場合でも、起こったバグごとに個別にバグ報告をします。異なるLibreOfficeのバージョンによる、異なる原因の異なる問題は、異なる人、異なるバージョン、異なる時に修正する必要があります。1つのバグ報告で、それを追跡することは不可能です。
Bugzilla へ。
サインイン
Log In を求められた場合は、Bugzillaアカウントでログインしてください。
Bugzillaアカウントをお持ちでない場合は、New Accountをクリックして作成してください。
コンポーネント
Componentの中からコンポーネントを選択します。
問題の対象コンポーネントが不明な場合は、LibreOfficeコンポーネントを選択してください。後で誰かがバグレポートを確認し、より正確なコンポーネントを選択します。（リストの重要なバグを上位に持ってくるためのバグの確認作業であるtriageの詳細については、「BugTriage」をご覧ください。）
緊急の問題（破損部分、回帰など）の場合で、あなたが開発チームを知っている経験豊富なユーザーであれば、FindTheExpertページに記載されている開発者の1人にバグレポートを割り当てることができます。
詳細
Sub-componentセクションがある場合は、サブコンポーネントを選択します。
適切なサブコンポーネントが分からない場合は、Componentsにアクセスしてください。そのページで適切なコンポーネントをクリックします。該当コンポーネントのページにあるすべてのサブコンポーネントの説明を読んでください。適切なサブコンポーネントが見当たらない場合は、Extended Helpをクリックし、そのページに記載されているサブコンポーネントの説明を読んでください。
バグが発生したアプリケーションのバージョンを選択してください。使用しているLibreOfficeのバージョンを確認するには、 ▸ を選択します。
Operating system または OS 欄には、バグが発生した際に使用していたコンピュータのオペレーティングシステムを選択してください。
Hardware セクションがある場合は、記入してください。
Severity セクションについては、あなたが経験豊富でない限り無視してください。Blockerを選択してもバグの修正が早まることはありません。Severityセクションの項目の定義を知りたい場合は、このチャートを参照してください。
latest known-working version セクションは無視して構いません。
件名
バグ報告ページの possibly related Bugs テーブル、および重複テーブルを確認し、問題が既に報告されていないか確認してください。
Subject セクション（Summaryとも呼ばれる）では：
- フィールドから既に分かっている情報は含めないでください。
- コンポーネントからサブコンポーネント名を含めてください。
- サブコンポーネント名は大文字で記載してください。
- サブコンポーネントが単語の一部と混同される可能性がある場合（例えば、UIが単語「quit」の一部である場合）、サブコンポーネントを角括弧で囲んでください。
- サブコンポーネントの使用は最大で2つまでとしてください。
- サブコンポーネントはリストの表示順に使用するものとしますが、「WIKIHELP [UI] not available in all languages」のように件名文に組み込むことができます。
- 問題をできるかぎり正確に要約してください。
- 悪い例: “File is broken.【ファイルが壊れました。】”
- 良い例: “File > Save as not available (greyed out)【メニュー ファイル > 名前をつけて保存 が使用できない。 (グレイアウト表示になっているため)】”
- サマリーでの文字列検索を容易にするため、「doesn’t」や「isn’t」のような短縮形は避け、代わりに「does not」や「is not」のような完全な形を使用してください。
- 報告書に書かれた問題がLibreOfficeのクラッシュや応答停止（「ハング」）である場合、サマリーにCRASHという単語を追加してください。これにより、これらのバグを簡単に見つけて追跡することができます。
説明と添付ファイル
Long Description または Description セクションには、問題の詳細かつ事実に基づいた説明を記載してください。
- バグを再現する手順をリストします。
- 番号付きリストを使用します。
- 具体的な操作方法を英文で記述します。例えば、「Open document」と書くのではなく、「新しい空のLibOスプレッドシートドキュメントで、メニューから ファイル > 開く（LibOダイアログ） > ファイルタイプ“文書ドキュメント” > 添付サンプルドキュメントを選択 > ダブルクリック」のように書いてください。
LinuxでプリビルドのLibreOfficeを使用している場合は、パッケージ管理システム内のLibreOfficeパッケージの正確なバージョンを記載してください。Windowsを使用している場合は、インストーラーの正確なファイル名とダウンロード元を記載してください。
- インストールされているローカライズ情報（UIの言語、ドキュメントの言語）についての情報を含めると役立つ場合があります。
- 64ビット（Linux）システム上で32ビット版のLibreOfficeを使用している場合はその旨を記載してください。
- 公式のLibreOfficeビルドでない場合は、パッケージの出所も含めてください。
期待される動作と実際の動作を記載してください。
スクリーンショットやサンプルドキュメントなどの添付ファイルを追加できます。通常、スクリーンショットを撮るにはキーボードの「Print Screen/PrtScn」ボタンを押します。オペレーティングシステムによっては、画像編集アプリケーション（WindowsではPaintなど）を開き、「編集」-「貼り付け」を実行する必要がある場合があります。
- スクリーンショットを作成する場合は、スクリーンショットを撮る前に言語を英語に切り替えてください。 ▸ ▸ ▸ で設定できます。
- LibreOffice Drawでコメントを追加したり、関連する領域にマークを付けると、スクリーンショットがより有用になります。
- 複数のスクリーンショットを添付したい場合は、すべてを1つのドキュメントにまとめて（LibreOffice Drawドキュメントにコピー＆ペースト）PDFとして添付してください。それぞれのスクリーンショットに簡単なコメントを追加し、何を示したいのかを説明してください。
- 報告しているバグを再現するサンプルドキュメントを添付する場合は、ドキュメントを可能な限り最小限にしてください。例えば、Writerのバグの場合、理想的には1つの段落だけを含むドキュメントが望ましいです。また、デバッグ時にドキュメント内のテキストが簡単に見つけられるように、バグを引き起こす文字には「AAAAAAAAAA ₂ ZZZZZZZZZZ」のように非常に認識しやすいテキストを使用してください。
- 添付ファイルは個別にアップロードするのが望ましいですが、半ダース以上のドキュメントを添付したい場合は、すべてのドキュメントを含む.zipファイルを作成し、その.zipファイルを添付してください。
- 添付ファイルがBugzillaに添付できないサイズ（1MB以上）の場合は、Experimental upload pageを使用できます。
状態
ステータスをNEWに変更するべき唯一のタイミングは、他の場所（Ask、メーリングリスト、フォーラムなど）で既に誰かがバグを確認した場合です。その場合、確認が行われたディスカッションへのリンクを提供してください。
送信
送信ボタンをクリックすると、あなたのレポートがBugzillaデータベースに追加されます。
Bugzillaへの報告がつらい場合
Bugzillaのバグ追跡システムへの報告がつらい場合や理解できないと思った場合は、こちらへ問題を投稿してください:
これらのチャンネルに問題を投稿したとしても、最終的な目標はBugzillaに良質なバグレポートを作成することです。これらのチャンネルはその助けになるかもしれません。ただし、ソーシャルメディア（Facebook、Twitterなど）で問題を報告するのは一般的に生産的ではありません。というのも、Bugzillaに適切なバグレポートが提出されることがほとんどないためです（参照：オープンソースプロジェクトを台無しにする99の方法、トップ5）。
バグを報告した後
適切な期間内（重大なバグの場合は24時間、機能改善リクエストの場合は14日間）に誰もあなたのレポートをレビューしていない場合、users@global.libreoffice.org メーリングリストやIRCチャンネル #libreoffice IRC:// で他の人にバグの再現を依頼することを検討してください。
バグにコメントを追加する
- 追加の有益な情報がない「自分も同じです」といったコメントは避けてください。
例外として、そのバグが現在までUNCONFIRMEDである場合にコメントする場合があります。その場合、再現手順を提供する（または元の報告者が提供した手順を確認する）とともに、ステータスをNEWに変更してください。ただし、明確な再現手順がない場合は、ステータスがすぐにNEEDINFOに戻る可能性があるため、簡潔で良い再現手順を見つけることが重要です。 - 「ここには1000席あり、このバグだけが移行を妨げている」といった、QAや問題の優先度に関連する追加情報がないコメントは控えてください。
LibreOfficeはオープンソースであり、特定の問題を解決するため、あなたからの支援を歓迎します。あなたができることは次の通りです：
- 自社の開発者をLibreOfficeの開発に従事させたり、そのための技術を教えることができます。私たちは彼らを指導することを非常に喜んでいます：開発者ページをご覧ください。
- 特定の問題に取り組むために個人や企業に資金提供を行うことができます - 認定開発者のリストを参照してください。
- もし少額の資金しかない場合や、特定の修正や機能強化のために他の同じ状況の方々と協力、調整、リソースを共有したい場合は、The Document Foundation にご連絡ください。
良いバグ報告
最小要件
- OS/LibreOfficeのバージョン;
- 再現可能手順を列挙する;
- 適切かつシンプルな 添付ファイル。そして
- 気づいた点/期待された結果。
良い例
- tdf#85004 - Writer: Crash when clicking the Reminder icon on the Navigation toolbar
- tdf#87907 - DIALOG: Page preview in print dialog refreshes when opening print details
- tdf#74839 - EDITING: Position of connectors connected to a group aren't updated when editing group content
悪い例
いくつかの理由により、報告が理想的とはいえないものになる場合があります。以下は、よくある問題の例です。
文章で記述する
バグ報告を何行もの文章で記述するのは、最も一般的な問題の1つです。開発者には長い段落を読む時間がありません。明確で簡潔、かつ箇条書きで番号付けされた手順として記述することが望ましいです。
1つの報告に5つのバグを書く
1つの報告には1つのバグのみを記載してください。バグをまとめたり、1つのドキュメントに関する複数の問題をリストにするのは全く役に立ちません。問題に取り組む開発者を見つけるためには、1つの問題に集中できるようにすることが最善です。複数の問題がリストされているバグは、取り組まれる可能性が低くなります。
詳細や手順が欠けている
すべてのバグ報告には、最低でも以下の項目が含まれているべきです：
- 使用しているオペレーティングシステムとLibreOfficeのバージョン ;
- 明確で再現可能な手順 ;
- 期待される結果 ;
- 観察された結果 ;
- 必要に応じてシンプルな添付ファイル
不要な情報を追加する
関連性のない詳細を大量に追加するのも、よくある問題の1つです。例としては、以下のようなものがあります。
1. 「これは邪魔な現象です」 2. 邪魔である理由の長いリスト 3. 「このバグのせいでLibreOfficeを使えません」 4. 「LibreOfficeは使いものにならない」（またはその類の表現） 5. 「これを修正しないなら競合製品を使います」
複雑な添付ファイル
添付ファイルはできる限りシンプルにしてください。例を最小限にまで絞るための時間をかけると、問題の診断が非常に容易になります。
対応する人が全部知っていると思い込む
あなたが言うまでもないと考えていることを、貢献者がその通りに理解していると思い込まないでください。各手順を明確に説明し、道筋を示してください。