Bug Tracker/ja
JIRAイシュー・トラッカーは技術サポートを求めるしくみではありません "'もしそれぞれのアカウント固有の問題について助けが必要であれば support resources|サポートリソース を使用してください"'
"'注意"':本サイト(JIRAも含む)へのすべての提案・投稿は セカンドライフへの貢献に関する同意規定プロジェクトにより管理されます。パッチやその他の情報を本サイトを利用して投稿した場合、あなたはこの同意規定を読み、理解して、条文の内容に同意したものとみなされます。
イシュー・トラッカー、PJIRAとは何?
パブリック・イシュー・トラッカーとは "一般向けJIRA"、"PJIRA"として知られているもので、Atlassianというツールを用いて http://jira.secondlife.com にて公開されている問題解決のためのプロジェクト管理ツールです。このサイトはセカンドライフ・オープンソース・イニシアチブが セカンドライフの様々なコミュニティから報告された案件(バグ情報や機能リクエストなど)をデータベースに入れて管理するために使用されています。あなたも、オープンソースそのものもしくは通常版のセカンドライフを使用して気がついた問題点などを投稿することができます。JIRAを使用する前にこのページの情報をよく理解するようにしてください。
どのような仕組みか?
JIRAに作成されているバグ報告は障害について、そしてもし可能であればその再現方法に関する記述で構成されています。新機能要望の場合は どのような機能が欲しいか、そしてその機能はどのように動くべきかの記述で作成されています。いずれの案件もその後、他のユーザーによってより簡潔な表現に修正されたり再現方法が追記されたりし、また同時にその案件がどの程度一般的か他のユーザによる投票が行われます。オープンソースの開発者の方であれば その案件を修正したり改善したりする "パッチ"を添付することもできます。投票は バグ・トリアージと同様、それぞれの案件の優先順位付けをする目安になります。承認された案件はリンデンの社内向け JIRAに "インポート" されます。
案件がリンデンの注意を引いたあとも継続して手助けをすることが可能です。修正・変更がなされて、一般向けリリースを待っている状態のバグは "resolved - fixed internally(内部で処理済)"とマークされます。修正・変更が利用可能な状態になったら "resolved - fixed(処理済・修正済)"とされ、ほとんどのユーザーにとって満足な状態になったと確認された時点で "closed - fixed(完了済・修正済)"とされます。
"fixed internally(内部で修正済)"と"fixed(修正済)"について補足しておきます。案件のうち他の案件と明らかに重複しているもの、再現ができないもの、誤って投稿されているもの、バグではない(仕様)であるもの、不完全なものなども解決済や完了として処理されることがあります。
セカンドライフ JIRAに関する良くある質問
抗議
JIRAイシュー・トラッカーは技術サポートではありません。くれぐれもこれらのような案件は投稿しないでください。
- 「クラッシュし続けるんだけどどうにかして!」
- 「誰かが私のお金を盗んだんです」
- 「いまいるシム、ラグが凄いんだけど」
- 「家を作る方法を教えて?」
- More examples of misfiled issues|誤って投稿されている案件の例
対策ができないような問題や手順が明確ではないもの(下記に詳細を示します)を投稿することは他のレジデントがイシュー・トラッカーを使用する際の妨げになります。 もし個別に対応を必要としている場合は サポートに連絡をとる を参照して正しい宛て先に連絡するようにしてください。なおその際にはあなたを手助けできるように 役に立つ詳細情報 を伝えるようにお願いします。
案件を報告する前に サポート情報をざっと検索すること、リンデン公式ブログに最新の情報や現状報告がでていないか見てみることをお勧めします。
もしあなたが *何回試してみても* ログインできない場合、この障害は(セカンドライフを停止させてしまうほどの)重大な問題としてリンデンは取り扱います。ただし JIRAは(個別案件ではなく)広範囲においてログインできない障害が発生している、などの問題に対応するためのものとして使用されていますので、個々に障害報告を投稿するのではなくその日の日付で投稿されている最初の「ログインできません」報告にコメントをしたり投票をするようにしてください。
ログイン方法
- https://jira.secondlife.com を開いて右上の 'Log In'リンクをクリックします。
- セカンドライフのユーザー名とパスワードをログイン画面に入力します。
- 元のメインページに戻りますが「Create Issue(案件を作成する)」などの項目やプロフィールを変更したりフィルターを作成したりするリンクが追加されているのに気がつくでしょう。
バグと新機能要望
- バグ報告をする 前に 品質保証にかかわるバグ報告をする際のガイドライン を読んでください。
- JIRAを使って新機能の提案をすることもできます。(JIRAの 投票機能で投票することは手助けすることで向上します。)(※訳注:このパラグラフは意味がよくわかりません…)
プロフィール
- JIRAユーザーはすべてプロフィールを登録することができます。プロフィールにはユーザー名(SLのアバター名)、フルネーム(私達の場合は、これもSLのアバター名です)、そしてあなたが所属している JIRAのグループすべてが含まれます。ほとんどの人は「jira-users」というグループに所属しているはずです。
- アカウントに関連付けられているメールアドレスは他の人には公開されません。このアドレスは現時点では編集したり確認したりすることはできません。セカンドライフのデータベースから直接メールアドレスを取得する機能は現在使用できません。
- セカンドライフのアカウントと一致しなくなる可能性があるため、JIRAではプロフィールを編集することができなくなっています。もしメールアドレスなどのアカウント情報を修正したい場合は secondlife.comの アカウント管理ページ へログインしてください。
詳細設定を行う
- 1ページ毎に表示する案件の数をもっと増やしたい場合、表示言語を変更したい場合はログインした後に ユーザー詳細の更新 をしてください。(メールアドレスオプションは現在使用できなくなっています。理由は WEB-58 を参照してください。
プロジェクトとコンポーネント
- 「プロジェクト」は各案件を分類分けするのに使用します。
- 「コンポーネント」はそれによってシステムのどの部分に影響を受けるかを示します。言い換えれば、プロジェクトのどの部分に問題があるか?ということです。
ビュワー (VWR) | サービス (SVC) | ウェブサイト (WEB) | その他 (MISC) |
---|---|---|---|
|
|
|
|
- セカンドライフ・ビュワー (VWR)
- セカンドライフのビュワー(クライアント)に関連する案件はこのプロジェクトとして報告します。
- 例:
- llGetDate() が誤った日付を返してくる。3月19日 10:30 PM PDTに確認した例では llGetDate() は 2007-03-20を返してきた。(コンポーネントは Scripting - スクリプト)
- 「ビデオカードのドライバを更新して以来、アバターの服がぜんぶ真っ黒で表示されるようになった」(コンポーネントは Avatar/Character - アバター)
- 「ログアウトして戻ってくると持ち物一覧が正しくない並び順になってしまう」(コンポーネントは Inventory - 持ち物)
- セカンドライフ・サービス (SVC)
- セカンドライフのサービスに関連する案件はこのプロジェクトとして報告します。
- 例:
- 「複数のアバターが同時に同じ場所にテレポートするとサーバーのパフォーマンスが落ちる」(コンポーネントは Performance - パフォーマンス または Teleport - テレポート、もしくは両方)
- 「セカンドライフ グリッドのダウンタイム(メンテナンスなどでの切断時間)後から渡しのスクリプトが外部と通信できなくなりました」(コンポーネントは Scripts - スクリプト)
- セカンドライフ・ウェブサイト (WEB)
- セカンドライフのウェブサイトに関連する案件はこのプロジェクトとして報告します。
- 例:
- 「名前にダッシュ(-)が入っていると Wikiにログインできない」(コンポーネントは wiki.secondlife.com)
- 「ログイン情報を記憶する設定にしても jira.secondlife.comにログインしようとすると毎回認証を求められる」(コンポーネントは jira.secondlife.com)
- セカンドライフ・その他 (MISC)
- セカンドライフに関連する上記に当てはまらないその他の案件はこのプロジェクトとして報告します。
- 例:
- 「TOS(Term of service = 利用規約)によるとソースコードの改変が許されていない」(コンポーネントは Miscellaneous - その他)
セキュリティ関連 -- 別名「失われた5番目のプロジェクト」
セキュリティに関連する案件は jira.secondlife.comにあげるのではなく セカンドライフ セキュリティ メーリングリスト へメールしてください。リンデンラボに直接連絡することでセカンドライフを安全に保ちましょう。
セキュリティ関連の報告の上げ方や有効な報告を上げていただいた場合の報奨金についてなどは セキュリティ関連 ページを確認してください。
「WorkingOnIt Linden」って誰?
案件が処理中の場合、担当者が「WorkingOnIt Linden」となっていることがあります。このアカウントはリンデン共有で使用しているものです。詳細は User:WorkingOnIt Linden を見てください。
JIRAそのもののバグを発見しよう!
JIRAそのもののバグを見つけた場合や新機能要望がある場合、SLのパブリック JIRAではなく Atlassian(JIRAソフトウェアの開発元)が運営している JIRAに投稿してください。Atlassianの JIRAは http://jira.atlassian.com です。
もし Atlassian JIRAへ投稿をした場合は ここ にリンクを張ってもらえると助かります。
検索
パラメータ
- パラメータについて少し知っておくと JIRAで検索するのがとても簡単になります。
- JIRAでの検索方法説明は JIRAのクエリー文法 と JIRA簡易検索 を参照してください。
検索の実行
- まず画面上部にある「Find Issues(案件検索)」リンクをクリックします。
- 次に画面左側にでている検索パネルに検索したいパラメータを入力します。
- 例えば、未解決で「avatar(アバター)」というキーワードを含んでいる案件を検索したい場合このようなパラメータになります。
- Project(プロジェクト)= all projects(プロジェクトすべて)
- Text search(文章検索)= avatar
- Resolutions(対処状況)= Unresolved(未解決)
- 別の例として、先週解決した特定のプロジェクトに関する案件を検索してみましょう。例えば、セカンドライフ・ビュワーに関するバグで 2007年の 2月1日から 2月14日の間に解決した案件を探したいとします。この場合の入力はこのようになります
- (任意:検索パネルの「New」をクリックして前に検索した内容をクリアします)
- Project(プロジェクト) = Second Life Viewer
- Resolution(対処状況)= Fixed(修正済)
- Updated After(この日付以降に更新)= January 31, 2007
- Updated Before(この日付以前に更新)= February 15, 2007
検索条件をフィルターとして保存する
- フィルターとは他の人と共有したい場合などのために検索条件を保存したものです。
- 上記の手順で検索を実施した後、検索パネルにある「Save(保存)」を押すことで検索結果をフィルターとして保存しておくことができます。
- フィルターには意味のわかる名前をつけましょう。例えば「すべてのプロジェクト内でアバターに関連する未解決の問題」など。
- これで次からは画面右上の「Filter(フィルター)」リンクをクリックすることでこの検索を実施することができます。もし複雑な条件での検索を何度も繰り返すことがあって簡単に実施する方法が欲しい場合、これによって時間も労力も節約することができます。
バグ報告と機能要望の作成
どこから手を付けたらよいのかもわからないというのなら「よりよいバグ報告のしかた」を参照してください。
最新情報をチェックしましょう
リリースノート or ベータ版リリースノートをチェックして最新のセカンドライフへの変更をチェックしましょう。新しいバグに関する情報や内部的に変更された仕様などを見つけることができるかもしれません。例えば「土地を L$0で売ることができない」というのはバグではなくて仕様です。(訳注:「誰でも買える」の設定では L$0に設定できないようになっています。)
そしてビデオカードのドライバーも更新しましょう。通常はビデオカードのハードウェアメーカーのサイト - NVIDIAオフィシャルサイト や ATIオフィシャルサイト - から入手できます。また、オメガ ドライバーズからはそれらの改変バージョンがしばしば提供されています。
その案件がすでに報告されていないかどうか調べてみましょう
案件が重複しないようにするのはとても大切なことです。内容が重複した案件が沢山あるのをより分けていくのは(リンデンにとってもレジデンツにとっても)時間・労力のムダになります。さらに本来その案件が集めたであろう注目度合いが分散してしまうことにもなりかねません。特に活発な案件は優先度が高くなるということもあるので、同じ案件・問題に労力を集中させたほうが効率がよくなります。
ログインした直後はダッシュボード画面になります。ここではいくつかのフィルターを使うことができ、登録された案件の もっとも最新の情報を調べることができます。例えば各プロジェクトの「all unresolved (unfixed or untested)(すべての未解決案件 - 未修正またはテスト待ち)」をクリックして その結果のフィルターをさらに編集、文章検索で絞り込んだりすることができます。もちろん自分用のフィルターを作成して登録することもいつでもできますし、。単純に簡易検索で検索をすることもできます。いずれの方法にしても いきなり案件を登録しようとする前にいくつかの方法で検索してみるのはよい練習になるでしょう。
(あなたが見つけて報告しようとした)案件がすでに登録されていたとしても、まだできることはいくつかあります。
- 追加情報や詳細を含んだコメントを残しましょう
- バグの場合は、他の再現方法など
- 投票することによって、それが重要だと思っていることを意思表示
特定の問題についてより良い情報が多くあれば、それだけ早く改善される可能性がでてきます。
ガイドライン
- セキュリティにかかわる問題やエクスプロイトはセキュリティチームへ直接連絡してください。それを使うことで 他の人よりも優位になったり、許可されていないスクリプトへのアクセスができてしまったり、コピー不可のものがコピーできてしまったり、あなたが作ったものではないものを transfer可や modify可にできてしまったり(これらはパーミッションバグとも呼ばれています)するもの、それにグリッド自体や他の住人のプライバシーを危険にさらすことができてしまうようなバグなど、それらをエクスプロイトと呼びます。早期解決のためには「Bug Hunters」グループに所属しているリンデンに連絡を取ってsecurity@lindenlab.comに詳細報告をメールしてください。詳細は セキュリティ問題 を参照してください。
- (持ち物が無くなったなどの)緊急を要する案件の場合、かつ、あなたがプレミアムアカウントである場合は電話かリアルタイムのテキストチャットサポートを使用してください。サポートポータル でチケットを切っておくとよりスムースに反応を得ることができるでしょう。ただし通常、チケットが確認されるまでには 7日程度かかることに注意してください。
- バグ報告をする際には、可能であればできるだけレジデントの名前や個人情報を取り除くようにしてください。もしそのバグがあなただけ、もしくはほんの一部の人にのみ発生するようであれば サポートポータル を見て 技術サポートを得るための他の方法を検討してみてください。
- 再現が容易にできれば、それだけ早く修正をすることができます。例えば「いろんなものをアップロードしようとするとクラッシュします」ではなく、このような形で報告してみてください。
- 例:
- File > Upload Image ($L10)... をクリック
- .JPGの代わりに .TXTファイル選択する
- Openボタンを押す
- 例:
- あなたが書いた内容を友達にも送ってみて彼らが再現できるかどうか確認してみてください。友達が再現することができれば私達もでききるでしょう。
- 画面を撮影したものや図、動画、クラッシュログなどの関連するファイルをアップロードしてください(上限は各10MBまで)。上記の例ではアップロードするとクラッシュしてしまうとあなたが考えているファイルをアップロードしてもよいかもしれません。
バグを報告する
JIRAに新規のバグ報告をする手順は下記の通りです:
- 画面上部のナビゲーションバーにある「Create New Issue(新規案件の作成)」をクリック。もしリンクが見つからない場合は JIRAにログイン できているかどうか確認してください。
1枚目のページでは:
- #プロジェクトとコンポーネント を参照して、登録しようとしているバグにもっとも適切なプロジェクトを選択します。
- 注意:セキュリティ関連の内容はセキュリティチームへ直接してください。セキュリティ問題。
- 「issue type(案件の種類)」で「Bug(バグ)」を選びます。
- 「NEXT(次へ)」をクリックします。
次のページでは:
- 簡潔かつ説明がキチンとされたサマリー(タイトル)を案件に付けます。
- バグの「priority(優先度)」を選びます。例えば「blocker」バグであればプログラム自体が使い物にならなくなるレベル、「small」であればほんの表面的な問題。ドロップダウンメニューの隣にあるアイコンをクリックして詳細を確認してください。
- バグの範囲を絞り込むため「components(コンポーネント)」を選びます。Ctrlキーを押しならがクリックすることで複数のコンポーネントを選ぶことができます。
- バグの影響がある「versions(バージョン)」を選びます。自分でそのバグを確認したものだけを選ぶようにしてください。なお、「first look」を選ぶときは そのバグが First Lookだけに発生している場合だけにしてください。
- 「Linden Lab Issue ID(リンデンラボ案件番号)」はあなたがリンデンではない場合は一般的に空欄のままにしておいてください。サポートチケットの番号を示したいときにはこの欄ではなく、本文中に記載するようにしてください。
- そのバグが特定のハードウェアやソフトウェアでのみ発生することに気がついた場合は「envirionment(環境)」に問題が発生したそれを記載してください。セカンドライフのメニューの中の「About Second Life」を使うと それらの情報を簡単に調べることができます。いくつかの事実をもとに何が影響しているのかを推定し問題を調べる手助けをすることもできます。(例えば特定モデルのグラフィックボードには問題があった、とか あるヘッドセットはボイス機能で不具合があるなどなど)。もし構成が影響していないようであれば この欄は空欄としてください。
- 例:「Mac OS X 10.4.1のみで発生する」「NVIDIA GeForce Go 7800だけで発生」など
- 「description(詳細説明)」には下記のような内容を記述してください
- 確実にバグを再現できる手順(バグを発生させる手順)、もしくは最低限 バグが発生する直前にどのようなことをしていたかを詳細に書いてください。手順は可能な限りシンプルかつ必要十分な記載を心がけてください。再現手順がシンプルであればそれだけ原因の特定が容易になります。
- 観察された現象・結果(バグが発生したときにどのようになるか)
- 本来期待される動作(本来どのような挙動であるべきか)
- フォーラムへのリンクやブログ記事など役に立つと考えられる情報
- 再度の注意ですが個人情報を含まないように注意して可能な限り詳細を書くようにお願いします。
- もしバグのスクリーンショットや動画、役に立つと思われるファイルなどがあれば「attachment(添付)」から添付することができます。注意:1ファイルは10MBまでです。後でファイルを追加することもできます。
- あなたがプログラマーでパッチを添付した場合は「source version(ソースコードのバージョン)」にパッチを当てたソース版を記載して「patch attached(パッチ適用済)」にチェックをしてください。
- 最後に「Create(作成)」を押せば新しい案件が登録されます。
新機能の提案
この手順はバグ報告と似ています。差異は以下の通りです。
- 「issue type(案件の種類)」で「Bug(バグ)」ではなく「New Feature(新機能)」を選択します。
- 「再現手順」ではなく希望する機能の実装詳細を記載してください。もうすでに実現されていないかどうか必ず確認してください - リリースノート を見ると過去の変更履歴を、公式ブログを読む と今後どんなことを予定しているか調べることができます。
案件に投票する
新機能や修正して欲しいと思うバグに投票することができます。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(追加情報が必要)
- 情報不足で検証できない状態。
- Cannot Reproduce(再現できず)
- このステータスは非常に多く使っています。どうやったら再現できるか詳細を提供してください。再現手順が示されない案件はしばらくしたらクローズされます。
- Misfiled(区分違い)
- イシュートラッカーで扱う案件ではない場合。
- Closed(クローズド)
- あがり。
「Fixed Internally(内部的に修正済)」と「Fixed(修正済)」の違いはなに?
これは明快です:
- 「Fixed(修正済)」は現在提供されているセカンドライフにすでに修正が反映されている状態です。
- 「Fixed Internally(内部的に修正済)」はリンデンラボ内では修正済だが一般にはまだリリースされていない状態です。一般向けに提供する前に品質チェックを行ったり、他の 分岐 と統合したりする必要があります。「ホトンド完了...近日公開!」状態と考えてください。
どうやったらお手伝いできますか?
聞いてくれてありがとう!
重複をマークしてください
以前からあってより多くのコメントや投票をされていたりパッチが提供されている案件と重複している新しい案件を見つけたら「Resolve(処理済)」で「Duplicate(重複)」としてしまってください。なおこれをするときは「Link(リンク)」を使って「This issue duplicates(この案件は重複しています)」と書いて親になるべき案件の番号へリンクしてください。これをすることで、どのバグがどのバグと重複しているのか みんな把握することができ、どんなバグが他のものより多く報告されているのかわかるようになります。よく報告される案件はこの方式によってより注目をあびることになり、また重複している案件自体も埋もれずに一箇所でまとめて管理することができ、かつ本当に重複しているかどうか確認することができます
サポート案件を処理する
これはサポート案件とバグを切り分けできる熟練した技術者のかたに任せるべき内容です。切り分けは概して難しいものです。サポート案件に見えるものはホトンドの場合「Resolved(処理済)」とするべきです。「Resolved(処理済)」ステータスの案件は報告者に戻され、どうしてこれはサポート案件ではなく すべての人において再現可能なバグであることを示すより詳細な情報を提供することが求められます。
再現できない案件を処理する
バグ報告で示されている通りに同じ環境で再現テストをしてみても再現ができない場合、そのバグは処理済とするべきです。グラフィックカードなどに左右されるバグの場合で、報告の内容と異なるビデオカードをあなたが使用している場合は注意してください。この例で言えば同じ環境でなければ評価できません。これも熟練した技術者の方が担当するべき内容です。
バグを再現テストする
これはとても重要です!もしあなたが箇条書き、ステップ・バイ・ステップでできる再現方法を見つけることができれば リンデンラボはバグ自身とバグが修正されたかどうかだけに集中することができます。バグが再現できなければ それが修正されたかどうか確認することは不可能です。報告をした人が記述している通りにテストをして、あなたが再現できた手順をステップ・バイ・ステップで詳細に記録しましょう。そして再現できたというコメントと一緒にその記録をレポートしてください。確実に再現できるバグは開発側でも優先度が高く設定されますし、バグ・トリアージチームが効率よく働く手助けになります。