Mozilla 開発ロードマップ

Mozilla 開発ロードマップへようこそ。1998年に、標準準拠、モジュール性、移植性という Mozilla の新しいコースを定めた オリジナルのロードマップ 以来、本稿はロードマップの三回目の大幅な更新になります。ひとつ前のロードマップ には、Mozilla 1.3 までのマイルストーンと開発のルールが記載されており、古いロードマップへのリンクもあります。

私たちは長い道のりを歩んできました。Mozilla 1.0 宣言 で定められた必要条件を満たした Mozilla 1.0 マイルストーンを完成させ、これは質の高いリリースであるとともに、より安全な開発と派生製品をリリースするための安定したブランチとして、コミュニティのみならずより広い世界に提供されました。Mozilla 1.0 から生み出された Mozilla ベースのプロジェクトと製品のリストが Mozilla Hall of Fame にあるのでご覧ください。

1.0 から 1.3 までの中心的な「トランク」開発系では、標準準拠であり、モジュール性があり、移植可能な、1998年に始まったコードベースにおいて、長い間懸案となっていた多くの欠陥を修正する事により、0.9.x マイルストーン期に開始されたフットプリント ［訳注：割り当てられた後、解放されないメモリ領域の大きさのこと］ やパフォーマンス関連のプロジェクトを更に進行させました。また私たちは、タブブラウジングやポップアップブロッキング、http://paulgraham.com に着想を得たベイズ式スパムフィルタなど、素晴らしい仕様の登場を目の当たりにしました。さらに、より高速で、ブラウザに焦点を絞ったプロジェクトである Phoenix や Camino （かつての Chimera） も登場しました。

新しいロードマップ

しかし、1.0 以降に私たちが行ったような段階的な開発は、健全なオープンソース・プロジェクトにとって充分なものではありません。より良い未来への道を描いた新しいロードマップが Mozilla に必要な事は明らかです。以下に提案するのは、独立したアプリケーション・プロセス間で共有可能な Gecko Runtime Environment (GRE) に基づいた新しいアプリケーション・アーキテクチャです。理論的根拠と予想される代償について議論する前に、まずその意味するところと主な構成要素を以下に述べます。

1. Mozilla のデフォルトブラウザ・コンポーネントを XPFE に基づいた Navigator から、スタンドアロンの Phoenix ブラウザに切り替えます。 注意： Phoenix のユーザインターフェースは、全て XUL を使って定義されています。ですので、Pheonix を採用するからといって、XUL を捨てるわけではありません。Phoenix のような高速でクロスプラットフォームなアプリケーションの強固な基礎として XUL が適役である事を私たちは実証しているのです。

2. すでに Minotaur として始まっている、Pheonix に相応するスタンドアロンなメールアプリケーションの開発をさらに進めます。ただし、Pheonix に使用されている新しい XUL ツールキットを基礎とします （この形式のものは Thunderbird というコードネームで呼ばれています）。 注意： Phoenix のツールキットは、カスタマイズ可能なツールバーのような追加機能を備えていますが、XPFE ツールキットと互換性を保った再実装です。私たちは新たな C++ GUI ツールキットを開始しようとしているのではなく、単に次世代の XUL ツールキットへと移行しようとしているだけです。

3. Mozilla 1.4 マイルストーンは、安定した開発系としての 1.0 ブランチを置き変えるものとして供給し、その後 1.5/1.6 の開発期間に、よりリスクの高い変化を加えます。1.4 の後の大きな変化には、Phoenix と Thunderbird への切り替えと、次の二項目を積極的に開発する事が含まれます。

4. Gecko レイアウト・アーキテクチャの根本的なバグを修正する事によって、メンテナンス性、パフォーマンス、そして拡張性に優れた将来像への道を開きます。

5. 無制限の CVS アクセス権を持つハッカーの集団が関わるというオーナーシップ開発モデルを捨てて、強いリーダーシップと明確な委任制度によってモジュールが強固に守られるという、オープンソース界でより一般的な開発モデルへの移行をさらに進めます。例えば、NSPR や JavaScript、最近の主なマイルストーンでの Gecko、そして Phoenix のように。

