プロジェクトのソースコードがバージョン管理されているということは、 ほとんどの決定が元に戻せるということを意味します。 変更を元に戻す原因としてよくあるのが、 皆にとって良いものだと間違って思い込み、変更をコミットするというものですが、 これは結局コミットした後に反対意見が出てくることになります。 こうした反対意見は決まって、 以前の議論を見逃したことを詫びることから始まりますが、 反対する人がメーリングリストのアーカイブにこれにあたる議論を見つけられなかった場合は省略されます。 どちらにせよ、変更がコミットされる前と後とで議論の口調を変える理由はありません。 少なくとも、あるコミットに依存する変更が行われた時点 （i.e. もともと加えられていた変更が突然削除され、新しい変更がそれを壊していた場合） まで、変更は取り消すことができます。 バージョン管理システムは、プロジェクトにとってよくない、 または性急な判断から生じた結果を元に戻す手段を与えているのです。 これは言い替えれば、開発者が何かをする前にどのくらいのフィードバックが必要かということを、 自分の直感を信頼して判断してよい、ということでもあります。

このことは、合意を得る手続きを型にはめる必要がないということでもあります。 ほとんどのプロジェクトはこの手続きを感覚で扱っています。 小さな変更は、議論をしないか、最小限の議論だけして、2、3の賛成があったあとに行われます。 より重要な変更、特に多くのコードを不安定にさせる変更については、 開発者達は合意に達した、 つまり単にメールを頻繁にチェックしていなかっただけの理由で重要な議論をないがしろにしたヤツはいないはずだ、 という合理的な根拠があるとみなす前に、１日か２日の間を置くべきです。

というわけで、自分がやるべきことを理解しているのなら、 単に作業を進めてやり遂げるべきです。これはソフトウェアの修正だけでなく、 ウェブサイトの更新、ドキュメントの変更、 そして議論になりそうにない他のあらゆることに当てはまります。 通常、とられたアクションを元に戻す必要がある事例は少ししかないでしょうし、 そうした事例はケースバイケースで扱えます。 もちろん、聞く耳を持たないことを奨励すべきではありません。 議論中の事項と、既に実行されて効果が表れている決定事項の間には、 いくら技術的に元に戻せるとはいっても精神的な差があります。 開発者達は勢いが行動に繋がるといつも思っていますし、 実際に行われた変更を元に戻すのは、 はじめに変更するのをやめさせるほど、気が進まないものです。 ある開発者がこの事実を悪用し、議論が必要かもしれない変更を急いでコミットする場合、 他の開発者達は文句を言えますし、言うべきです。 そして事態が好転するまで、より厳しい基準をその開発者に守らせるべきでしょう。

議論によっては、結論がでないことが必ずあります。 行き詰まった状態を打開するあらゆる手段が失敗に終わった場合、 投票が打開策になります。 投票を行う前には、結論の候補となる選択肢を明確にしなければなりません。 ここで、普段やっている技術的な議論をしてみると、 結論を出す手続きと意外によく合っていることが再びわかるでしょう。 投票になる論点は、複雑で多面的な問題を含むことがたびたびあります。 こういう複雑な議論では、 仲裁人 の役割を果たす人が普通ひとりかふたりはいます。 彼らは定期的にさまざまな主張をまとめたものをポストし、 反対（賛成）意見の核がどこにあるのかを追いかけています。 こうしたまとめは、議論がどの位進んでいるのかを知ったり、 どういう問題に取り組んでいるのかを覚えておくのに役立ちます。 また、実際に投票が必要になった場合に、投票用紙のひな型として役立つかもしれません。 仲裁人が仕事をうまくこなせば、 時が来れば皆に投票しましょうと呼びかけることもできるでしょうし、 プロジェクトは彼らが作ったまとめをベースにした投票用紙を使うことができるでしょう。 仲裁人自身は、議論に参加していても構いません。 つまり、対立する人の意見を理解し、中立的に表現でき、 自分の同志の気持ちが議論を中立的にまとめるのを妨げなければ、 賛成、反対の立場を超越した立場にいる必要はないのです。

