Mozilla 勉強会＠東京 8thで話しました
さる12月1日に、Mozilla 勉強会＠東京 8thでお話しさせて頂きました。発表の内容でお聞き苦しい点がありましたら申し訳ありませんでした。
今回は「Mozillaへのバグ報告とバグの修正ステップを通じて、contributeへの間口を広げる」というテーマを設定しました。単にcontributeへの間口を広げるだけであれば、バグ報告のパートは要らないのですが、あえて追加した理由としては、この機会を通じて、バグ・不具合報告のやり方のたたき台のようなものを作成しておきたかったからです。
ユーザーとしてアドオンを使ったりFirefox自体を使ったりする上で、不具合報告をする機会はそれなりにありますが、「具体的にどのように不具合報告をすればいいのか？」というノウハウのようなものは、非エンジニアはもちろん、エンジニアの方でも知識レベルがまちまちです。各種勉強会では、開発インテグレーションやソフトウェア設計に関する発表は多々見られますが、「バグ報告」という初歩のそのまた一歩となると数も少なく、まったくの初心者の方向けのガイドライン足りうる資料を探すのは決して容易ではありません。 その結果、「バグ報告してください」との言葉だけが一人歩きし、無用のバグ報告ばかりが行われる事で、問題の本質を探るまでのコミュニケーションコストばかりがかさんでしまい、結果、報告者・修正者ともに余計な時間を過ごすというのはあまりにもバカバカしいと言えます。
いいアドバイスをもらうための相談の仕方 - ククログ にもあるような、アドバイスにおいて必要な情報をすべてうまいこと伝えるためにはどのような点を押さえておくべきなのか？ ということを、最低限のテンプレートとして参照できるように意図して作成しました。
Mozilla Firefoxは完全なリポジトリもMLもBTSもIRCもちゃんと公開されているOSSではありますが、非社員であるボランティアのコントリビューターや普通のユーザーにとっては公開される情報量の多さ故、新規機能実装案の初期から議論に参加するのは結構難しいプロジェクトでもあります。そうした特性上、どうしてもユーザーが気づくのは実装が煮詰まってから、あるいは完成後になることが多く、実装経緯のログも簡単に読める分量を超えているため、適切なツッコミのコメントがなされない、あるいはコメントが上がってもスルーされるということがままあります（ユーザーが触れるUI関連の開発では、UI開発という作業の性質もあるのでしょうが特にその傾向が感じられます）。
ですが、その一方でbugzilla.mozilla.orgというBTSは民主的ないしオープンであり、真っ当な意見の声が複数集まれば、ちゃんとそれなりに意見として（短期的・長期的かはケースバイケースですが）影響力を持つという文化が存在します。ですので、英語という言語の壁はありますが、可能であればbugzilla.mozilla.orgやMLフォーラムになるべく意見を明確に申し立てることにチャレンジしてみるといいと思います。人間の仕事ですので、観測圏外で騒いだところで、その騒ぎ声は存在しないのと同義になってしまいます。
あと、番外編としてLTで話した Browser Debuggerですが本当に便利です。これさえあればFirefoxのchrome領域に絡むパートのデバッグが一網打尽というわけではないのですが、コードリーディングをして当たりを付けた箇所にブレークポイントを張り、実際に動かしてそこで止めてスタックトレースを閲覧できるまでのステップがVenkmanに比べて簡単になりました。幸せです。不具合や仕様上の問題、未実装箇所なども幾つかありますが、結構楽しいです。願わくばこれがtoolkitに移動して、thunderbirdなどでもしようできれば良いのですが。 とりあえず騙されたと思って使ってみるといいと思います。
