Bug Tracker/ja

/ja

	警告
	こちらの記事の翻訳内容は古くなっています。最新の内容に関しては「英語版」をご覧ください。 この記事を最新版に翻訳するお手伝いをして下さる方は、是非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イシュー・トラッカーは技術サポートを求めるしくみではありません。その状況について個別に調査が必要になるような個人的な問題は投稿しないでください。もしアカウント固有の問題について助けが必要であれば サポートリソース を使用してください。 JIRAイシュー・トラッカーではなくサポートを使う例： "土地の月額維持費用の変更がうまく行かない" "持ち物の一部が無くなってしまいました" "誰かが私の L$を盗んだみたいです" 6px

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

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

どのような仕組みか？

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

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

1. いずれの案件の場合も、興味を持った他の住人の方が より説明や再現手順を簡略化したりすることができます。
2. 話題の案件であれば他の住人の方からの投票を集めることでしょう。
3. オープンソース・コミュニティのプログラマーの方であればパッチを提供したり、その案件に関連するコードそのものを修正したりすることもできます。
4. 投票することで案件の重要度を明確にすることができます。これはバグ・トリアージュと同じです。
5. 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まで）のも検討してください。上の例で言えばあなたがアップロードしようとしてクラッシュを巻き起こしたファイルを添付すると良いでしょう。 １つの案件で複数の事例を説明しないでください。それぞれ別の内容のバグは別の案件として管理する必要があります。 投稿しようとしてる案件が重複していないかどうか事前に検索して確認してください。 バグ報告をする時には、個人を特定するような情報や住人の名前は載せないようにしてください。もしそのバグがあなただけ、もしくは特定の少数の人々にだけ発生するのであればサポート・ポータルなどの他の手段を検討してみてください。

最新情報をチェックしましょう

1. 案件を報告する前に更新情報をチェックして最近の変更事項をチェックしましょう。往々にして既知の問題として把握されている事項や、意図した変更であることがあります。例えば「0L$で土地を販売することができません！」というのは意図した制限であってバグではありません。（訳注：「誰でも買える」の設定では L$0に設定できないようになっています。）
2. もう１点、ビデオドライバーは最新のものになっているかどうかもチェックしてください。より上級者の方向けにはOmega Driversという改変バージョンのドライバーもあります。

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

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

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

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

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

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

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

バグを報告する

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

1. 画面上部のナビゲーションバーにある「Create New Issue（新規案件の作成）」をクリック。もしリンクが見つからない場合は JIRAにログイン できているかどうか確認してください。
2. 1枚目のページでは：
   • #プロジェクトとコンポーネント を参照して、登録しようとしているバグにもっとも適切なプロジェクトを選択します。
   • 「issue type（案件の種類）」で「Bug（バグ）」を選びます。
   • 「NEXT（次へ）」をクリックします。
3. 次のページでは：
   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（パッチ適用済）」にチェックをしてください。
4. 最後に「Create（作成）」を押せば新しい案件が登録されます。

新機能の提案

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

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

セキュリティ関連の登録

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

礼儀正しく

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

イシュー・トラッカーから排除されてしまうような言動・行動の例：

• イシュー・トラッカーを案件とは関係のないビジネス・ブログ・ウェブサイトなどの宣伝の場として使用する。
• 個人攻撃
• フレーミング、トローリング -- フレーミング（個人または特定の団体を攻撃する、相手を怒らせることを目的としたコメントを書き込む行為）またはトローリング（論争を巻き起こすこと、誘発することを目的として恣意的に反対する意見を書き込む行為）はイシュー・トラッカーにふさわしくありません。案件に関連する事実のみに集中するようにしてください。これに反するような書き込みは削除されます。
• 個人的な議論 -- 自身の個人的な意見や不満を書き込む行為。イシュー・トラッカーはバグや問題点の解決方法を見つけるための仕組みです。常に前向きな姿勢で、技術的な観点で事象を取り扱うようにしてください。
• 編集合戦 -- 案件のステータス、重要度、区分を執拗に編集し合う行為。

案件に投票する

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

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

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

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

内部的に問題が修正された場合、イシュー・トラッカーもそのむねステータス更新されます（タイミングによっては次バージョンがリリースされる前に更新が行われることもあります）。ですので定期的に自分の案件をチェックするようにしてください。

案件ステータス

使用可能なステータス

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

Open（オープン）

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

In Progress（処理中）

開発者が作業中であることを示します。

Reopened（再オープン）

オープンと同じです。いったんはクローズされた案件ですが、まだ問題が解決していないとして再度注意をひくべくオープンした状態です。

Resolved（処理済）

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

Fixed（修正済）

そのバグが一般向けリリースにおいて修正された状態です。

Fix Pending（修正適用待ち）

近々公開予定の版で修正が適用される予定の状態です。

Contact Support（サポートに連絡）

サポートが取り扱うべき内容が登録されています。チケットを切ってサポートに依頼してください。

Won't Finish（修正不可）

直近では修正することができない、もしくは修正すべきではないと担当者またはLinden Labが判断した状態です。

Duplicate（重複）

同じ問題や提案がすでに他の案件ででており重複している状態です。

Expected Behavior（仕様）

案件で説明されている内容が期待される動作であって、バグではない場合。

Needs More Info（追加情報が必要）

情報不足で検証できない状態。詳細情報を追記してください。さもなければこれ以上の調査ができませんという状態。

Under Advisement（審議中）

Linden Labによって使用されるステータスです。案件の内容が技術的というよりもポリシーに関わる場合に使用されます。PJiraに上がった案件が確認されて議論されている状態だということを示すために使用されます。

Cannot Reproduce（再現できず）

説明されている手順に従っても問題が再現できない状態です。別の条件か設定・操作が問題の再現に必用なのかもしれません。問題を再現するためのより詳細な情報提供してください。再現手順が示されない案件はしばらくしたらクローズされます。

Misfiled（区分違い）

イシュートラッカーで扱う案件ではない場合。

Closed（クローズド）

終着駅。完了です。

よくある質問

一般的な質問についてはイシュー・トラッカーによくある質問を参照して下さい。

検索

検索の仕方の詳しい手順はイシュー・トラッカーの検索方法を参照して下さい。

Linden Labがバグ対策をする手助けをしたいのですが？

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

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

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

サポート案件を処理する

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

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

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

バグを再現テストする

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

間違ったカテゴリに登録されている案件を修正する

カテゴリが間違って登録されている案件（例えば SVCに入れるべきものが VWRに登録さているなど）は「misfiled（区分違い）」にするのではなくWEB-566のリストに「本来どこにあるべきか」をコメントしてください。JIRAボランティアがその後、区分の修正を行います。

関連資料

イシュー・トラッカーについて詳しく知りたいですか？

• Issue Tracker Forum Transcript - RobとAric Lindenが、なぜイシュー・トラッカーを設置しているのか、システムはどのようにして運用されているのか、など様々な事柄について回答しています。
• JIRA user's guide -- JIRAの開発元であるAtlassianによるユーザーガイド。