投票用紙の実際の内容は、議論の余地がないものになるのが普通です。 投票が実際に行われるまでに、反対意見は２、３のキーとなる問題にまとめられ、 理解できるラベルや簡単な説明が付けられます。 開発者が投票用紙の形式そのものに反対する場合もあります。 そういう人は、たとえば重要な選択肢が抜けていたり、 選択肢に対する正確な説明がないといった、 投票が正しいものかどうかを心配していることがありますが、 投票によって出る結論が自分の望むものに絶対ならないことを多分知っていて、 投票を避けようとしているだけの場合もあります。 この手の妨害行為をどう扱うかは、 6章コミュニケーション の、 「扱いにくい人たち」 を参照してください。

投票システムを必ず決めるようにしましょう。なぜなら、 投票システムにはたくさんの種類があり、どういった手続きがとられるのかについて 参加者が間違った想定をしている可能性があるからです。 ほとんどの場合に適しているのは 認定投票 です。 このシステムでは投票者が自分が好む選択肢をできるだけ多く投票できます。 認定投票は説明するのも、得票数を数えるのも簡単ですし、他の方法と異なり、 一回の投票で済みます。認定投票と他の投票システムの詳細については、 http://en.wikipedia.org/wiki/Voting_system#List_of_systems を参照してください。 しかしながら、どの投票システムを使うかについて、長く議論するのは避けるようにしましょう。 （当然、 投票システムを決めるのにどの投票システムを使うかを議論することになるからです！） 認定投票が優れた選択となる理由は、反対意見を表明することが難しいからです。 — つまり、投票システムはできるだけ公平であるべきということです。

最後に、投票は公開の場で行いましょう。 どちらにせよ、公開の場で議論した問題について、 秘密投票にしたり、匿名投票にしたりする必要はありません。 オブザーバが投票を記録し、結果をチェックできるように、 そしてすべてをアーカイブに記録するために、 投票の参加者には、 プロジェクトのメーリングリストに自分の投票をポストさせるようにしましょう。

投票で最も難しいのは、いつ投票を行うかです。一般的には、 投票に実際に踏み切ることは滅多にすべきではありません— つまり、他のあらゆる手段が失敗したときの最後の手段にすべきです。 投票が議論を解決する素晴らしい手段だと看做さないでください。 実際、そうではないのです。投票は議論を終結させ、 それによって問題について創造的に考えることもやめさせてしまうのです。 議論が続いている限り、皆が好む新しい解決策を誰かが思い付く可能性があります。 これは驚くほどたびたび起こります。活発な議論は、 問題について新しい考え方を生み出しますし、結局皆を満足させる提案にも繋がります。 たとえ新しい提案が生まれなくても、投票を行うよりは、 妥協案を仲介してもらった方が通常はまだマシです。 妥協したあとは、皆がちょっと悲しい思いをします。 一方で、投票をしたあとは喜ぶ人がいる一方で、悲しい思いをする人もいます。 政治的な観点からは、前者の方が好ましいといえます。 なぜなら、少なくともひとりひとりが自分の悲しい思いに対して対価を支払っているからです。 満足はしないかもしれませんが、それは他の誰もが同じなのです。

投票の主な利点は、皆が次に進める形で問題を最終的に解決してくれることです。 しかし、投票は皆を理性的な対話によって同じ結論に導くのではなく、 頭数で問題を解決してしまいます。私は、オープンソースプロジェクトで経験を積めば積むほど、 人々が問題を投票によって解決したがらなくなるのがわかってきました。 むしろ、以前考えたこともない解決策を探ったり、 もともとの計画よりも厳しい妥協をしようとします。 早まった投票を避けるために様々なテクニックがあります。もっとも明白なやり方は、 "まだ投票を実施する段階ではないと思うよ。" といって、何故かを説明することです。 別のやり方として、非公式に賛成の人は手を挙げてもらう（拘束力はありません）ことがあります。 その反応が明らかに一方に偏っていたら、 正式に投票を行うのを避けるために、積極的に妥協することを人々に促すことになるでしょう。 もっとも効率的なやり方は、人々が同じ主張を繰り返さずに問題に再び取り組めるように、 新しい解決策や、以前の提案に基づいた新しい視点を示すことです。

まれなケースとして、示された全ての妥協案は、 妥協していない全ての案よりも劣っていることで全員が一致することがあります。 この場合、投票を実施することに反対しにくくなります。なぜなら、 投票の方がより優れた解決に繋がる可能性がありますし、 どのような結果になっても全員が過度に悲しい思いをすることはないからです。 たとえそうであっても、投票を急ぐべきではありません。 投票に至るまでの議論は有権者にいろいろなことを教えるので、 議論を早い段階でやめてしまうと、投票の結果出てくるものの質が悪くなるかもしれません。

