Mozilla モジュールの特徴、モジュールオーナーの役割、モジュール所有者の基準、モジュールオーナーの指名。
コードの適切性、品質、または CVS ソースレポジトリにチェックインされる準備が整っているのかという点に関して mozilla.org のスタッフメンバーが決定を下していない事項が多数あります。スタッフがこのような作業を行うには Mozilla プロジェクトがあまりに大きすぎるためです。プロジェクトにはコアテクノロジーセット (レイアウトエンジン、ネットワークライブラリ、クロスプラットフォームコンポーネントモデルなど)とこれらのテクノロジーで構築されたアプリケーションセット (ブラウザ、メール/ニュースリーダー、Internet Relay Chat クライアント) の両方が含まれています。mozilla.org のスタッフは、現行の開発に必要な大量の決定を下すための態勢が整っていません。ひとつには、mozilla.org スタッフがコードのあらゆる分野の専門家であると思うのはおこがましいことだと考えるからです。間違いなくそんなことはありません。もうひとつには、スタッフが少人数であることが挙げられます。特定のコードに関する大半の決定を mozilla.org のスタッフが下そうとしたならばプロジェクトはなかなか進捗しなくなってしまいます。
この代わりとして、mozilla.org は「モジュール」およびモジュールオーナーシップを通じて広範な参加者に意思決定を分散しています。モジュールとは、合理的に定義された境界を持つ機能の一部分を実装するファイルセットです。モジュールは、アクセシビリティのための「accessible」などディレクトリ内のファイルセットの場合があります。または「スタイルシート」などのようにより概念的な場合があります。このような場合、モジュールにはソースツリーのさまざまな領域内に多数のファイルが含まれます。モジュールが C または C++ で記述されている場合には、.h ファイルと、.c または .cpp ファイルの 2 ファイルのみを含むことができます (一例は xpcom/ds/pldhash.{{ mediawiki.external('ch') }} で、これは xpcom の他の要素とは個別に処理されます)。
「合理的に定義された境界」といっても、絶対的に明確ではないのは当然です。特定の機能が終了し別の機能が開始する場合に重複やあいまいさがある場合、この定義自体がコードを反映するため、私たちはこの定義を使用します。絶対的な定義を作成しようとすると、複雑なルールや例外が要求されますが、これらはほとんどの場合必要とされません。このような定義を考案するためにエネルギーを使うよりも、必要に応じて mozilla.org のスタッフが仲介となってモジュールオーナーに重複または共有したオーナーシップを可能であれば管理していただきたいと考えています。
「モジュールオーナー」は mozilla.org のスタッフがモジュールの開発のリーダーシップを委ねた人を指します。モジュールオーナーの責任範囲は、コードの品質を改善する、適宜改訂と刷新を実施する、残りのコードベースの開発との調整を図る、モジュールの方向性に関する共通の理解を構築および維持する、適宜 API を開発する、可能な限り多くの文書を作成する、コードの貢献に適切に対応する、提言を策定したり、コミュニティから述べられたニーズをまとめる、有能な新規参加者を喜んで受け入れる環境を作るなど、広範囲に及びます。
コードをそのモジュールにチェックインするためには、モジュールオーナーの承認が必要です。これと引き換えに、私たちはモジュールオーナーに対して、受け取るものに注意を払う、他の人によって実行されたパッチに対応する、そして他の人によって開発されたコードを正当に評価することを期待しています。この役割を果たす方法についてはかなりの柔軟性がモジュールオーナーに与えられています。mozilla.org のスタッフは、モジュールオーナーがモジュールを管理する方法についての複雑なルールや手順を規定しません。作業がうまくいき、コミュニティ全体が満足すれば、これに越したことはありません。そうでない場合には、うまくいくように問題点を見つけて正していけばいいのです。
モジュールオーナーはモジュールの管理作業すべてを自分で行う必要はありません。モジュールオーナーは、モジュールにチェックインするためにコードを認可する能力のある他の人を指名することができます。これらの開発者は「ピア」と呼ばれ、優れたモジュールオーナーに求められる資質の多くを持つ人がその任に就くべきです。モジュールオーナーは、自分自身が作成したコードを評価する場合、ピアを指名して評価してもらわなければなりません。モジュールオーナー自身が自分のコードのレビューをすることは許されません。モジュールオーナーがいない場合には、そのモジュールをコードにチェックインするためにピアの承認があれば十分です。
モジュールオーナーは専制的な支配者ではありません。コミュニティからの入力を基に、そしてコミュニティの利益を最優先にして決定する権限を与えられています。コードの記述はコミュニティが行うので、モジュールオーナーに記述は求められません (もちろん、他の人たちと同じように、モジュールオーナーの雇用者やコミュニティが記述を求めるなどさまざまな理由から、モジュールオーナーがコードを記述してもかまいません)。モジュールオーナーはそのモジュールに実行されるパッチに注意を払う必要があります。といっても、「注意を払う」ということはすべてのパッチに同意することを意味するわけではありません。Mozilla にとって意味のないパッチもあれば、実装してもうまくいかないパッチもあるかもしれません。モジュールオーナーにはパッチを拒否する権限が与えられています。これはモジュールオーナーの不可欠な役割のひとつです。mozilla.org はモジュールオーナーに、パッチへの変更を求める理由、パッチを拒否する理由、または一定期間レビューを延期する理由など該当するバグのレポートをお願いしています。使えるパッチにするためにパッチをリライトすることはお願いも期待もしていません。同様に、次回の期日を考慮するとある有望なパッチのレビューを延期しなければならない場合があります。たとえば、パッチに関心はあるが、次のマイルストーンに向かないという場合です。このような場合には、マイルストーンに必要な状況が整うまでパッチのレビューを延期する方が得策です。該当するバグのレポートにその旨を記述してください。そして当然のことですが、mozilla.org スタッフによるレビューを行わずに頻繁にまた長期間にわたって延期し続けることはできません。
論争に発展した場合やその他の方法で解決できない場合には、mozilla.org が関与します。モジュールオーナーが特定のアクションに同意する公式見解を mozilla.org に求める場合もあれば、モジュールオーナーが改善できるであろう方法をその他の貢献者が提案する場合もあります。現在論争が展開されている場合もあります。可能であればこれらの問題をコミュニティが解決するのが望ましいと考えますが、常にそうはいかないということも分かっています。「こうでなければならない」というような絶対的な決定は避けようと努めますが、必要な場合には絶対的な決定を下します。
優れたモジュールオーナーシップにとって重要な要素は多数あります。もちろん第一は問題のコードに対する個人の専門的な知識です。しかしこれまでの経験から、付加的な基準も重要であること、また優れたハッカーがモジュールオーナーに適しているとは限らないことが分かっています。優れたモジュールオーナーのための基準は以下のとおりです。
ある個人が一定期間モジュールで作業を行い、モジュールを完了させるまでの間、基準のほとんど (完璧を求めるほど世間知らずではありません) を満たすことができる能力を証明し、そしてこの人をモジュールオーナーとして指名することへの総意が生まれることが望ましいと考えています。このように、指名は任命というよりはむしろ確認です。これまで常にそうしてきたわけではなく、また常にこの方法がうまくいったわけでもありませんが、今後よりよい仕事をしていこうと思っています。
これは、モジュールオーナーが不在の時があるということを意味します。特にほとんど注目されてなかったモジュールや廃り始めたモジュール、また勇敢な人が状況を把握し再び軌道に乗せるために尽力してくれる場合には、モジュールオーナーが不在です。これらの人たちの取り組みに対して大いに感謝するものです。ただし、これらの人たちをモジュールオーナーに指名することはすぐにはできません。当然のことながら、このモジュールの作業に相応の時間を費やさないと、この人が基準のいくつか、特に 1 から 5 の基準を満たしていることを証明することは困難です。この作業を行うことができるだけの幅広いそして深い専門知識をある人が持っているというのは十分にあり得ることですが、これはどちらかといえば例外だと思います。
モジュールオーナーを決定する際、上記の基準が各モジュールに対して同じ重要性を持っているとは限りません。モジュールごとに特定の要素の重要性は変わります。たとえば、基準 4 (Mozilla コードベース全体、ならびにコードベースとモジュールの関係を正しく理解している) と 6 (コードベースの他の部分に対するコードの影響を評価する能力) は自己完結型のモジュールにはあまり重要ではありませんが、コードの他の部分に多大な影響を及ぼすコアテクノロジーを含むモジュールにとっては非常に重要です。同様に、基準 9 (そのモジュールの対象となるさまざまなコンシューマの多様な視点とニーズを考慮する能力) と 10 (適宜ファクタリングやその他の抽出技法によってさまざまなニーズを解決する能力) は、少人数の貢献者のために明確に定義された機能を果たすモジュールにはあまり重要ではありませんが、さまざまな用途と広範な貢献者グループをサポートするモジュールには不可欠です。
mozilla.org は「Despot」(despot.mozilla.org) として知られているデータベースを使用してモジュール、モジュールオーナーおよびピアを追跡しています。データは www.mozilla.org/owners.html をご覧ください。このページには、各モジュールを構成するコードの指示も記載されています。
モジュールオーナーシップの譲渡は mozilla.org を通じて行われます。モジュールオーナーを辞任するためには、staff@mozilla.org にメールを送信してください。遠慮なく新しいモジュールオーナーの推薦をメールに記載してください。モジュールによっては、モジュールオーナーシップの基準を満たしていることが証明済みで、モジュールオーナーになることに興味を持っており、継承者となることを概ね了承しているピアがいる場合もあります。このような場合には、mozilla.org のスタッフが Despot にオーナーシップの変更を行います。それ以外の場合には、そのモジュールに関するオーナーシップの基準を満たしていることを証明済みの人はいないでしょう。このような場合には、オーナーが育つまでオーナー不在でモジュールを進行し、モジュールのピアがそのモジュールにチェックインするために必要なレビューと承認を行います。
モジュールオーナー/ピアの役割と Bugzilla コンポーネントの既定のオーナーの役割が不明瞭な場合があります。しかし役割は全く異なっています。コンポーネントオーナーは、特定のコンポーネントに対するバグレポートの受け取りに最も適した人のことで、モジュールの方向性やコードのレビューに関しての決定を下すために最適な人とは限りません。これにはいくつかの理由があります。第一に、Bugzilla コンポーネントはモジュールに正確に対応してはいません。これは、コンポーネントがバグを確認および経験する方法を反映しているが、コードの構造を必ずしも反映していないためです。第二に、バグの管理は、モジュールのコード管理とは異なる作業です。必要となるスキルが異なります。したがって、非常に優れたハッカーであっても、バグレポートを定期的にレビューする、進捗状況を追跡する、正しいオーナーにバグを再度割り当てる、テストケースが存在することを確認するなどの作業を得意としない場合があります。これらのスキルに優れていてもモジュールオーナーにふさわしくない貢献者もいます。Bugzilla コンポーネントオーナーとモジュールオーナーが同一人物の場合もありますが、多くの場合、別の人物がそれぞれのオーナーです。
モジュールのメンテナンス状態が悪く、残りのコードベースとうまく動かない場合があります。モジュールオーナーが不在である、または指名されたモジュールオーナーが他の作業に忙しくてそのモジュールのメンテナンスができない場合に発生します。あるいはモジュールオーナーはいるが、コミュニティ全般が不適切だと考えるモジュールへのアプローチをとった場合にも発生する可能性があります。mozilla.org のスタッフは、開発コミュニティがこのようなモジュールを確認し、解決策を提案して改善策を実施することを望んでいます。何らかの理由で不可能な場合には、mozilla.org のスタッフが可能な限り最善の解決策を見つけ出すために尽力させていただきます。