適切なパッケージに登録する

Assigning bugs to packages helps direct bug reports to the developer(s) most likely to be able to help. By ensuring that this information is accurate, you increase the chances of the bug being fixed promptly. Often, it is unclear which package contains the bug, and in these cases it is appropriate to file the bug in Ubuntu. If a bug is assigned to a package which is clearly not correct, and you don't know the correct package, change it to Ubuntu.

不具合をパッケージに割り当てると、その不具合をもっとも解決できる可能性のある開発者(たち)にその不具合が報告されます。その情報が正確であることを保証することによって、不具合が即座に修正される可能性を上げることができます。不具合がどのパッケージに登録すべきかはっきりしない場合もあります。そのときは、Ubuntuに不具合を登録すると良いでしょう。ある不具合が、そのパッケージに登録すべきかどうか明らかでないにも関わらず登録されていて、どのパッケージに登録すべきかもわからない場合は、登録先をUbuntuに変更してください。

The correct package for bugs in the Linux kernel is linux, regardless of which particular package is in use (there are many packages which contain Linux kernels).

Linuxカーネルの不具合は、どのパッケージで利用されているかに関わらず、linuxに登録します(Linuxカーネルを含んでいるパッケージはたくさんあります)。

不具合の確認

If a bug is marked as Unconfirmed, it is helpful for you to try to reproduce the problem and record the results in Malone. If you are able to confirm the problem, you may change the status to Confirmed. If you are unable to confirm the problem, that is also useful information that should be recorded in a comment.

不具合に"Unconfirmed(未確認)"というマークが付いている場合、その問題の再現を試してみて、その結果をMalone(Launchpad Bugs)に報告してください。その問題を再現できたら、ステータスを"Confirmed(確認済み)"に変更してください。その問題を再現できない場合でも、有用な情報をコメントに残しておいてください。

Forwarding bugs upstream

上流(upstream)への報告

You can forward bugs to the authors of the software (upstream), if

次の場合は、ソフトウェアの(上流の)作者へ報告してください

• you made sure that the bug doesn't occur because of Ubuntu related changes
• その不具合がUbuntuでの変更によって起きていないと確認した場合
• the change is too hard to be fixed by yourself or anyone else on the team
• チームやあなた自身によってその不具合を修正することが難しい場合

If you do this, be sure to include all the necessary information, such as

報告する場合は、次のような情報をすべて含めるようにしてください

• how to reproduce the bug
• 不具合の再現方法
• which version is used (which version of dependent libraries, if the bug indicates problems there)
• 利用しているバージョン(不具合が関係していると思われるライブラリのバージョン)
• who reported it
• 誰が不具合を再現したか
• where the whole conversation can be found
• 全情報が得られる場所

Make sure to also create a bug watch in Malone for this bug.

Maloneでこの不具合の"bug watch"も作成しておいてください。

新機能の要望への対応

If you feel that the bug reported is a feature request disguised as a bug report, please introduce the reporter gently to the specification process we have. Be sure to mention the following specification resources: FeatureSpecifications, SpecSpec, SpecTemplate, and http://launchpad.net/specs

あるバグレポートが、不具合の報告ではなく新機能の要望であると思われる場合は、報告者に機能要望の方法(specification process)が存在することを丁寧に説明してください。その際、FeatureSpecifications、SpecSpec、SpecTemplate、http://launchpad.net/specsなどについても言及してください。

サポート要望への対応

If you feel that the bug reported is a support request disguised as a bug report, please introduce the reporter gently to the Support Tracker we have. Be sure to mention http://launchpad.net/support.

あるバグレポートが、不具合の報告ではなくサポートの要求であると思われる場合は、報告者にSupport Tracker(Launchpad Answers)が存在することを丁寧に説明してください。その際、http://launchpad.net/supportについても言及してください。

初期設定変更の提案への対応

If you feel that the bug reported is a suggestion for changing defaults disguised as a bug report, please kindly reroute the discussion to an appropriate mailing list or discussion forum. If this change has already been discussed and rejected, explain the reasons to the user and direct him or her to the relevant discussion for further suggestions/comments.