（投票をしたがるなというアドバイスは、 7章パッケージの作成、リリース、日々の開発 の 「リリースを安定させるプロセス」 で説明している、 ソースコードに大幅な変更を加える投票には当てはまりません。 そこでは、投票は対話のメカニズムとして働き、 有権者を変更をレビューする手続きに参加させる手段となります。 それによって、 有権者は与えられた変更がどの程度のレビューを経ているのかを区別することができるのです。）

投票システムを使うとなると、有権者に関する疑問が出てきます。 誰が投票権を得るのか、という問題です。これは繊細な問題となる可能性があります。 なぜなら、どの人が熱心にプロジェクトに参加しているかとか、 どの人がよりよい判断を下せるか、 ということをプロジェクトに公式に認めさせることになるからです。

一番よいのは、既にある権限の区別、 つまりコミット権限を単純に利用し、その権限に投票権限も付加することです。 完全なコミット権限と、限定的なコミット権限を提供しているプロジェクトで、 限定的なコミット権限を持つ人に投票権を与えるかどうかは、 コミット権限を与える手続きがどのようなものかに大きく依存します。 たくさんのサードパーティーのツールをリポジトリで管理させるようなやり方で、 プロジェクトがコミット権限を気前よく配分している場合、 限定的なコミット権限が単にリポジトリにコミットする権限だけで、 投票権限はないことを明確にすべきです。 逆に考えると、同じことが当然当てはまります。 つまり、完全なコミット権限を持つ人には投票権限もあるのだから、 彼らはプログラマーとしてではなく、投票権限のあるメンバーとして選ばれなければならない。 ということになります。 メーリングリスト上で破壊的な発言をしたり、 プロジェクトを妨害する傾向がある人がいる場合は、 プロジェクトはたとえその人が技術的に優れていたとしても、 コミット権限を与える際に注意する必要があります。