これら新しいロードマップの要素の背後にある理由は、量よりも質を追求する事にあります。成果の数は少なくなりますが、その質は向上しなければなりません。そして、充分な拡張機構があれば、(例えば) メインメニュー項目のようなユーザインターフェースの整理をめぐってコミュニティ内で論争する事もなくなるでしょう。

もう一つの拡張性の例として、ユーザインターフェース以外のものをあげましょう。Gecko は、実験的または制限付きであっても、新しく台頭してきた XML や関連する標準をサポートする必要があります。その際に、全員が nsCSSFrameConstructor.cpp をハックしなければならないようでは駄目です （そして、この巨大なファイルは、1.5、1.6 さらにそれ以降の開発期間で徐々に変更を行って、削除あるいは大幅に単純化する必要があります）。良い基本 （HTML や XUL ウィジェット、SVG） とスタイリングおよびコンポジションツール（CSS、XBL）を利用すれば、新たな C++ コードの爆発的増加やレンダリング・オブジェクトの肥大化を防げる筈です。

考察

1998 年 3 月 31 日、Netscape がオリジナルブラウザのコードベースをオープンソースとして公開した時に、人々の期待、製品の計画、チェックインの権限、そして実際のコードの構造、これらの全てが、Netscape 4 の時代に "Communicator" として初めて大々的に PR された巨大なアプリケーション・スイート （ブラウザ、メール、エディタ） を継続させる方向に向かっていました。この「多機能製品」 [訳注：原文は、スイス・アーミーナイフ = 十徳ナイフ] 方式は、1998 年の末に私たちが Gecko、XPFE、 および スクリプト可能な XPCOM インターフェース で Mozilla をリセットした時にも継続されました。この間に、もちろん Netscape は、主として給料を支払われている貢献者およびインフラという形で、 Mozilla に対して非常に寛大なサポートを行なってきました。

その結果は、ユーザインターフェースのフロントエンドに膨大なバックエンド・モジュールを備えた、機能豊富で複雑なアプリケーションでした。この野心的な統合から、XUL や XBL などのたくさんの良い成果が得られました。

それでも、もし単に「ブラウザを書き直す」という事が目的であれば、XUL は経済的なものではなかったでしょう。まさしく 意図された通り に、一度クロスプラットフォームのフロントエンドを書けば、ネイティブな OS のツールキットを元にしたフロントエンドを最低三つのプラットフォームに対して書かずに済みました。しかしその結果として、ネイティブなブラウザだけのフロントエンドとブラウザの１つのバックエンドを開発するのに要するのと同じくらいの人数と時間を費やして、スイートの様々なアプリケーションを作成したり、各アプリケーションのコンポーネントを統合したりしているのです。

上記した批判が成立するには、Mozilla と主要な貢献者たち、例えば Netscape が、メール・ユーザエージェントやニュースリーダーや HTML エディタや、アプリケーションの枠組みを開発せず、ブラウザだけを開発する事に甘んじていられた、という仮定が必要です。今から振り返っても、「ブラウザだけ」が充分であったとは思えません。XUL は、価値のあるクロスプラットフォームのメールと composer アプリケーションを実現しただけではなく、カスタマイザー、ローカライザー、ディストリビュータ、そしてポータブルアプリケーションの開発者たちにとっては、大きな勝利 (「経済的なもの」) でした。私たちの第一の目的ではなかったのですが、私たちは、実に品質の高い、ウェブ指向のクロスプラットフォームなアプリケーションの枠組みを開発したのです。プラットフォームとしての Mozilla (Mozilla-the-platform) です。

とはいうものの、統合に関わるコストは高くつきます。仮に、かゆい所に手が届く有用なユーザインターフェースを作らず、アプリケーション・スイートとしての Mozilla (Mozilla-the-application-suite) のそれぞれのアプリケーションの目標を最低限のものにしたとしても、です。スタンドアロンのアプリケーションは、起動が早く、動的メモリ消費量が平均的に小さく、そしてより頑丈でクラッシュしにくい傾向にあります。

