From 33058f2b292b3a581333bdfb21b8f671898c5060 Mon Sep 17 00:00:00 2001 From: Peter Bengtsson Date: Tue, 8 Dec 2020 14:40:17 -0500 Subject: initial commit --- .../bugzilla-jp/guide/report/crashbugs/index.html | 24 +++++++++++++ .../guide/report/enhancement/index.html | 10 ++++++ files/ja/bugzilla-jp/guide/report/index.html | 39 ++++++++++++++++++++++ .../guide/report/memoryleakbugs/index.html | 10 ++++++ .../guide/report/renderingbugs/index.html | 14 ++++++++ .../guide/report/securitybugs/index.html | 12 +++++++ .../ja/bugzilla-jp/guide/report/uibugs/index.html | 15 +++++++++ 7 files changed, 124 insertions(+) create mode 100644 files/ja/bugzilla-jp/guide/report/crashbugs/index.html create mode 100644 files/ja/bugzilla-jp/guide/report/enhancement/index.html create mode 100644 files/ja/bugzilla-jp/guide/report/index.html create mode 100644 files/ja/bugzilla-jp/guide/report/memoryleakbugs/index.html create mode 100644 files/ja/bugzilla-jp/guide/report/renderingbugs/index.html create mode 100644 files/ja/bugzilla-jp/guide/report/securitybugs/index.html create mode 100644 files/ja/bugzilla-jp/guide/report/uibugs/index.html (limited to 'files/ja/bugzilla-jp/guide/report') diff --git a/files/ja/bugzilla-jp/guide/report/crashbugs/index.html b/files/ja/bugzilla-jp/guide/report/crashbugs/index.html new file mode 100644 index 0000000000..4dd639bbe4 --- /dev/null +++ b/files/ja/bugzilla-jp/guide/report/crashbugs/index.html @@ -0,0 +1,24 @@ +--- +title: CrashBugs +slug: Bugzilla-jp/Guide/Report/CrashBugs +--- +

クラッシュするバグを報告する

+

クラッシュするバグの報告は簡単です。

+

Firefox2/Thunderbird2以前

+

まず、Firefox2/Thunderbird2以前では、Quality Feedback Agent(日本語版だと品質フィードバックエージェント)をインストールした状態でそのバグを再現させてください。

+

インストールしているかどうか分からない場合はアドオンマネージャでTalkbackという拡張がインストールされているか確認してください。インストールしていない場合は、Firefoxを上書きで再インストールします。その際に、カスタムインストールを使用してQuality Feedback Agentをインストールしてください。

+

シャットダウン時等、特殊な状況でのクラッシュバグを除き、大抵、クラッシュ時にQuality Feedback Agentが自動的に起動します。初回起動時のみ、英語で以下のようなツールの説明等が出てきます。

+

Quality Feedback Agentの初回起動時のダイアログのスクリーンショット

+

この最初の画面と次の画面と両方でNextボタンを押し、最後に出てくる、次の画面で「Turn Agent On」にチェックを入れ、Finishボタンを押してください。

+

Quality Feedback Agentの初回起動時のダイアログの最後の画面のスクリーンショット

+

そうすると以下のような実際のリポート画面が出てきますので、そのまま何も入力せずにSendボタンを押してください。

+

Quality Feedback Agentの送信画面

+

次に、Firefoxのインストールしたフォルダにある、talkback.exeを実行してください。そうすると、今までに送信した情報のIncident IDが表示されます。

+

Quality Feedback Agentの送信済みリストのスクリーンショット

+

この中から、Bugzilla-jpに報告したいクラッシュを選択し、コンテキストメニューからIncident IDをコピーして、それを私たちに報告してください。

+

その際に、そのクラッシュさせる手順も書き込んでください。Incident IDのみでのクラッシュの報告は再現確認等が行えないためです。

+

Trunk/Firefox3以降

+

TrunkではQuality Feedback Agentに代わり、Breakpadというツールが利用されるようになりました。

+
+

Breakpadの利用手順は後日紹介予定です。

+
diff --git a/files/ja/bugzilla-jp/guide/report/enhancement/index.html b/files/ja/bugzilla-jp/guide/report/enhancement/index.html new file mode 100644 index 0000000000..ae0e1c108b --- /dev/null +++ b/files/ja/bugzilla-jp/guide/report/enhancement/index.html @@ -0,0 +1,10 @@ +--- +title: Enhancement +slug: Bugzilla-jp/Guide/Report/Enhancement +--- +

