	警告
	こちらの記事の翻訳内容は古くなっています。最新の内容に関しては「英語版」をご覧ください。この記事を最新版に翻訳するお手伝いをして下さる方は、是非Community Translation Projectにご参加ください。 set version=2

Update Needed

This article needs an update to reflect recent changes in the base article located at Issue tracker. When you're done with the update, change the {{Help/CODE|Parent=Issue tracker|BugFixes=*}} part to {{Help/CODE|Version=2|Parent=Issue tracker|BugFixes=*}}. Thank you for your help!

貢献・寄贈

本サイト（JIRAも含む）へのすべての提案・投稿はセカンドライフ・プロジェクトへの貢献・寄贈に関する同意規定により管理されます。パッチやその他の情報を本サイトを利用して投稿した場合、あなたはこの同意規定を読み、理解して、条文の内容に同意したものとみなされます。
6px

サポートを依頼する場ではありません

JIRAイシュー・トラッカーは技術サポートを求めるしくみではありません。その状況について個別に調査が必要になるような個人的な問題は投稿しないでください。もしアカウント固有の問題について助けが必要であれば support resources|サポートリソースを使用してください。

JIRAイシュー・トラッカーではなくサポートを使う例：

"土地の月額維持費用の変更がうまく行かない"
"持ち物の一部が無くなってしまいました"
"誰かが私の L$を盗んだみたいです"

6px

パブリック・イシュー・トラッカーは http://jira.secondlife.com で運用されています。これはSecond Lifeコミュニティによって報告された各種の案件（バグや新機能要望など）を管理する、検索可能なデーターベースです。このシステムを使ってオープンソース版、もしくは通常版のSecond Lifeを使用しているときに見つけた問題について情報提供することができます。このページではそのツールの使い方について解説を行っています。

より詳細に言うと、JIRAはAtlassianとして販売されている案件プロジェクト管理ツールです。Second Lifeでは主にオープンソース関連で使用されており、"Public JIRA"、"PJIRA"、もしくは単に"JIRA"と呼ばれることが多いです。

どのような仕組みか？

主として扱われている案件は２種類あります。バグ報告と新機能の要望です。

バグ報告は不具合の詳細と、その再現方法からなります。
新機能の要望には機能の説明と、実際に実装される場合どのような動作をするべきかを記述します。

いずれの案件の場合も、興味を持った他の住人の方がより説明や再現手順を簡略化したりすることができます。
話題の案件であれば他の住人の方からの投票を集めることでしょう。
オープンソース・コミュニティのプログラマーの方であればパッチを提供したり、その案件に関連するコードそのものを修正したりすることもできます。
投票することで案件の重要度を明確にすることができます。これはバグ・トリアージュと同じです。
Linden Labに確認された案件は "imported"としてLinden Lab社内のJIRAにコピーされます。これはそのバグを調査および対策を実施する予定に入れたということです。

案件がリンデンの注意を引いたあとも案件のステータスをおうことができます：

修正・変更がなされて、一般向けリリースを待っている状態のバグは "Fix Pending"と表示されます。
変更が新バージョンのSecond Lifeで利用可能になったら "Fixed"になります。
一般的にLinden Labの品質保証チームもしくはコミュニティによって修正が完了したと確認された案件は"Resolved"または"Closed"とされます。

"Fix Pending（修正適用待ち）"と"fixed（修正済）"について補足しておきます。案件のうち他の案件と明らかに重複しているもの、再現ができないもの、誤って投稿されているもの、バグではない（仕様）もの、不完全なものなども解決済や完了として処理されることがあります。

バグ報告や新機能要望を作成する

どこから手を付けてよいかわからない場合は、まず15分のこの解説ビデオを見てみてください。

<videoflash>Jofq8ClPfNg</videoflash>

バグ報告のガイドライン

必ず！再現手順を示してください。（番号を振って！）。再現できないバグは調査することができません。容易に再現することができれば、それだけ速く修正することができます。
- 「何かをアップロードしようとするとクラッシュします」という書き方は再現手順としてはあまりよくありません。再現方法は特定の順序で書くようにしてください：
  1.「アップロード」-「画像（$L10）...」をクリックします。
  
  2.JPGではなく .TXTを選択します。
  
  3.Openボタンを押すと
  
  4.発生した現象：Second Lifeビュワーがクラッシュします。クラッシュ報告の窓も開きません。