アプリケーション・スイートがコスト高になる別の例は、本質的に過負荷で複雑なユーザインターフェースです （数え出すときりがありませんが、一つだけ例をあげれば、「ファイル｜新規作成」 サブメニュー）。スイートがターゲットとするユーザ層が明らかにされた事はなく、このユーザ層は、流行のビジネスと、ボランティア - 貢献者が起こす風に揺れ動いているように思えます。Hyatt の blog は、スイートというアプローチに反対する立場の意見を的確にまとめています。簡単に言えば、特定の領域で最も動機がある人や、アプリケーションの個々のルックアンドフィールを決めて最後にチェックインする人が誰であれ、偉大なアプリケーションは共有地としては運営できないのです。

Gecko もまた、無理をしすぎて苦しんでいます。それは、Gecko の上に立つ統合されたアプリケーションが多すぎるからではなく （これらはデザインと移植のバグの多くを振り分けるのに役立っています）、Gecko が元来、実際問題として拡張するのが容易ではない形式で高度に「モジュール化」されているからです。同時に、Gecko には、いまだに いびつな （baroque） 部分があります。 その原因は、初期におけるデザインの制限と、中心的な問題をパッチで解決してきたためにコードが蓄積された事です。

理由の要約

簡単に、また上記したロードマップの要素リスト順に述べると、この新しい計画の理由はこうです。

1. Phoenix は、実に小さく、速く、そして より良い ものです -- Phoenix が、Mozilla コミュニティのいろんな方面で求められている、互いに競合するような機能を全て備えているから良いの ではなく 、強固な「アドオン」拡張機能を持っているから良いのです。私たちは、ユーザが違えば要求する機能もまた異なる、という事を認識しています。このような要求は、まったく理にかなったものです。さまざまな機能の全てを、統合されたアプリケーション・スイートに盛り込もうとするのは、合理的ではありません。技術的にも社会的にも受け入れられないものです。

2. ブラウザ (Phoenix) にとって良いものは、メールアプリケーション (Minotaur と、それに続く Thunderbird) にも良いものです。Mozilla の統合されたメールは多くの優れた機能を備えていますが、他のアプリとの統合点が多すぎる事の弊害を受けています。また、現存している複雑なフロントエンドを保守しているのは少なすぎる人数の人々であり、彼らの多くは今は別の仕事で給料を得ているのです。

3. 1.0 ブランチは一年近く古いものです。ディストリビュータとユーザの手に、安定性とパフォーマンス、そして 1.0 以降のトランクに行なわれたセキュリティ修正の全てを渡すために、mozilla.org が推奨する安定した開発・製品リリースを 1.0 から 1.4 に変更する時期が来たのです。多くのディストリビュータはこの変更に対応するための計画をたてています。この変更によって、トランクは 1.5 から 1.6 の間のよりアグレッシブな変化に対応することができます。ただし、日々のビルドによる鍛錬と、四半期ごとの アルファ版/ベータ版/ファイナル・マイルストーンによるテストとフィードバックというループは変わりません。

4. Gecko の支持者たちが、いま率先して行なっている事は、レイアウト構造のバグとデザインの欠陥に対する修正であり、これは症状にパッチを当てる事では治療できないものです。これらのバグは、メンテナンス性、フットプリント、パフォーマンス、そして拡張性を大きく改善させる際の障害になっています。ソースコードの複雑な部分を削減するだけで、Gecko は、よりメンテナンスしやすく、より速くなり、そしておそらくダイナミック・フットプリントが少なく、コード・フットプリントは著明に少なくなるでしょう。

5. Mozilla の最も初期から行われてきた、CVS アクセスの 誤った 平等主義モデルと、ツリー全体にわたるハッキングは、終わりを迎えています。当初のハッカーたちの多くは立ち去って、後に残されているのはオーナーのいない、あるいはオーナーの権限が有効ではないモジュール群です。やりすぎと、転職と、伝統的な CVS アクセス権が相まって、mozilla.org が作った コードレビューの資格 は、関連するモジュールオーナー （オーナーがいるとすれば、ですが） に求められるべき物よりはるかに敷居の高い物になってしまいました。