完全なコミット権限にせよ、限定的なものにせよ、 新しいコミッターを選ぶには投票システムを使うべきですが、 この場合は秘密投票が適切になるまれな事例のひとつです。 コミッターになる可能性がある人について、メーリングリストで投票を行うことはできません。 なぜなら、候補者の感情(評判）を傷つけてしまう可能性があるからです。 代わりに普通使われるのは、 コミッターのみで構成されるプライベートなメーリングリストに、 コミット権限を与える提案をし、 それに対して既にいるコミッターが投票する方法です。 他のコミッターはそこで行われる議論がプライベートなことを知っているので、 自分の思うところを自由に述べていきます。 そこで反対意見が出ないために、投票が必要ないこともあります。 他のコミッターに反対意見を述べるチャンスを必ず与えるために２、３日待ったあと、 提案者はコミッターになる候補者にメールしてコミット権限を与えます。 反対意見があった場合は、他の問題と同じように議論が行われ、おそらく投票が行われるでしょう。 このプロセスをオープンかつ率直なものにするにせよ、 議論はとにかく非公開で行うべきです。 コミット権限を与えようと考えている人が、何が起きているのかを知っていて、 権限を貰えなかった場合、自分は投票権も失ったんだと決めつけてしまったり、 傷ついてしまう可能性もあるでしょう。 もちろん、誰かが明示的にコミット権限が欲しいと頼んできた場合は、その提案について検討し、 受け入れるか拒むかの回答を明示的に行うしかありません。 仮に拒む場合は、はっきりと説明を沿えてできるだけ丁寧に断るべきです。 たとえば "開発者チームは君のパッチを気に入っているけれども、量がまだ十分でない。" とか、 "開発チームは君のパッチを全て高く評価しているけど、適用する前にかなり調整が必要なんだ。 だからコミット権限を与えるのが好ましいと思えない。 このことは時間をかけて改善して欲しいと願っている。" という感じです。 ただ、その人との信頼関係の度合によりますが、 あなたの発言が相手にショックを与える可能性があることを忘れないように。 メールを書くときは、相手の視点からメールを眺めるようにしましょう。

新しいコミッターを加えることは、 他のほとんどの一度限りの決定よりもより重大なので、 プロジェクトによっては投票に特別な要件を課すところもあります。 たとえば、その提案には 少なくとも n 票の賛成票が必須で、 反対票があってはいけないとか、圧倒的多数の賛成票が必須、といったものです。 正確な賛成票の数は重要ではありません。 中心となる考え方は、開発チームが新しいコミッターを加えるのに慎重であるべき、というものです。 コミット権限を 奪う 場合にも、投票には似たような、 あるいはもっと厳格な要件が必要です。 まぁしかし、こんなルールを必要としないのが望ましいのですが。 コミット権限を与えたり、奪ったりすることの、投票以外の側面に関する詳しい情報は、 8章ボランティアの管理 の 「コミッター」 を参照してください。

ある種の投票では、有権者を広げた方がいいかもしれません。 たとえば、 与えられたユーザーインターフェイスがユーザーのソフトウェアの使い方と合うかどうかを、 開発者が決められない場合、 プロジェクトのメーリングリストを購読している人全員に尋ねてみるのがひとつの解になります。 これは投票というよりむしろ 世論調査 ですが、 開発者はその結果を拘束力のあるものとして扱っても構いません。 どういった調査であっても、 与えられている選択肢以外の回答を記入できることを必ず参加者に明示するようにしましょう。 調査の質問として与えられた選択肢よりも優れた回答を考えている人がいる場合、 調査の結果、その回答がもっとも重要だとわかる場合があるからです。

プロジェクトによっては、 拒否権 として知られる特別な投票権を許しています。 拒否権は性急に、または思いつきで行われた変更で、 少なくとも皆でもっと議論する時間が必要な場合に、 開発者がそれをやめさせる手段になります。 拒否権は、とても強い反対と、 議事の進行を妨害することの中間に位置すると考えるとよいでしょう。 正確な意味はプロジェクトによって異なります。 プロジェクトによっては拒否権を無効にするのがとても難しいところもありますし、 おそらくは、 もっと議論をするために強制的に時間を置いたあとで、 通常の投票権で多数の得票を得れば、 拒否権を無効にできるプロジェクトもあります。 どんな拒否権であっても、説明が一通り行われてから行使すべきです。 説明もされないのに行使された拒否権は無効なものと考えるべきでしょう。

拒否権を許すと、それが濫用されるという問題が起きます。 開発者たちは、もっと議論が必要なときに拒否権を行使することで、 リスクを増やしたくないと考えています。 あなたは、自分自身が拒否権をとても慎重に行使し、 そして拒否権を多く行使し続けている人がいる場合に、 丁寧にそれを指摘することによって拒否権の濫用を防ぐことができます。 必要とあらば、開発者たちが拒否権に拘束力があると長期に渡って賛同している場合にだけ、 拒否権に拘束力を持たせるよう求めることもできます — 結局は、明らかに大多数の開発者が X を望んでいる場合は、 その X が将来何かにつけ発生するでしょうから。 その場合は、拒否権を行使している開発者がそれを取り下げるか、 グループが拒否権の力を弱くする決定をすることになるでしょう。

拒否権を行使するのに "-1" と書く人を見かけるかもしれません。 この使い方は、高度に組織化された投票と拒否権システムを持つ Apache Software Foundation で生まれたものです。 これについては http://www.apache.org/foundation/voting.html に説明があります。 Apache プロジェクトの基準は他のプロジェクトにも広まっているので、 オープンソース界の多くの場所で、 彼らの規約が形を変えて使われているのを見ることになるでしょう。 技術的には、Apache プロジェクトの基準に照らしても、 "-1" という表現が正式に拒否権を行使していることを必ずしも表すわけではありません。 しかし、非公式には拒否権を行使している、 もしくは少なくとも強い反対の意志を示していると普通は受け取られます。

投票と同じく、拒否権の効果は遡って適用できます。 疑問が持たれている変更が既にコミットされている、 もしくはアクションが既に起こされているという理由で、 （既にプレスリリースが出ている場合のように、 取り返しが付かないものでなければ） 拒否権に対して異を唱えるのはよくありません。 言いかえれば、何週間、何ヶ月もたったあとに拒否権が行使されても、 それが真面目に取り上げられる可能性は少ないですし、 真面目に取り上げるべきでもありません。