要望を報告する

+

バグとはで述べたように、Bugzilla-orgやBugzilla-jpでは製品に対する要望、機能強化もバグとして扱われます。ですが、現在、Bugzilla-jpでは要望を受け付けていません。

+

要望を挙げるのは簡単ですが、実際にそれに賛同し、パッチを作成し、更にそのコードをメンテナンスする人はまず居ないと考えてください。あなたにとって、とても有用で、素晴らしいアイデアがあったとしても、それが万人に必要とされ、受け入れられるものであることは非常に希です。(ユーザインターフェースに関するバグを報告するも参照してください。)

+

どうしても実現したい要望があり、パッチも作るし、メンテナンスもするというのであれば、Bugzilla-jpをディスカッションの場として利用されることを私たちは拒否しません。その場合、「深刻度」を「enhancement」として登録してください。また、本家への登録やそのバグの担当もあなた自身で行ってください。(担当になる権限が無い場合、Bugzilla-jpのスタッフがあなたを担当に割り振ります。)

+

つまり、私たちを頼って要望を出さないようにしてください。

+

メモ: Bugzilla-orgにバグがあり、それを追跡する目的でのBugzilla-jpへの登録はかまいませんが、そのBugzilla-orgに登録されている要望はあなた以外が登録している必要があります。

diff --git a/files/ja/bugzilla-jp/guide/report/index.html b/files/ja/bugzilla-jp/guide/report/index.html new file mode 100644 index 0000000000..80a32fc898 --- /dev/null +++ b/files/ja/bugzilla-jp/guide/report/index.html @@ -0,0 +1,39 @@ +--- +title: Report +slug: Bugzilla-jp/Guide/Report +--- +

バグを報告する

+

Bugzilla-jpにバグを報告する際にはいくかの決まりがあります。報告する人それぞれがガイドライン無く報告を行うと、開発者にとって必要な情報が不足したり、あなたが報告するバグを探している人が、うまくあなたの報告を見つけられないということが発生します。いわゆる「駄目な報告」はバグを処理する開発者にとっても、実際にそのバグで困っている報告者自身も不幸なものです。

+

ここではバグを報告する際のガイドラインと、開発者が報告してもらいたいと考えている情報をバグの種類ごとに紹介します。

+

バグを報告する際には、bugzilla-jpの画面上にある「新規登録」というリンクが移動します。報告する際にはまず以下のことについて注意してください。

+

テストは最新のTrunkでも行う

+

原則としてテストは最新のTrunkでも行ってください。

+

もし、あなたがリリース版を常用している場合、発見したバグは報告する前に最新のTrunkビルドでも再現するかどうか確認をとってください。

+

セキュリティバグ、もしくは重大なバグ以外の場合、最新のTrunkビルドで再現しない場合は既に修正済みのバグであり、リリース版で修正されることはほとんどありません。

+

バグが再現するビルドを明記する

+

リリース版でのみ再現するバグであれば、リリースバージョン(2.0.0.4等)でかまいませんが、Trunkでのテストの場合、HelpのAboutで表示されるUser Agent名(Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070622 Minefield/3.0a6pre等)を書いてください。

+

MinefieldのAbout画面

+

既に同じバグが登録されていないか検索する

+

既に同じバグが報告されている場合は報告の必要がありません。まずは検索してみてください。検索に関するヒントも用意していますので、参考にしてください。

+

見つからない場合は是非、報告してみてください。実際には重複となる報告だったとしても、そのバグが知られないままでいる方が問題です。

+

一回の報告で二つ以上のバグを報告しない

+

Bugzilla上ではバグ単位でステータスを管理します。そのため、ひとつの報告に二つ以上のバグを報告されると管理できなくなってしまいます。

+

例えば、同じWebページで二つのバグを見つけて、それを箇条書きにして一つの報告にまとめてはいけません。この場合、二つのバグをそれぞれ、別々に報告しなくてはいけません。

+

スタッフが後からバグを分割するだろうという期待はしないでください。それは非常に迷惑なことです。なぜなら、Bugzillaでは一度投稿されたコメントは修正できないため、あなたの当初の不適切な報告はそのままになってしまいます。それをスタッフが分割したとしても、そのバグを検索した第三者はそのバグが何を取り扱っているのかを知るためには分割作業が終わるところまでコメントを読む必要が出てきます。これでは、バグのデータベースとしては非常に品質の低いデータとなってしまいます。

+