オーナーシップについて...

最後の点は、議論の分かれる所です。少しのあいだ詳しく論じ、例外を提示する事ではっきりさせたいと思います。

• スーパーレビュー は、一般論として良い制度です。その領域のエキスパートから一つ、そして強力なジェネラリストからもう一つ、という二段階のレビューは、しばしば （大なり小なり） 危険な変更を成功に導きました。私たちは、有益なものをやめるつもりはありません。

• しばしば数人の献身的なボランティアによって行なわれる、ツリー全体の価値あるクリーンアップと、ビルドシステムのハッキングを軽視している、というつもりはありません -- この種の作業は継続されるべきです。

• また、オーナーが常に正しいと言い張ったり、彼らが「終身在職権」を持っていて交代させる事ができないと言うつもりもありません。

これらの簡単な問題を片付けた上で、後に残っている重要な点は次のものです。決断力をもって支配するコンポーネントオーナーが一人いれば、オーナー不在で決断が下せない状態よりは、ほとんどの場合よい結果になる、という点です （注意： 三人以上の委員会は有効なオーナーではありません）。この事は、トップダウンによるアプリケーションのデザインとポリシーの設定、とりわけユーザインターフェースのデザインにおいて、特に当てはまります。アプリケーション内のユーザインターフェースを首尾一貫したものにするためには、「アプリケーションの皇帝 （独裁者）」によるリーダーシップに勝るものはありません。デフォルトの共通キーバインドのように、アプリケーション同士で統一が必要な場合、皇帝たちが連絡し協力して、整理統合することを期待します。

Mozilla が、「秩序を回復する」時が来たのです。 偉大なソフトウェアは、一人または数人のハッカーによって作り始められます。より大勢の人々がチームとなって、作成者の指導のもとに、テストし、クリーンアップし、拡張します。 そして中には、作成者たちに合流あるいは入れ替わるまでに成長する人たちも出てくるでしょう。 コードのテストと同じく、コードのレビューは、すでにあるものをチェックする手続きであり、凡庸な素材から優秀なコードを作ることはできません。

従って、ケースバイケースではありますが、スーパーレビュアーたちがそのモジュールではオーナーの権限が有効に働いているとみなしている場合、用心深いオーナーに対してスーパーレビューを必ずしも必須ではないのものとし、強力なオーナーシップを促進します。 そして、オーナーシップが弱いか存在しないモジュールでは、私たちはオーナーを見つけるための手段を取るでしょうし、候補者が誰もいなければ、オーナーの権限が低い、あるいはオーナー不在のコードへの依存度を減少するでしょう。 ある重要なモジュールにおいてオーナーなしでしばらく「減速走行」できるのであればそうするでしょうが、経験上、それは減速走行よりも深刻な状態に至るのが常だったのです。

以上の記述が意味していない事

例外をあげることで明確化する、というのをもう少し続けると、次のような事も私たちは提案していません。

• 貢献者と会社が XPFE に基づいたブラウザを開発するのを止めようとしているのではありません。この由緒正しいコンポーネントあるいはスイート全体に基づいた製品を出した会社はいくつかありますし、今後出す予定の会社もあります。しかし、私たちは、上述した新しい アプリケーション・アーキテクチャ に基づいた、独立したアプリケーションに焦点を移そうとしています。ですので、XPFE に基づいたブラウザがあっと言う間に古びてしまう可能性は高く、従って 1.4 ブランチのブラウザが作業中のままで残される可能性も高いと思われます。もし充分な数の貢献者が XPFE に基づいたブラウザの作業を継続する意思を表明したなら、mozilla.org は 1.4 以降のブランチでもこのブラウザのサポートを継続することを考慮するでしょう。しかし、二つの異なったツールキットに基づくブラウザを充分にテストできるだけの、tinderbox やその他のリソースを用意できるかはまだわかりません。アプリケーション・スイートとしての Mozilla に基づいた製品を出している会社や組織の皆さん。この新しいロードマップの提案に対する皆さんの計画をお知らせください。