あるバグレポートが、不具合の報告ではなく初期設定値の変更提案で思われる場合は、適切なメーリングリストやフォーラムで議論するように誘導してください。すでに議論済みか、却下された変更である場合は、将来の提案やコメントで関係する議論を参照できるようその理由を説明してください。

重複した報告への対応

Finding duplicates of bugs is a very valuable contribution in the Bug community. Users sometimes don't know how to check if the same bug has already been filed, and sometimes they don't care. Weeding out simple ME TOO messages and aggregating information is crucial to the process of fixing a bug.

不具合の報告の重複を見つけたときは、バグコミュニティに対して大変有益な貢献ができます。一般の利用者はときどき、既に登録されている不具合を確認する方法を知らずに同じ不具合を登録してしまったり、それを直す方法を知らなかったりします。単純な「私も発生します」だけのメッセージを取り除き、情報を一つに集めることは、不具合の解決にとってとても重要な作業です。

There are quite a few measures you can take to assist with this aspect. One is to search for bugs filed for the same component. Also try to rephrase your search, and concentrate on actions and words that describe the items involved to reproduce the bug.

重複を見つけるためにはいくつかの方法があります。一つは、同じコンポーネントに登録されている不具合を見ていく方法です。他にも、不具合を生成するときの説明に使われるような単語や動作で検索する方法もあります。

Examples:

例：

• Easy ones: DAAP support is a duplicate of please enable daap.

• 簡単な例： "DAAP support"は"please enable daap"と重複しています。

• More difficult ones: plug:spdif on emu10k1 gone after breezy upgrade is a duplicate of alsa-utils cannot always restore mixer settings correctly across upgrades.

• より難しい例： "plug:spdif on emu10k1 gone after breezy upgrade"は"alsa-utils cannot always restore mixer settings correctly across upgrades"と重複しています。

If you can't find it in the list of open bugs, you could try to find it in the list of closed ones. Don't feel discouraged if you don't find duplicates quickly in the beginning. After some time, you will recognize the usual suspects and will be able to identify them more easily.

オープンなバグの一覧の中で重複が見つからなかった場合は、解決済み(closed)のバグの一覧から探してみてください。最初のうちはすぐに見つけられないかもしれませんが、気を落とすことはありません。ある程度慣れてきたら、より簡単に重複を見つけられるようになるでしょう。

• If you encounter a bug that has a terrible/unintelligible title, rephrase it so people find it more quickly.

• 荒っぽい、もしくは内容を反映していないタイトルの不具合を見つけた場合は、他の人がわかりやすいように書き直してください。

行動規範の周知

Note that the Code of Conduct applies to conversations in bug reports too. If you observe people being disrespectful, please direct them to the Ubuntu Code of Conduct.

不具合報告のやりとりの中でも行動規範(Code of Conduct)が適用されます。失礼な人を見かけた場合は、Ubuntu Code of Conduct(日本語版の行動規範)へ案内してください。

ステータスの管理

As a bug triager or developer, bug status is an important tool to categorize bugs and have a good overview of the state of packages and software.

不具合の順位を管理する人や開発者にとって、不具合のステータスは、不具合を分類しパッケージやソフトウェアの状態を把握する上で重要なツールとなります。

Here's a brief list and explanation of the various statuses:

以下はさまざまなステータスのリストと、簡単な要約です：

• Unconfirmed: Bugs start with this status. Bugs marked Unconfirmed sometimes lack information, are not ready, or are not confirmed yet. Most of them have not yet been triaged.

• Unconfirmed(未確認)： 不具合はまずこのステータスから始まります。"Unconfirmed"な不具合は、情報が欠けていたり、準備ができていなかったり、まだ確認ができていない状態を示します。この不具合の多くは、まだ順位付けがされていません。

• Needs Info: If you have to ask the reporter questions, please set this bug to "Needs Info". A regular task for Needs Info bugs is to ask back. If there are no answers after a reasonable period, close them saying "If you have more information on this bug, please reopen."

