Subversion プロジェクトでは、コミッターを決める際には ヒポクラテス主義 first, do no harm (何よりもまず、患者に害を与えないこと) を重視しました。 技術的なスキルや Subversion のコードに関する知識よりも、 単によりよい判断ができるかどうかに重きを置いたのです。 「判断ができる」というのは、単に「すべきでないことは何か」 を知っているかどうかという意味です。 だれかがちょっとしたパッチを送ってきたとしましょう。 それは、コードの中のほんの些細な問題を修正するだけのものでした。 そのパッチはうまく適用することができてバグもなく、 プロジェクトのコーディング規約やログメッセージの規約も守っています。 そのようなパッチを数多く送ってきた人に対して、 既存のコミッターたちが「コミット権をあげたらどう?」と提案します。 少なくとも 3 人のコミッターが賛成し、 かつ反対する人が誰もいなければ、正式にコミット権を提供します。 もちろん、その人がコード全体を把握していて複雑な問題も解決できるという証拠なんてありません。 しかし、そんなことは関係ないのです。はっきりと言えることは、 彼は自分自身の能力をきちんと判断することができるということです。 技術的なことは、後からでも勉強できます (し、教えることもできます) が、判断力についてはなかなかそうはいきません。 したがって、コミット権を与える際には判断力の有無を重視したほうがいいでしょう。

新たにコミッターを追加しようという提案が議論を呼ぶ場合、 その原因が技術的なものであることはあまりありません。 どちらかというと、メーリングリストや IRC 上でのその人のふるまいが問題になることが多いようです。 たまに、技術的には問題がなく プロジェクトの公式指針にしたがって働くこともできるけれども、 掲示板ではやたらけんか腰だったり非協力的だったりする人がいます。 これはちょっと深刻な問題です。 何度か助言をした上でまだ彼がそのような態度をとり続けるようなら、 たとえ彼の技術が優れていたとしても私たちは彼をコミッターにはしないでしょう。 ボランティアの集まりにおいては、いわゆるソーシャルスキル、 つまり「集団の中でうまくやっていく能力」は技術力と同じくらい重要です。 すべてはバージョン管理されているわけなので、 仮にふさわしくない人をコミッターにしてしまったとしても コードにはそれほど被害は及びません (何か問題があっても、 コードのレビューですぐに見つかることでしょう)。 しかし、そんな場合はすみやかにその人のコミット権を剥奪することになるでしょう。 これは決して気持ちのいいことではなく、ときには対立が起こることもあります。

多くのプロジェクトでは、重要なパッチを何回か提供することで はじめてコミッター候補として認められるような仕組みになっています。 これは、単にその人が周りに害を与えないかどうかを見るだけではなく その人がコードにどのように関わっていくかを見るという意味があります。 これはこれでいいのですが、コミット権を得るのがまるで 会員制の高級クラブに入会するかのようなことになってしまわないように注意しましょう。 ここで問うべきことは「コードにとってもっともよい結果をもたらすにはどうしたらいいのか?」 であり、決して 「こいつを仲間に入れるとコミッターたちの社会的な評判がおちるんじゃないか?」 といったものではありません。 コミット権を与えるのは個人の自尊心を高めるためではなく、 コードに変更を加える際の手間をできるだけ減らすためです。 100 人のコミッターのうち定期的に大規模な変更を行うのが 10 人だけで、 残りの 90 人は誤植やちょっとしたバグの修正を年に数度行うだけだったとしましょう。 それでもコミッターを 10 人だけにしておくよりもよっぽどましです。

コミット権の剥奪に関してまずひとこと。 そんなことをしなければならない羽目に陥らないように、 最初から十分注意するようにしましょう。 「誰の」アクセス権を「なぜ」剥奪するのか といった議論は紛糾しやすいものです。 たとえ皆の意見が一致していたとしても、 そんな作業は全く生産的ではありません。

しかし、どうしてもそうしなければならない状況になったら、 まずはその人にコミット権を 与えた ときのメンバーの間で非公開で議論しなければなりません。 問題となっている人自身はその議論に加えてはいけません。 通常は秘密主義は否定されるものです。その方針には反していますが、 この場合は非公開であることが必要なのです。 第一の理由として、そうでないと自由に意見を交換することができません。 もう一つの理由は、もしコミット権剥奪の試みが失敗したときに 「そういう考えがあった」ということを当事者に知られないようにするということです。 それを知られてしまうと、きっと「剥奪に賛成したのは誰? 私の味方になってくれたのは誰?」という疑問が頭に浮かぶことになるでしょう。 これは、もっともたちの悪い派閥争いの原因となってしまいます。 ごくまれに、コミット権を剥奪する (あるいはしようと考えている) ことを警告として知らせたいという状況もあるかもしれません。 しかし、そのような場合は必ずグループ全体の同意をとってからにしなければなりません。 非公開で行った議論や投票の内容は、参加者全員が了解しない限り公開することはできません。

だれかのアクセス権を剥奪したら、その事実を公表しなければなりません (この章の後半の 「秘密主義を避ける」 を参照ください)。 一般向けへの公表は、できるだけそつなく行うようにしましょう。

プロジェクトによっては、コミット権に何段階かの区別をつけているところもあります。 たとえば、ドキュメントについては自由に変更できるけれども コードそのものにはコミットできないといった権限を用意しているわけです。 このように「一部だけに限定」したコミット権を与える場面としてよくあるのは、 ドキュメント、翻訳、他のプログラミング言語とのバインディング、 パッケージ作成用の設定ファイル (RedHat の RPM スペックファイルなど) などです。これらは、何か間違いがあったとしてもプロジェクトのコアには あまり影響を及ぼさないところでもあります。