• 私たちは、XUL を捨てて、ネイティブな GUI ツールキットのフロントエンドを選ぼうとしているのではありません。また私たちは、Mozilla の Gecko をベースにしてネイティブな OS X のフロントエンドを持つブラウザである、Camino を軽視しようとしているのでもありません。どちらのアプローチも成功をおさめており、誠実なファンがいます。Mozilla コミュニティは、両方のアプローチを受け入れたのです （OS X 版の Phoenix まで作成され、繰り返しテストされています）。

• 従って、ブラウザを切り替えるに当り、私たちは Mac の XUL を捨てるつもりはありません。Mozilla のクロスプラットフォームなアプリケーションとツールキットが、人々が実際に使えるアプリケーションとして、クロスプラットフォームかつ使用可能なものであり続ける事を確認するのが私たちの目標です。また、Gecko の組み込みをテストするための環境は、他のプラットフォームと同様に、Mac でも必要です。ですから、デフォルト・ビルドのブラウザを Phoenix に切り替えた後も、私たちは OS X 版のデイリー・ビルドとマイルストーン・ビルドを提供するつもりです。

• XPFE に基づいたブラウザと統合されている重要なツール、 DOM インスペクター と Venkman (JavaScript デバッガ) は、新しい Phoenix ベースのブラウザでアドオンとしてサポートされる必要があります。

• Mozilla アプリケーション・スイートの、そのほかの統合されたコンポーネントである、Calendar、 Chatzilla、そして Composer (HTML エディタ・アプリケーション) もまた、なくなりません。これらがどのように含まれるかはまだ未定です。スタンドアローンのツールキット・アプリ になるか（もしそうなら、どちらの XUL ツールキットか）、あるいは Pheonix の一般的なアドオンになるか （もしそうなら、新しい XUL ツールキットを使用する必要があるでしょう） は不明です。いずれにせよ私たちは、コミュニティが行なうテストとフィードバックのためのデイリー・ビルドとマイルストーン・ビルドを提供するなどして、これらのモジュールのオーナーが必要とするあらゆるサポートを行なうことを約束します。

アプリケーション・アーキテクチャ

新しいアプリケーション・アーキテクチャの提案を始めるにあたり、関連する事実を要約し、いくつかの用語を定義しておきましょう。

現在、Mozilla テクノロジーを使用して作成されるアプリケーションには、主に二種類あります。ひとつは、組み込みアプリケーションです。これは、Mozilla のレイアウト・エンジンを使用していますが、レイアウトされた HTML または XML 文書以外のユーザインターフェースには、独自のコードを使用しています。もう一つは、ツールキットアプリケーションです。これは、Mozilla 自体の上に作成され、クロスプラットフォームとして設計されています。ユーザインターフェースの要素は XUL で定義され、Gecko を使用してレンダリングされています。

どちらのアプリケーションでも、 Gecko Runtime Environment (GRE) を使用して、一度 Gecko をインストールすれば、それを共有して使用する事ができるようになるでしょう。アプリケーション間でプロファイルが共有できるようにさえなるかもしれませんが、独立したプロセスで動作しているアプリケーションの間でプロファイルを共有できるようなプロセス間の通信機能は、 （1.4 アルファ版の時点では） まだ作成されていません 。

ツールキットアプリケーションは、機能拡張 (extensions) もサポートするでしょう。これは、中核になるアプリケーションの上に置かれて、追加機能を提供するように設計された特殊なアドオンです。ブラウザの場合でいえば、マウスジェスチャー、サイトナビゲーション・ツールバー、DOM インスペクター、そして JavaScript デバッガがこのようなアドオンの例です。

さらに、私たちは、特定のツールキットアプリケーションは、それ自体が機能拡張でもあるべきだ、と提案します。つまり、スタンドアロンのアプリケーションであると同時に、他のアプリケーションにインストールされるアドオンでもあるように設計されるべきです。このようなアプリケーションの例は、Thunderbird、別名 Mozilla メール であり、スタンドアロンのアプリケーションとしても動作し、また Phoenix、別名 Mozilla ブラウザ に機能拡張として直接インストールする事もできるようになるでしょう。