- 書いてみたものを友達に送って、再現できるかどうか確認してもらってください。もし友達もあなたと同じように障害を再現できるなら、私たちも再現できる可能性が高いですよね？

スクリーンショットや動画、クラッシュログ、その他なんでも関係のありそうなものを添付する（1ファイル10MBまで）のも検討してください。上の例で言えばあなたがアップロードしようとしてクラッシュを巻き起こしたファイルを添付すると良いでしょう。

１つの案件で複数の事例を説明しないでください。それぞれ別の内容のバグは別の案件として管理する必要があります。

投稿しようとしてる案件が重複していないかどうか事前に検索して確認してください。

バグ報告をする場合、個人を特定するような情報や住人の名前を取り除くようにしてください。もしそのバグがあなただけ、もしくは特定の少数の人々にだけ発生するのであればサポート・ポータルなどの他の手段を検討してみてください。

その案件がすでに登録されていないかチェックしましょう

広範囲なシステム障害について案件登録をする場合は、その前にサポート・リソースを検索してみてください。またステータス・リポートの最新情報も見てみてください。

重複して案件を登録しないように注意するのはとても大事なことです。重複案件を整理してまわるのは（Linden Labのスタッフにとっても、住人にとっても）ムダな作業、ムダな時間です。本当に重要なバグや新機能要望が埋もれて注目されづらくなるという弊害もあります。より活発にやりとりがされている案件はより注目されるという原則からしても、同じ内容の問題が分かれて登録されるのは望ましくありません。

ログインするとまずダッシュボードが表示されます。ここから登録されている案件を検索して最新の情報をみることができます。例えば、show all unresolved issue（未解決の案件を全表示）を選択してそこから検索キーワードを追加して検索することができます。もちろん単純にQuick Searchボックスから検索をすることもできます。どちらでもかまいませんが、案件を登録しようとする前には必ず検索をしてみるようにしましょう！

登録しようとしていた内容がすでに案件登録されていた場合でも、まだできることがあります。

コメントを入れて、現象のさらなる詳細を追加する。
もしそれがバグであれば、他の再現方法を登録する。
これは重要だという意思表示をするために投票をする。

より多くの情報が集まれば、それだけ解決が容易になる可能性が高まります。

バグを報告する

JIRAに新規のバグ報告をする手順は下記の通りです：

画面上部のナビゲーションバーにある「Create New Issue（新規案件の作成）」をクリック。もしリンクが見つからない場合は JIRAにログインできているかどうか確認してください。
1枚目のページでは：
- #プロジェクトとコンポーネントを参照して、登録しようとしているバグにもっとも適切なプロジェクトを選択します。
- 「issue type（案件の種類）」で「Bug（バグ）」を選びます。
- 「NEXT（次へ）」をクリックします。
次のページでは：
1. 簡潔かつ説明がキチンとされたサマリー（タイトル）を案件に付けます。
2. バグの「priority（優先度）」を選びます。例えば「showstopper」バグであればプログラム自体が使い物にならなくなるレベル、「small」であればほんの表面的な問題。ドロップダウンメニューの隣にあるヘルプアイコンをクリックしてこれらの分類詳細を確認してください。
3. バグの範囲を絞り込むため「components（コンポーネント）」を選びます。Ctrlキーを押しならがクリックすることで複数のコンポーネントを選ぶことができます。
4. バグの影響がある「versions（バージョン）」を選びます。自分でそのバグを確認したものだけを選ぶようにしてください。なお、「first look」を選ぶときはそのバグが First Lookだけに発生している場合だけにしてください。
5. そのバグが特定のハードウェアやソフトウェアでのみ発生することに気がついた場合は「envirionment（環境）」に問題が発生したそれを記載してください。
  - セカンドライフのメニューの中の「ヘルプ」-About Second Life...からそれらの環境情報をコピーするのが一番の手でしょう。事象を特定することには意味があります。（Windows、Mac、Linuxのどの環境か？どのグラフィックカードを使用しているのか？特定のヘッドセットだけでボイスの障害が起きているのか？など）。もしこういった設定が問題に影響していないことがあきらかであれば、この欄は空欄にしておいてかまいません。
  - 例：「Mac OS X 10.4.1のみで発生する」「NVIDIA GeForce Go 7800だけで発生」など
