この日記はMozillaのプロダクトへの貢献者としての私の成果を中心に、気になったバグやWeb界隈の話題について書いていますが、 断り書きがある場合を除き、いかなる団体のオフィシャルな見解ではありません。あくまでも個人的なものです。 Mozilla Foundation、Mozilla Corporation、及び関連企業の公式情報ではないことに注意してください。

現在、XHTML 1.0 (もどき)から、HTML5なコンテンツに修正中です。古い日記は修正が完了していませんので表示が崩れます。 順次、修正していく予定ですのでしばらくお待ちください。

もずはっく日記(2011年12月)

2011年12月5日

Firefox Inputって何?
初回投稿日時: 2011年12月05日21時42分47秒
最終更新日時: 2011年12月11日23時27分04秒
カテゴリ: Firefox Mozilla Core 雑談
SNS: (list)

いつからか忘れましたが、Firefoxのフィードバックを送信することができるようになってますが、書き込まれている内容等々から察するに、システムがよく分かってない方多そうなのでざっくりと説明をしておこうかな、と。

書き込まれた内容は一般公開されています

ここに書き込まれた内容は、一般公開されています。個人情報を書くな、という注意書きがあるのはこのためですね。もちろん、言語で絞り込んで表示することができます。

日本語版のフォームからなら、日本語で書き込んでOK

日本語について絞り込んだ結果からすると、日本語版のフォームから書いたかどうかで、内容の言語を直接見ているわけではないことが分かると思います。当たり前ですけど。ですので、日本語版のフォームから書き込む場合には日本語で書き込めばOKですね。逆に、日本語以外のフォームから(例えば英語版のベータ版から)書き込む時はその言語か英語で書かないと、ほぼ確実にその書き込みは埋没して無駄になります。

質問はFirefox Inputではなく、ユーザコミュニティのフォーラムへ

検索結果を見ると分かりますが、送信者は完全に匿名で、特定することはできません。このため、問い合わせたつもりで書き込んでいる人を時々見かけますが、絶対に返事はありません。連絡先の入力を要求もしていないのに、それは不可能です。返事が欲しいような質問はコミュニティのフォーラムに行くしかありません。

バグを報告したい場合の書き込むべきこと

私も時々、内容をチェックして自分の分かる範囲でのバグ等の報告があればbugzillaで調査したり、修正したりしていますが、どちらかというと、残念ながらごくまれです。その最大の理由は書き込まれた内容のクオリティの問題です。

140文字、という文字数制限が確かに厳しいですが、バグ報告としてフィードバックを書く場合は、問題が発生した時に、

  • 何をしたのか
  • Webサイトに関する問題なら、どのページで発生したのか

この二点は最低限、書いてもらわないと理解できません。結果だけを書いてしまわないように気をつけてください。なお、バージョンは書かなくてもUA名が自動的に記録されていますので、貴重な文字数を浪費しなくても大丈夫です。逆に言うなら、問題のあったバージョンのFirefoxから書き込んでもらわないと理解できないかもしれません。

バグについて詳細に対応が必要なら、ユーザコミュニティのフォーラムに書き込むか、bugzillaを直接利用する方が良いでしょう。

また、バグ報告を見ていて気になるのが、手元では全く再現しないバグが多いことです。

開発コミュニティの一員でもない人が積極的にバグを報告したくなるようなバグというのは大体、重大な問題が発生した時でしょう。そのようなバグが、もしどの環境でも発生しているのであれば、開発者は最優先でそのような重大なバグに取りかかっているはずです。ですので、そのようなバグを発見した場合はあなたの環境固有の問題であることを疑う方が合理的です。

ですので、そのような場合はセーフモードでの確認や、グラフィックドライバの更新等で様子を見てみるべきです。もし、特定のアドオンや、システムに常駐してるソフトウェア等が問題の原因だった場合はその原因を含めて報告しておいてもらえると非常に有益です。

バグが発生した結果はもちろん重要ですが、報告された情報が有益かどうかは、最低限、発生させるためのヒントが含まれているかどうかに依ります。もし、ひとつの報告で十分な情報が得られなかったとしても、同じ結果と共に別のヒントを提供している報告が存在すれば次第にバグの再現のさせ方が絞り込めていきます。

例えば、本体のバグではありませんが、高速リリースサイクルでアドオンの互換性が無くて困るという苦情をよく見かけますが、数字上はそのようなアドオンはほとんど無いはずです。ですので、どのアドオンが無効化されて困ったのか、どのアドオンが無効化されていなかったもののどのような機能に異常が出たのか、その情報が、そのアドオンの互換性を向上させるかもしれません。この場合も「どのアドオンなのか」という事実を確認するためのヒントが重要であることが分かってもらえるかと思います。「アドオンの互換性が失われた」という結果は必要な条件ではありますが、それだけでは価値が非常に低いのです。

バグ報告以外は有益じゃないのか

ユーザがどういったところを気に入ってて、どういった不満を持っているのか、それが表れるという点では重要です。ただ、見る側は一人で大量にポストしているのではないか、という疑いも持たなくてはいけないので、このツールがこの点で有用かどうかは利用者の方次第といったところでしょうか。

有名なサイトでの問題見つけたけど、誰かが送ってそうだからやらない方が良い?

是非報告した方が良いです。単純に見ている人達が見逃してしまっているかもしれませんし、報告の数が増えていくと、特定の環境の問題か、重大な問題ではないと思っていたとしても、そうではないかもしれない、ということが自然と分かってきます。早期解決を望むのであれば問題はどんどん書いた方が良いです。

最後に、やはり私は気軽にバグの情報を書き込むことができて、なおかつ開発者にとって検索しやすいデータベースを作成する必要があると今でも考えています。Bugzillaだと開発者以外には非常に使い勝手が悪いですし、ユーザコミュニティのフォーラムでは利用者も開発者もバグの情報を探しにくいですし、また、Firefox Inputには双方向性がないので、不明な点や、細かい確認を行うことができません。もし、そのようなサービスの構築に興味があり、サーバアプリを書ける方は私に直接連絡してもらえると助かります。

関連するかもしれないエントリ

関連するかもしれないエントリを発見できませんでしたが、無いとは限りません。

このエントリへのリンク元