つまり、最初の報告者のコメントの文面だけでバグの詳細を理解できるのが理想的です。

+

バグの再現条件を細かく調査してから報告する

+

バグの再現条件がいい加減なままで報告しないでください。

+

例えば、特定のパソコンでのみ再現する、といった報告は良くありません。私たちがあなたよりもあなたのパソコンの環境に詳しいということはありません。

+

しかし、どうしても再現条件の絞り込みが困難な場合はこの限りではありません。

+

セーフモードでもテストする

+

報告する際は、拡張を無効にした状態でも確認をしてください。あなたが報告しようとしている不具合は、拡張によるものかもしれません。報告の前に拡張をアンインストールするか、セーフモードで実行し、Mozilla製品単体で再現するかを確認してください。なお、Bugzilla-jpでは現在、拡張や(デフォルト以外の)テーマの不具合は受付けておりません。

+
+

以下、バグの種類ごとにおける特殊な注意事項については以下のドキュメントを参照してください。

+
    +
  1. Webの表示に関するバグを報告する
    2. +
  2. ユーザインターフェースに関するバグを報告する
    3. +
  3. クラッシュするバグを報告する
    4. +
  4. セキュリティに関するバグを報告する
    5. +
  5. メモリリークに関するバグを報告する
    6. +
  6. 要望を報告する
    7. +
diff --git a/files/ja/bugzilla-jp/guide/report/memoryleakbugs/index.html b/files/ja/bugzilla-jp/guide/report/memoryleakbugs/index.html new file mode 100644 index 0000000000..4559769c30 --- /dev/null +++ b/files/ja/bugzilla-jp/guide/report/memoryleakbugs/index.html @@ -0,0 +1,10 @@ +--- +title: MemoryLeakBugs +slug: Bugzilla-jp/Guide/Report/MemoryLeakBugs +--- +

+

+

メモリリークに関するバグを報告する

+

Bugzilla-jpにメモリリークバグを報告する場合は、必ず原因となるコードを特定するか、Bugzilla-orgのバグのIDと共に報告してください。Bugzilla-orgではここまで厳しい要求を報告者に求めていませんが、現象のみからBugzilla-jpにバグを報告されても、これをBugzilla-orgの特定のバグを同じバグであると判断することができないため、私たちはこれをあなたに要求するしかありません。 +

もちろん、コード上から直接発見した場合を除き、実際にそのメモリリークがどうやれば発生するのかも報告してください。 +

diff --git a/files/ja/bugzilla-jp/guide/report/renderingbugs/index.html b/files/ja/bugzilla-jp/guide/report/renderingbugs/index.html new file mode 100644 index 0000000000..cad3c72272 --- /dev/null +++ b/files/ja/bugzilla-jp/guide/report/renderingbugs/index.html @@ -0,0 +1,14 @@ +--- +title: RenderingBugs +slug: Bugzilla-jp/Guide/Report/RenderingBugs +--- +

+

+

Webの表示に関するバグを報告する

+

Webコンテンツの表示に関するバグを報告する場合、Web標準仕様に関する最低限の知識は必要になります。他のブラウザとは表示結果が違うということを理由に報告しないでください。その判断は多くの場合、間違っています。他のブラウザとの表示結果の違いはバグを見つける良いきっかけですが、それがGeckoのバグであるかどうかはWeb標準仕様に照らし合わせて検証する必要があります。つまり、Geckoにバグがあるため、表示結果が異なったという確証を私たちは仕様書に求めます。報告する際に仕様書のどこの記述に違反しているのかを明示してください。 +

なお、仕様書は有志によって和訳された仕様書でかまいません。和訳された仕様書が利用できる場合、Bugzilla-jpではよくそれを資料として利用しています。 +

ただし、根拠として挙げようとする仕様書が勧告前のものである場合は注意してください。まず、既に先行実装していること自体にバグがある場合は報告してください。先行実装の失敗は明らかにGeckoのバグであると言えるからです。そのバグは修正されなくてはいけません。 +

ですが、先行実装すべきである、して欲しい、というバグは、あなたが実作業を行う場合を除き、報告しないでください。私たちは実現するかどうか分からない要望がBugzilla-jpにあふれかえる状態を好ましい状態とは考えていないためです。 +

また、非常にシンプルなテストケースを私たちは必要としています。何百行もあるtableレイアウトのWebページを示されて、その一部の表示にバグがあると言われても、その検証には時間がかかります。あなたが報告した後に、簡単なテストケースを添付してくれることで私たちはその時間を自分の仕事に割り当てることができます。(コメント欄にソースコードを貼り付けないでください。それをテストするにはファイルを作成する必要があるため、確認を行うだけで貴重な労力を必要としてしまいます。) +