6. 「description（詳細説明）」には下記のような内容を記述してください
  - 確実にバグを再現できる順序（１、２、３、、、）を記述してください。手順を特定できない場合は何がバグに影響しているように見えるかを書いてください。手順は可能な限りシンプルかつ必要十分になるように心がけてください。再現手順がシンプルであればそれだけ原因の特定が容易になります。
  - 観察された（OBSERVED）現象・結果（バグが発生したときにどのようになるか）
  - 本来期待される動作（EXPECTED）（本来どのような挙動であるべきか）
  - 再度の注意ですが個人情報を含まないように注意して可能な限り詳細を書くようにお願いします。
7. もしバグのスクリーンショットや動画、役に立つと思われるファイルなどがあれば「attachment（添付）」から添付することができます。注意：1ファイルは10MBまでです。後でファイルを追加することもできます。（より詳細な情報を得るための手法がDebug Helpに解説してあります）
8. あなたがプログラマーでパッチを添付した場合は「source version（ソースコードのバージョン）」にパッチを当てたソース版を記載して「patch attached（パッチ適用済）」にチェックをしてください。
最後に「Create（作成）」を押せば新しい案件が登録されます。

新機能の提案

この手順はバグ報告と似ています。異なっている点は以下の通りです。

「issue type（案件の種類）」で「Bug（バグ）」ではなく「New Feature（新機能）」を選択します。
「再現手順」ではなく希望する機能の実装詳細を記載してください。もうすでに実現されていないかどうか必ず確認してください - リリースノートを見ると過去の変更履歴を、公式ブログを読むと今後どんなことを予定しているか調べることができます。

セキュリティ関連の登録

セキュリティに関連する案件はセキュリティ・チームに直接報告してください。（"エクスプロイト"とは他の人より優位になることができたり、許可されていないのにスクリプトを実行できたり、オブジェクトのコピーや転送・変更ができるようになったりするバグのことです。（権限関連のバグともいいます）。その他にもグリッドそのものや住人のプライバシーを侵すような可能性があるものもこれに含まれます。
迅速に対応するためにも報告は電子メールで security@lindenlab.com に送るようにしてください。詳細はセキュリティ関連ページを確認してください。

礼儀正しく

注意：コミュニティ・スタンダードはPJIRAも含むSecond Lifeすべての範囲に適用されます。この規定に反するような方はパブリック・イシュー・トラッカーの使用を制限する場合があります。Pjiraはフォーラムでもブログでもありません。ポリシーについて検討する場でもありません。主にLinden Labのエンジニアと開発者向けのシステムです。

※※ Examples of specific behavior or actions which may result in removal from the Issue Tracker:

Using the Issue Tracker to promote a business, cause, blog, website or anything not directly related to the issue at hand.
Personal Attacks
Flaming, Trolling -- Flaming (posting a comment that is intended to incite anger or directly attack a person or persons) and Trolling (a post with an intentionally contrary opinion written with the intent of inciting or getting argumentative opinions) are not appropriate for the Issue Tracker. Please keep to the facts of the issue at hand. Posts that disregard this may be deleted.
Private Discussions - Blogging your personal opinions or off-topic rants. The issue tracker is about finding solutions to bugs and problems. We love productive feedback. Please stick to the technical details of the matter at hand.
Editing Wars - Repeated changes to a resolution, priority or classification of an issue within the issue tracker.

※※

案件に投票する

新機能や修正して欲しいと思うバグに投票することができます。view all issues by # of votes で投票数順にすべての案件を見ることもできます。JIRAでは approval voting と呼ばれる投票システムをとっています。各案件に 1票、いくらでも好きなだけの案件に投票することができます。

投票の結果は優先順位の決定プロセスとして使われます。注意して欲しいのは必ずしも投票数が多いものが常に優先して処理されるわけではない点です。実現可能性を評価したり実装するための工数を見たりした結果によって投票数が少ないが容易に実現できるものが先に処理されることもあります。

時々、案件の処理状況をチェックしてください

リンデンラボは jira.secondlife.com にあげられる案件を定期的にレビューしています。技術チームはまれに追加情報を報告者の方や他の協力者の方々へ求めることがあります。JIRAの電子メール機能は使えないようになっていますので時々自分が作成した案件やコメントを入れたものをチェックするようにすると良いでしょう。

内部的に問題が解決した場合、外部サイト（パブリックJIRA）にも結果が反映されます。ですので自分の案件を定期的にチェックするようにしてください。

※訳注：「watch」機能を使うと案件に変化があった場合に登録しているメールアドレスに通知がきます。

案件ステータス

使用可能なステータス