（ブラウザとメールが統合された現行のアプリケーションに多くのファンがいて、こうしたアドオンを望む事が予想されるので、私たちは、デフォルトのブラウザを切り替える前にこのアドオンを提供できるよう作業するつもりです。）

思想としては、統合されすぎたアプリケーション・スイートから単純なツールキットアプリケーションへの移行です。デフォルトの設定から上級者向けの機能を削除すると同時に、好みの機能拡張群を基本機能に追加してあなた独自のブラウザを作成できる強力なツールを提供します。mozilla.org がサポートしなければならない独自のビルドが多数できるのを避けるために、一般的な機能拡張はすべて無効でインストールされる状態で出荷されるでしょう。こうすれば、機能拡張を使いたい人は簡単に有効にできますし、使いたくない人はアンインストールできます。

このアーキテクチャは、次の図でわかりやすくなるでしょう。

この図でメールは、アプリケーション (四角) と同時に、機能拡張 (メールが拡張する対象であるブラウザに向かう矢印を持つ円形) としても示されています。アプリケーションではない純粋な機能拡張は、図の一番上に置かれています。

やるべき事

このロードマップは提案です。私たちは、Mozilla プロジェクトが向かうべきだと私たちが考えている方向を示しているのです。私たちが今いる場所 （1.4 アルファ） からより良い場所に到達するためには、少なくとも以下に示す事を行なう必要があります。

• 二つのブラウザによってビルドされたファイルに追加された MOZ_PHOENIX #ifdefs を除去する。

• Phoenix によって分岐された全てのファイルを統一する。ここで、XPFE 側には分岐後に、Pheonix 側では行なわれていない重要なバグフィックスがなされています。これらのファイルを共有の場所に移動するか、修正をマージする一方でフォークの両方の枝の開発は継続するか、XPFE 側を軽視してお蔵入りにするか、一般論として述べることはできません。しかし何かを行なう必要があり、それは早期に行なわれなければなりません （XPFE 側の修正は 1.4 のあいだ続くでしょう）

• Phoenix からすでに削除されたかもしれない小さなビルド・オプション (低レベルの JavaScript デバッガ・サポート、MathML、Midas) が、デフォルトビルドで設定されているかどうかの確認。

• 現存するアドオンの作成、ないし作成の援助をする。
  • DOM インスペクター
  • Venkman
  • サイト・ナビゲーション・ツールバー
  • メールの統合 (メール作成のための <ctrl-M> など)

• Phoenix のツールキットに基づいた Thunderbird の開発。

• 移行期の間、新旧両方のブラウザ・ビルドをカバーするのに充分な数の tinderbox マシンを用意する。

繰り返しますが、私たちはここで、ただ方向性を示しているだけです。攻撃プランの詳細は、ニュースグループと Bugzilla で進展させられるでしょう。Mozilla 1.5 のファイナル・マイルストーンで Pheonix に切り替えられるかは、まだ不明です。私たちはあなたのコメントを歓迎します。mozilla.seamonkey ニュースグループが良いでしょう。

マイルストーン・スケジュール

本稿の前のロードマップに 記載されている ように、Mozilla プロジェクトは、四半期ごとにマイルストーンをリリースする、という計画に従ってきました。 この計画では、新機能を盛り込んだ安定しているリリースを定期的に供給する、という点に重点がおかれています。 理想的には、リスキーな変更を「アルファ」マイナーリリースに詰め込み、安定化のための「ベータ」期間が続き、そして短いフリーズ期間内で「出荷の障害になる」バグだけを発見して修正する、というものです。

コミュニティの多くの人から、アルファ期間を延長してほしいという要望が出されました。 しかし、アルファ期間が長すぎると、大勢のテスターから自動的に送られてくるクラッシュレポートなどのフィードバックを集計して、それに対処する ことができなくなります。とは言っても、アルファ期間をベータ期間よりも長くするのは合理的な事だと私たちも思いますので、ベータ期間から一週間分をアルファ期間へと移しました。 以下が更新したマイルストーンスケジュールです。