なお、ひとつひとつのバグについて個別に報告していただけるようにお願いします。例えば、ひとつのWebページで二つのバグが同時に見つかったからといって、それらをまとめて一つの報告にしないでください。なぜなら、それらのバグが同時に修正される訳ではないからです。二つのバグがある場合、バグ報告もテストケースの作成も二件に分けるようにお願いします。 +

diff --git a/files/ja/bugzilla-jp/guide/report/securitybugs/index.html b/files/ja/bugzilla-jp/guide/report/securitybugs/index.html new file mode 100644 index 0000000000..8918cc217b --- /dev/null +++ b/files/ja/bugzilla-jp/guide/report/securitybugs/index.html @@ -0,0 +1,12 @@ +--- +title: SecurityBugs +slug: Bugzilla-jp/Guide/Report/SecurityBugs +--- +

+

+

セキュリティに関するバグを報告する

+

もしあなたが見つけたバグがセキュリティに関わる(つまり、他のユーザがあなたの報告によって攻撃者から被害を受ける可能性がある)場合、あなたはそのバグを非公開のバグとして報告することができます。 +

バグを報告する際に「Bug 報告を送信」ボタンの直前にある「Mozilla/Firefoxのセキュリティ問題を扱うグループ」にチェックを入れてから、送信してください。このフラグが付けられたバグはスタッフと信頼できる貢献者の方々とあなたにしか見えなくなります。 +

もし、報告されたセキュリティバグが既にBugzilla-orgで公開されているものだったり、危険の無いものであった場合、スタッフによって通常の公開されたバグに変更されます。ですから、どちらか判断できない場合、セキュリティバグとして報告してもらった方が問題ありません。 +

あなたが同時にBugzilla-orgにも同一の内容を報告した場合、そのバグIDも報告してください。また、スタッフからそのバグのCCへの追加要請があった場合、対応をお願いします。 +

diff --git a/files/ja/bugzilla-jp/guide/report/uibugs/index.html b/files/ja/bugzilla-jp/guide/report/uibugs/index.html new file mode 100644 index 0000000000..c469d5929b --- /dev/null +++ b/files/ja/bugzilla-jp/guide/report/uibugs/index.html @@ -0,0 +1,15 @@ +--- +title: UIBugs +slug: Bugzilla-jp/Guide/Report/UIBugs +--- +

+

+

ユーザインターフェースに関するバグを報告する

+

ユーザインターフェース(以下、UI)に関するバグは、いわゆるバグと、こうあるべきだという要望の二種類に分けて考えた場合、圧倒的に要望が多く寄せられるものです。ですが、UIに関する要望を行うことは原則的にやめてください。特に、既存の動作と賛否両論が分かれるような要望は受け付けられません。 +

何故かと言うと、現在のMozilla関連製品は全て「独裁的な」開発体制によってUIの仕様が決定されています。これは過去に様々な要望を取り込む「民主的な」開発体制で失敗した経験を持っているためです。 +

Bugzilla-orgではUIに関する議論も行われていますが、これはBugzilla-jpという"架け橋"ではできないことです。つまり、UIに関して議論が行いたい場合、Bugzilla-jpという場は良い場ではありません。 +

また、この開発体制が全ての人の要望を満たすことができない、という事実に対する回答として「拡張機能(アドオン)」という仕組みが整備されました。UI仕様に対して要望がある場合、まずは拡張機能での開発を検討してください。それが適さない場合には報告していただいてもかまいませんが、そのバグはあなたがリーダーシップを発揮して、Bugzilla-orgと連携をとる必要があります。つまり、自分で開発できない場合、要望をBugzilla-jpに報告することはできません。 +

要望ではないバグを見つけた場合は、是非その現象を報告してください。報告の際にはその再現手順、実際の挙動、そしてあるべき挙動を事細かく、あなたにとって、「くどい」ぐらいに細かく報告してください。意外とUIの挙動のバグ報告というのは難しいものです。それを実感するには +bug 4102は良い例かもしれません。 +

また、それがバグであるという根拠も論理的に説明してください。例えば、そのOSの他のアプリケーションとは挙動や表示が異なっているというのは良い根拠です(それが意図的な結果であることもありますが)。 +

-- cgit v1.2.3-54-g00ecf