リンデンラボが使用している各ステータスの意味を説明します。

Open（オープン）: 案件が担当者による処理待ちの状態。担当者は案件を修正したり、「Resolved（処理済）」報告者へ差し戻したりします。

In Progress（処理中）: 開発者が作業中であることを示します。

Reopened（再オープン）: オープンと同じです。

Resolved（処理済）

報告者に案件が差し戻された状態です。対処状況にもよりますが、クローズされてはいないが檻に入った状態です。再度案件をオープンする（Reopen）するかクローズするかは報告者しだいです。

Fixed（修正済）: そのバグが一般向けリリースにおいて修正された状態です。
Fixed Internally（内部的に修正済）: 近々公開予定のコードで修正済の状態です。
Won't Fix（修正不可）: 修正することができないものとして担当者が認識した状態です。
Duplicate（重複）: 同じ問題や提案がすでに他の案件ででており重複している状態です。
Needs More Info（追加情報が必要）: 情報不足で検証できない状態。

Under Advisement: this is used by Linden Lab for issues that tend to fall more in the category of Policy rather than being just a technical bug. This is used to let the community know that the Pjira has been viewed and is being discussed.

Cannot Reproduce（再現できず）: このステータスは非常に多く使っています。どうやったら再現できるか詳細を提供してください。再現手順が示されない案件はしばらくしたらクローズされます。
Misfiled（区分違い）: イシュートラッカーで扱う案件ではない場合。

Closed（クローズド）: あがり。

Frequently Asked Questions

See the Issue tracker/FAQ for answers to common questions!

Searching

See the Issue tracker/Searching page for more help!

どうやったらお手伝いできますか？

聞いてくれてありがとう！

重複をマークしてください

以前からあってより多くのコメントや投票をされていたりパッチが提供されている案件と重複している新しい案件を見つけたら「Resolve（処理済）」で「Duplicate（重複）」としてしまってください。なおこれをするときは「Link（リンク）」を使って「This issue duplicates（この案件は重複しています）」と書いて親になるべき案件の番号へリンクしてください。これをすることで、どのバグがどのバグと重複しているのかみんな把握することができ、どんなバグが他のものより多く報告されているのかわかるようになります。よく報告される案件はこの方式によってより注目をあびることになり、また重複している案件自体も埋もれずに一箇所でまとめて管理することができ、かつ本当に重複しているかどうか確認することができます

サポート案件を処理する

これはサポート案件とバグを切り分けできる熟練した技術者のかたに任せるべき内容です。切り分けは概して難しいものです。サポート案件に見えるものはホトンドの場合「Resolved（処理済）」とするべきです。「Resolved（処理済）」ステータスの案件は報告者に戻され、どうしてこれはサポート案件ではなくすべての人において再現可能なバグであることを示すより詳細な情報を提供することが求められます。

再現できない案件を処理する

バグ報告で示されている通りに同じ環境で再現テストをしてみても再現ができない場合、そのバグは処理済とするべきです。グラフィックカードなどに左右されるバグの場合で、報告の内容と異なるビデオカードをあなたが使用している場合は注意してください。この例で言えば同じ環境でなければ評価できません。これも熟練した技術者の方が担当するべき内容です。

バグを再現テストする

これはとても重要です！もしあなたが箇条書き、ステップ・バイ・ステップでできる再現方法を見つけることができればリンデンラボはバグ自身とバグが修正されたかどうかだけに集中することができます。バグが再現できなければそれが修正されたかどうか確認することは不可能です。報告をした人が記述している通りにテストをして、あなたが再現できた手順をステップ・バイ・ステップで詳細に記録しましょう。そして再現できたというコメントと一緒にその記録をレポートしてください。確実に再現できるバグは開発側でも優先度が高く設定されますし、バグ・トリアージチームが効率よく働く手助けになります。

Sorting issues in the wrong categories

If an issue is in the wrong category (i.e. a VWR issue that belongs in SVC) it should never be resolved as "misfiled." Instead, a comment should be left on WEB-566 listing the issue and where it should be belong. A JIRA volunteer will make sure it gets moved to the appropriate place.

Related resources

Want to learn more about our Issue Tracker?

Issue Tracker Forum Transcript - Info from Rob and Aric Linden on why we have an Issue Tracker, its behind-the-scenes workings, and answers to various questions.
JIRA user's guide by Atlassian, creaters of JIRA

Bug Tracker/ja

Contents