下の表は、各マイルストーンの予定を、トランクのフリーズ日、ブランチ作成日、マイルストーンのリリース日に分けてあります。（マイルストーンの開始日は、前のマイルストーンのブランチ日です）

いつもの通り、マイルストーンのフリーズ時刻は、大平洋標準時の火曜日午後 11時 59分です（tinderbox のページにある告知をご覧ください）。

Mozilla ベースの製品をリリースしようと計画していて、その開発スケジュールが上記のマイルストーンとうまく合わない場合は、私たちに お知らせ ください。（情報の秘密は外部にもれないようにしますし、必要であれば適切な守秘手段をとります。）

協力するには

C および C++ ハッカーへ： tinderbox は現在 コードフットプリント を計測していますので、フットプリントを増やすのではなく減らしていきましょう。コードを追加するというありがちな誘惑に負けないでください。コードを削除する事、複雑になりすぎたコードを単純化する事、早まった最適化を元に戻す事、そして根拠のない XPCOM の使用や充分に XPCOM 化されていない古いコードを一掃する事を心がけてください。新しい機能を追加しなければならない場合は、正しいライブラリにバンドルされているか、すなわち新しいライブラリを追加しないで良いかを確認してください。最小限の組み込みブラウザビルド にリンクされるモジュールへのいかなる追加も ドライバ による承認が必要です。

Mozilla 組み込み制作者へ： embed、footprint、mlk、perf その他の適切なキーワードをつけて Bugzilla に意見を投稿してください。Bugzilla の新しいリクエスト追跡機能を利用して、そのバグを将来のマイルストーンに対するブロッキングとして指定してください （例： blocking1.4b?）。そして、なぜそのマイルストーンまでにバグの修正が必要か、説得力のある説明を付けてください。Mozilla プロジェクト・マネージメント を利用すれば、できるだけ多数のマイルストーンキーワードを満たすように修正目標を決められるようなハッカーがそのバグを担当するように努力します。

バグ担当者、そして特に、Future バグや期日未定のバグを名目上の担当者の代わりに修正できる支援者へ： 割り当てられたバグを mozilla 1.4 と mozilla 1.5 マイルストーンの間で修正目標を定めてください。分類の目安として、安定性に関するものは 1.4、アプリケーションおよびレイアウト再構築に関するものは 1.5 です。バグを支援者に任せるようにしてください。future とされたバグ、あるいは期日未定のバグで、すぐに修正するべきだけど修正を支援してくれる人が見つからない場合、drivers@mozilla.org に知らせてください。

コミュニティメンバーへ： Bugzilla のマイルストーン指定機能を使う場合は、慎重に使用してください。担当者の同意がないまま他の人のバグのターゲットマイルストーンを変更しないでください。もちろん、優先度を上げる手助けとして投票することはできます (ただし、パッチを投稿するほうが投票よりも大きな力を持つことを忘れないでください) 。 最後に、支持活動や「同感です」的なコメントをバグシステムに投稿するのはご遠慮ください。

プロジェクト・マネージメント

mozilla.org は、早急な援助を必要とするバグへの支援者を求めている開発者のため、またリスクを軽減するため、そして Mozilla ベースの商品化プロジェクトに対して製品リリースの管理面を支援するため、プロジェクトマネージャーのグループを創設しました。drivers@mozilla.org です。

現在のドライバーは以下の通りです。

• David Baron, dbaron@dbaron.org
• Chris Blizzard, blizzard@redhat.com
• Scott Collins, scc@mozilla.org
• Asa Dotzler, asa@mozilla.org
• Brendan Eich, brendan@mozilla.org
• Chris Hofmann, chofmann@netscape.com
• Randell Jesup, rjesup@wgate.com
• Michael Kaply, mkaply@us.ibm.com
• Robert O'Callahan, roc+moz@cs.cmu.edu
• Tim Rowley, tor@cs.brown.edu
• Mike Shaver, shaver@mozilla.org
• Seth Spitzer, sspitzer@mozilla.org
• Dan Veditz, dveditz@cruzio.com