Developing New Mozilla Features

Mozilla へ新機能を提供するためのヒント

コードベースとコーディング手順を学んでから機能の開発に着手してください

スケジュールに修得時間を含めてください。 Mozilla は複雑なコードベースです。私たちの移植性の要件は経験豊富な開発者にとっても新奇に映るかもしれません。クロスプラットフォーム部品モデル (“XPCOM”) は COM に類似していますが、あなたは自分のプロジェクトが進み過ぎない内に、確実に十分にそれを使いこなしたいと思うでしょう。そして当然誰もが共生できるように、私たちは 一揃えのコーディング手順 を備えています。もしチームの中に Mozilla の世界についてすでに詳しいメンバーが一人ないし数人いれば、生活はより一層楽になるでしょう

あなたの開発する機能の分野において現在活躍中の開発者との関係を深めてください

メールに重要な新機能を追加したいならば、活動中のメール開発者達を支援することに時間を割いてください。バクがあれば除去について彼らと相談してください。そしてバグを取り除いてください。あなたの QA チームのメンバーにも加わってもらってください。ある分野に精通すると、あっと言わせるほど思いもよらない仕事をして、ドキュメント化してください。開発者に感謝され、支援活動において本当に優れた人間として知られるようになります。私たちの コードレビュー方法 を学んでください。あなたのチームの誰かに CVS へのアクセスを取得 できる程の Mozilla の専門家になってもらってください。

あなたが「本気」であることを活動中の開発者が分かるようにしてあげてください

つまり、あなたが Mozilla に通じていること、あなたのチームが製品を送り出そうとしていることを理解してもらう必要があります。開発者が受け取るメールは多く、すべてが役に立つとは限りません。 Mozilla への関心と興味には感謝致しますが、開発者は時間の優先付けをする必要があります。あなたが活動に関心があり貢献できる有能な開発者であると教えてあげてください。上記提案 2 を実行されているならば、一層簡単なことです。

常時担当として mozilla.org CVS レポジトリーへ従事するメンバーとして、チームの誰かを指名してください

チームの誰かがソースツリーに深く関わることになれば、あなたの開発する機能はより簡単に統合されます。マイルストーンのリリース時にのみツリーを参照するのは、もしあなたが重要な開発行為を遂行しているならば危険です。変更されてしまった内容のために、余分な仕事を負うこともあります。そして、時期を逸して設計に自分の思想を反映出来なくなるかもしれません。この事で絶対的にリソースが不足しているならば、統合には時間的な余裕を見込んでください。

あなたが開発している内容に関わっている開発者を是非とも中核的コーディングに参加させるようにしてください

それが出来ないならば、 mozilla.org のスタッフに知らせてください。そうすれば、私たちが支援するようにします。提案された機能の優先度が低いとか、全く必要でないと開発者に思われたり、またあなたがコードベースと Mozilla のコーディング手順を十分理解しいて、開発者があなたに多くの時間を割いてくれる事に値する旨を証明しなかったりすると、あなたは注意を払ってもらえないこともあります。開発者が間違いをしてスタッフがそれを修正しようとしてあなが呼ばれることもあります。また、mozilla.org のスタッフと開発者が、あなたのプロジェクトを支援するのに時間をかける事を意味がないと判断することもあります。これは、辛いケースでしばしばあって欲しくないと思います。しかし開発者は貴重な存在であり、その時間はおそらく私たちのリソースの中で一番重要なものです。

また、開発者が過労気味になったり、休暇に入ったり、へまをする事もあります。当然完全と言うわけには行きませんが、プロジェクトを成功させるのにこれらの事が出来るだけ発生しないようにする必要があります。万が一発生した場合は、連絡をください。問題の開発者と話をして、支援できる他の人を探し、あなたのプロジェクトの仕事を向上させるように努力します。最終的にあなたは十分軌道に乗って私たちを必要としなくなり、自分自身の支援部隊を見つけるこが出来ます。それでも、私たちは開発者が変わらずに協力者に応えているかどうかを知っておく必要があります。しかしあなたは、時々発生する問題をただ誰かに聞くことで処理できるようになっているでしょう。

オープンに設計してください

適当なニューズグループに計画を送ってください。回答が無いときは、提案の登録が上手く行ったかどうかをダブルチェックしてください。

あなたの開発する機能が処理可能な大きさのパッチで、実装されレビューされるように厳密に設計するようにしてください

最初にコア要素を実装して提供し、次のパッチでそれを拡張させることが出来れば一層望ましいことです。大きな範囲でしか機能の実装とレビューが出来ないと判断するならば、あなたの知り合いとなった適当なニューズグループおよび（または）開発者に設計の援助を要請してください。

あなたの開発する機能を処理可能な大きさのパッチで提供することが出来ずに、500K のパッチを送れないならば、パッチのチェックインの準備が整うまでに数ヶ月に渡るレビューと改訂を覚悟してください

実際そんなにかからないかもしれません。しかしあなたのチームが機能を数ヶ月かけて作り上げたのであれば、コードを知らないチェック担当が仕事を完了するのに時間を要することになります。機能をバイトの大きさ単位で設計出来なければ、おそらく同じようにバイト単位でレビューすることも出来ないでしょう。チェック担当はチェックインを許可するコードは軽く眺めるだけで OK を出さないで、完全に理解して欲しいと思います。もしあなたが完ぺきな仕事を成し遂げたとしても、他の様々な要求も抱えながらボリュームのあるパッチを消化するのに集中する事は、時間がかかります。完全な人間はいませんので、改訂が必要になる可能性は多いのです。

大きなパッチがあるならば、チェック担当になる可能性のある人に、いつ調べることになるかを知らせてください

時間がないのであれば、マイルストーンのデータ用の Mozilla ロードマップをチェックアウトして、あなたの開発する機能が旺盛な活動期にぶつかるかどうか調べてください。もしぶつかって、あなたの開発する機能が一般的な関心の対象とならなければ、しばらくは優先度が低い状態に置かれると思ってください。

mozilla.org スタッフに連絡を取ってください

[email protected] はプロジェクト管理の問題では有益な連絡先となります。あなたがしている事をお知らせください。もしリソースを見出せるならば、プロジェクト管理について mozilla.org とのチームの連絡役を指名してください。

コードレビュー FAQ の内容の詳細を理解してください

レビューとスーバーレビューには時間が必要です

チェック担当の要求どおりにコードを改善するのにも時間がかかります。コーディングの品質が悪ければまた時間を浪費します。私たちはチェックインする前に、コードの一貫性を改善するのに時間をかけることにしています。チェックイン前であれば、痛い目を見るのは開発者とチェック担当者のみで済みますが、一度チェックインされるとツリーに関わるすべての人が痛い目に遭います。この開発スタイルに従っていますが、新参者と彼らの機能が行き場を失わないように、私たちが用心する必要があると思います。もしあなたが特にひどい経験をしていたり、私たちのやり方を向上させる方法について提案をお持ちならば、どうか mozilla.org のスタッフにお知らせください。