オープンガバナンスにおける役割とその責任

この記事は Qt Blog の "Open Governance Roles and Responsibilities" を翻訳したものです。
執筆: Thiago Macieira, 2011年5月20日

先日の「成熟レベル一覧」という記事と、その前の「成熟レベル」で Qt のコードの各パーツのメンテナに何が期待されるのかを示唆しました。この記事では Qt のオープンガバナンスで働く人々に期待していること、どのような役割が存在し、そのそれぞれにどのような責任があるのかを詳しく説明しようと思います。

簡単に言うと、3つのレベルだけになるでしょう。

1. Contributor(貢献者)
2. Approver(承認者)
3. Maintainer(メンテナ)

“Chief Maintainer”(チーフメンテナ)の存在は四番目のレベルではありません。詳しくは後述します。

外部からのインスピレーション

Qt Open Source プロジェクトでは、非常にフラットかつシンプルな構成を望んで、そのアイデアを練り始めました。メーリングリストでの議論はとても興味深く、初期には "board" もしくは “oversight committee” と呼ばれていた構成がありました。(初期に私が作成した資料には、「スパイ映画や番組で使われるような陳腐で無意味な名前 − 例えば、理事会、監督団体、本部等 − を見つけよう」という提案もありました。)しかし、最終的にはそれらではなく、成功している既存の巨大なオープンソースプロジェクトを参考にすることにしました。

我々が特に参考にしたのは WebKit と Linux kernel の二つのプロジェクトです。双方のプロジェクトには利点も欠点もあり、どちらもそのまま Qt に当てはめることは出来ないと考えました。Qt ではそれぞれの良いところを組み合わせたいと考えました。信用に基づくネットワークと分散開発を利用したいと思いましたが、新規の貢献者と最終的なリポジトリとのホップ数は出来るだけ小さくしたいとも思いました。また、Qt には品質を保証するための非常にアグレッシブなデグレードテストと継続的インテグレーション(CI)システムがあります。

ここで紹介するモデルは長い間議論され、やがて Robin Burchell と私の間の長い IRC セッションを通じて形になったものです。全ての結論は opengov メーリングリストに投稿され、若干の議論を経て調整されました。

Qt でのモデル

図にあるように、ここでは Contributor(貢献者) に加えて二つの基本的な役割を作りました。貢献者はプロジェクトに貢献する意志とスキルを持つ人であれば誰でもなれます。貢献はコード以外にも、様々な形式で行うことが出来ることを言及しておきます。それはここで注目することでもあります。貢献者は今後利用可能となるコードレビューツールを通じて貢献を開始します。そのツールは我々の Qt の開発そのものにも使われます(詳細は別の記事で説明します)。貢献がツールに登録されると、誰でもそれにコメントや意見、改良の提案などを行えます。より高いレベルに達していなくてもこれには参加できます。

次のレベルは Approver(承認者) です。これは Webkit の reviewer レベルに相当します。承認者とは、貢献をソースコードに統合するための承認をする権利を得た貢献者のことです。その権利には、貢献があるガイドラインに従っていることを保証する義務が伴います。そのガイドラインは定量的で客観的(“Technical Fit”)と、定性的で主観的(“Spirit Fit”)なものの双方に適用されます。また承認者は提案したり却下したりする場合においても、建設的である義務を負います。承認者になるためには、貢献者として貢献を行いそのプロジェクトの為を一番に思っているということを証明して、その権利を勝ち取らなければなりません。既存のある承認者に推薦され、別の承認者がそれに賛成し、かつ反対のないときに、その権利が与えられます。

権利は簡単に与えられ、また簡単に奪われます。承認者はその所属や業務内容に関わらず、プロジェクトの利益のために働くことを期待されます。その承認の権利はコード全体にわたって与えられますが、その行使には、知見のある領域に集中し、かつ十分な注意を持ってあたることを期待されています。濫用した場合にはその権利を剥奪されることによってコミュニティから罰せられます。オープンソースプロジェクトでの経験から言うと、それが起こるのはとてもとても希なことです。

ほとんどの状況では、これがオープンガバナンスの全てです。貢献が作られ、一人もしくは数人によってレビューされ、承認者(レビューした中の一人かもしれませんし、そうでないかもしれません)が貢献を承認し、継続的な統合システムにかけられてテストされコードベースに統合されます。この仕組みは WebKit のモデルに非常に近いところにあるでしょう。