• Needs Info(情報が必要)： 報告者に質問をしたい場合は、その不具合のステータスを"Needs Info"に設定してください。"Needs Info"状態の不具合の基本的な作業は、質問に答えることです。十分な時間を待っても答えが得られない場合は、"If you have more information on this bug, please reopen"とコメントして、そのバグレポートを閉じてください。

• Rejected: Bugs marked as Rejected are closed. Be sure to triple-check a bug before you reject it.

• Rejected(却下)： "Rejected"状態になった不具合は、閉じられます。不具合を却下する場合は、十分に確認を行ってから却下してください。

• Confirmed: Confirmed bugs require somebody else to confirm. Please don't confirm your own bugs.

• Confirmed(確認済み)： 誰か他の人によって確認された不具合は"Confirmed"状態になります。自分が報告した不具合を、自分自身で"Confirmed"状態には変更しないでください。

• In Progress: If you start working on a bug, set it to In Progress so people know someone is working on the bug.

• In Progress(進行中)： その不具合を解決するために作業を開始した場合は、他の人に誰かが作業中であることを知らせるために、その不具合を"In Progress"状態にしてください。

• Fix Committed: For upstream projects this means the fix is in CVS/SVN/bzr or committed somewhere. For package maintainers it means that the changes are pending and to be uploaded soon (it is what PENDINGUPLOAD is in Bugzilla)

• Fix Committed(修正方法は報告済み)： 上流のプロジェクトにとって、このステータスはCVS/SVN/bzrなどに修正版がコミットされたことを意味します。パッケージメンテナにとって、このステータスは修正版は現在保留中(pending)で、すぐにアップロードされることを意味します(Bugzillaで言うPENDINGUPLOADです)。

• Fix Released: For upstream projects this means that a release tarball was announced and is publicly available. For package maintainers this means that a fix was uploaded. Please don't be hesitant to add a changelog as a comment, so people know which changes affect their bug(s).

• Fix Released(修正完了)： 上流のプロジェクトにとって、このステータスは修正されたソースアーカイブのリリースが告知され、公に利用可能であることを意味します。パッケージメンテナにとって、このステータスは修正版がアップロードされたことを意味します。この不具合に関係する変更点を周知するために、changelogをコメントに張り付けるようにしてください。

重要度の管理

Launchpad uses the following guidelines for assigning importance:

Launchpadでは、以下の基準に従って重要度を割り当てます：

• Untriaged: the bug report has not be triaged yet. This is the default importance for new bugs.

• Untriaged(重要度未定)： この不具合はまだ順位付けがなされていないことを意味します。新規に不具合を登録した時の初期値です。

• Wishlist: a request to add a new feature to one of the programs in Ubuntu. Use this for bugs which aren't really bugs but ideas for new features which do not yet exist.

• Wishlist(要望)： あるプログラムに対する新機能の追加要求であることを意味します。実際の不具合ではないけれども、まだ存在しない新機能のアイデアに割り当てられます。

• Low: bugs that affect functionality, but to a lesser extent than most bugs

• Low(低)： 何らかの機能性に影響する不具合だけれども、他の不具合に比べて影響範囲が狭い場合に割り当てられます。

• Medium: a functionality bug of the standard variety. Most bugs are of "Medium" severity.

• Medium(中)： 標準的な範囲の機能に影響する不具合です。多くの不具合で、重要度は"Medium"になります。

• High: a bug that has a severe impact on a small portion of Ubuntu users (estimated) or has a moderate impact on a large portion of Ubuntu users (estimated)

• High(高)： 一部のUbuntuユーザ(推測)にとって重大な影響を与える不具合、もしくは多くのUbuntuユーザ(推測)にとって中程度の影響を与える不具合に割り当てられます。

• Critical: a bug which has a severe impact on a large portion of Ubuntu users

• Critical(重大)： 多くのUbuntuユーザにとって重大な影響を与える不具合に割り当てられます。