コミット権は、単にコミットすることだけでなく投票権 (4章プロジェクトの政治構造と社会構造 の 「誰が投票するのか?」 を参照ください) にもからんできます。 部分的なコミット権を持つ人の扱いはどうしたらいいのでしょうか? 正解はひとつではありません。 そのプロジェクトでどのように部分コミット権を定義しているかによって変わります。 Subversion ではきわめてシンプルに考えています。 部分的なコミット権を持つコミッターは、 自分がからんでいる範囲の事項については投票できるが それ以外の範囲についての投票権はないということです。 ただ、参考意見としての投票 (advisory vote) という仕組みは存在します (要するに、投票用紙に単に "+1" と書くのではなく "+0" あるいは "+1 (拘束力なし)" と書くようなものです)。 公式な効力がないからといって、彼らを完全に黙らせてしまう理由はありません。

フルコミッターは、あらゆることに関して投票権を持ちます。 ちょうど彼らがどの部分にでもコミットできるのと同じようなことです。 そして、フルコミッターのみが新規コミッターの追加に関する投票権を持ちます。 しかし現実的には、部分的なコミッターを追加する手続きについては権限を委譲することもよくあります。 フルコミッターが部分的なコミッターの "保証人" となり、 その分野だけのコミット権を持つコミッターについては彼らに選ばせるのです (これは、特に翻訳作業などを円滑に進めるために便利です)。

作業の内容によっては、このような決まりを あなたのプロジェクトでそのまま取り入れるわけにはいかないかもしれません。 しかし、 「すべてのコミッターは自分のコミット権の及ぶ範囲に関する決定への投票権を持ち、 コミット権の及ばない範囲に関しては投票できないということ」 「プロジェクトの進め方に関する投票は、基本的にフルコミッターのみが行うこと」 「ただし、もう少し投票できる人の範囲を広めるようにフルコミッターが決められるということ」 という大まかな考えかたはすべてのプロジェクトに適用できるでしょう。

部分的なコミット権の付与に関する注意: 部分的コミット権を与える機能を仮にバージョン管理システムが持っていたとしても、 できればそれは使わないようにしましょう。その理由については 3章技術的な問題 の 「承認」 をご覧ください。

プロジェクトによっては、ある程度の期間 (たとえば一年間) いちどもコミットがなかった人のコミット権を自動的に削除しているようなところもあります。 私はこれはあまりメリットがないと思っています。 というかむしろ逆効果でしょう。理由は次のふたつです。

まず、単にコミット権の有効期限切れを防ぐためだけの目的で、 あまり意味のない不要なコミットをする人が増えてくることになるでしょう。 次に、そんなことをしたところで何の意味もありません。 コミット権を与えるか否かを決める主要な条件は、 その人が正しい状況判断をできるかどうかです。 単にプロジェクトでの活動から一時離れていただけで 判断力が低下したと見なすことなんてできないでしょう? 仮に数年の間完全にプロジェクトから離れており、 その間コードも一切見ずに開発関連の議論にも目を通していなかったとしましょう。 それでも、プロジェクトに復帰した彼は 自分の状況をきちんと把握し、適切に振る舞ってくれることでしょう。 彼の判断力を信じたからこそコミット権を与えたはずです。 だったら最後まで信頼してあげましょうよ。 ハイスクールの卒業証書が期限切れになることがないのと同様に、 コミット権にだって有効期限なんかいらないはずです。

時には、コミッター自身から「私を削除してほしい」 「休眠状態であることをコミッター一覧 (この一覧についての詳細は 下の 「秘密主義を避ける」 をご覧ください) に明示してほしい」とお願いされることもあります。 そんな場合は、当然そのお願いを受け入れなければなりません。

誰かを新しいコミッターとして認めるかどうかについての議論は内密に行う必要がありますが、 認める基準やその手続きについては特に隠す必要はありません。 というか、公表してしまったほうがずっといいでしょう。 そうすれば、まるで星室庁 (Star Chamber) のような謎めいた組織だと見られることもなくなり、 よいパッチを投稿してコミュニティー内で認められさえすれば コミッターになれるのだと理解してもらえます。 Subversion プロジェクトでは、 この情報を開発者むけガイドラインドキュメントに記載しています。 コミット権を取得したいと考える人のほとんどは、 コードを書いてプロジェクトに貢献したいと考えているであろうからです。

コミッターになる手順を公開するだけでなく、 現在のコミッターの一覧 も公開します。この情報を公開する場所として昔からよく使われているのは、 プロジェクトのソースコードツリーの最上位にある MAINTAINERS あるいは COMMITTERS という名前のファイルです。 このファイルには、まずフルコミット権を持つメンバーの一覧を記載します。 その後に、各分野別に部分コミット権を持つコミッターの一覧を続けます。 各メンバーについて名前とメールアドレスを記載しますが、 メールアドレスについてはメンバーの希望に応じてスパム対策のエンコードを施すこともあります (3章技術的な問題 の 「アーカイブでのメールアドレスの処理」 をご覧ください)。

フルコミッターと部分コミッターは明確な基準で区別できるものなので、 一覧上でも区別しておくとよいでしょう。 ただ、プロジェクト内で必然的に発生する非公式な区別 (影響力の大きい人は誰かなど) までも一覧に反映させようとしてはいけません。 この一覧は公式な記録なのであり、覚え書きではありません。 コミッターの並び順は、単純にアルファベット順にするか コミッターになった時期の順にします。