それでは、Maintainer(メンテナ) はどこにいるのでしょうか。メンテナは質問の対象となるコードについてよく知っていて、尊敬されているコミュニティのメンバです。承認者とは異なり、メンテナはコードにひもづけられています。メンテナは基本的にメンテナンスを行っている特定のコードに対して一つの義務と一つの権利を持ちます。

• 義務: そのコードがいつでもベータの準備が出来ていることを確実にすること。すなわち、その領域への貢献がいつでもリリースプロセス(テストし、安定していて、機能が実装済みで、ドキュメントがあり、API がレビューされていて、等々)を開始できる適切な状態にあること、いつでもその状態であることを確実にしてください。
• 権利: 将来の方向性を決めることが出来、それに従わない貢献はリジェクトすること(安定していなかったり完了していない承認済みコードを削除することも含みます)などが出来ます。

それらとは別の義務もあります。そのモジュールにどのようなプロジェクトが発生しているのかを把握して、モジュールに新機能を貢献したい人にアドバイスしたり、全ての貢献のレビューを確実に行うことです(そのため、誰もレビューしなければ自分でレビューしなければなりません)。そのうえ、メンテナは何か問題が発生した場合に QA やリリースチームと連絡を取るメンバーでもあります。

コードの増大に伴って、新しいメンテナの必要性が顕在化してきます。そのため、常にその数を適切に維持します。すなわち、各仕事を快適にこなすのに必要なだけのメンテナを確保するべきです。しかし、余分には要りません。既にコードを監視し、コンサルティングを行っている誰かが、自然とメンテナの候補になるのを期待しています。新たなメンテナが誕生するもう一つのケースは、前任者が時間や興味の欠如や、取られたアクションがプロジェクトに最上の利益をもたらさない場合などで、適切な仕事をしなくなったときです。

メンテナはもちろん、権限を委譲することが出来ます。例えば、QtCore モジュールにメンテナがいるとします。そのメンテナはツールとコンテナサブシステムの全てを、信用する人へ委譲することが出来、その間モジュールの他のパーツに専念できます。これが信用による関係であることに注意するのは重要です。サブメンテナのアクションはメンテナ自身に反映されます。Qt 5 の "qtbase" のように大きなモジュールでは複数のメンテナで仕事を分け合うことになるでしょう。

Chief Maintainer(チーフメンテナ) をこの構造の四番目のレベルと考えてはいけません。チーフメンテナ(ここでは事実上、"qtbase" モジュールのメンテナを想定しています)はその他のメンテナと同様のメンテナです。その代わり、チーフメンテナは そのレベル内の筆頭メンバー としてみなされるべきで、その過去および現在の貢献によって、その意見はプロジェクトに大きな影響をもたらします。このため、大きな膠着状態を打ち破る、飛び越えた決定を行う権利を与えられています。チーフメンテナとはそのような役割であり、それがその人を選出する理由です。

それらの役割に誰が割り当てられるか疑問に思うかもしれません。その人の仕事に関係なく、その役割につくことによるメリットを示せる人ならば誰でも成ることができます。しかし、オープンガバナンスが始まるときには、Qt を既に開発している人々(Troll および既存の貢献者達)による「立ち上げ時」のモデルを用いるでしょう。それらの人々は自然と定まるはずですが、念のための調整期間を持つでしょう。また、「立ち上げ時」にはそのほとんどは Nokia の社員で占められるのも確かです。時がたつにつれて、Nokia 外の人々が参加し、責任を得ていくと期待しています。

最後になりましたが、上記の記述は現実にはコードのワークフローにフォーカスしています。それはあらゆるオープンソースプロジェクトで発生していることです。しかし、上記の役割に加えて、プロジェクトを進めていくには QA チームやドキュメントチーム、リリースマネージャチーム、コミュニティマネージメント、Web チーム、ロードマップ計画などのように他の役割も多数必要となります。それらの各チームは(それ以外を選択しなければ)ただ二つのレベル、すなわち貢献者とチームリーダー(メンテナのような存在)で構成されるでしょう。それらの役割に現在着いている Nokia の社員が来たる Qt Contributors' Summit に参加するので、共同作業に興味があればそこでその方法について話し合うセッションを設けます(訳注: Qt Contributors' Summit は終了いたしました。その結果については別途報告いたします)。