Apacheフレームワーク内で物事を達成するための基本的な側面の一つが、コンセンサスによって行うことであるため、コンセンサスに達したかどうかを判断する方法が必要です。 これを投票によって行います。
投票には、基本的に3つの種類があります。
手続き的なもの
コードの変更
パッケージのリリース
手続き的な問題に関する投票は、特に明記されていない限り、多数決という共通の形式に従います。 つまり、賛成票が反対票より多ければ、各カテゴリーの投票数に関係なく、その問題は可決されたと見なされます。(投票数がコミュニティのコンセンサスを代表するには少なすぎると思われる場合、その問題は通常追求されません。ただし、変更要因については、レイジーコンセンサスの説明を参照してください。)
コードの変更に関する投票は、異なるモデルに従います。 このシナリオでは、反対票は、投票グループ (通常はプロジェクトの PMC) が覆すことのできない拒否権を構成します。 このモデルは、投票のリクエストが提起されたときにレイジーコンセンサスの宣言によって変更される可能性がありますが、反対票の絶対的な性質は変わりません。 通常の (レイジーコンセンサスではない) 条件では、提案を可決するには、3つの賛成票と反対票がないことが必要です。必要な支持を得ることができなかった場合、可決されません。その後、提案者は提案を撤回するか、コードを変更して再提出するか、または誰かが削除するまで提案は未解決の問題として残ります。
パッケージをリリースする準備ができているかどうかに関する投票では、さらに別のメカニズムが使用されます。少なくとも3つの拘束力のある賛成票がリリースに必要ですか？ 投票と拘束力のある投票の要件の詳細については、リリースポリシーを参照してください。
誰が投票できるかは、ある程度、コミュニティ固有のものです。
PMC メンバーは正式に拘束力のある投票権を持っていますが、一般的にコミュニティは、たとえ投票が助言に過ぎないとしても、すべてのメンバーに投票を推奨しています。
場合によっては、またコミュニティによっては、投票の行使はすぐには明白でないいくつかの責任を伴います。 たとえば、場合によっては、賛成票は「私は承認しますそして私は喜んで手伝います」という暗黙のメッセージを伝えます。また、反対票は、「私は反対しますが、代替案があり、その代替案で手伝います」という意味を持つ場合があります。
コミュニティは、投票の暗黙の意義をガイドラインで明確にする必要があります。 ただし、暗黙のコミットメントを満たしていないように見えたとしても、いかなる場合でも誰かの投票が無効と見なされることはありません。投票は、コミットメントのではなく、意見の正式な表明です。
R-T-C ポリシーが有効になっている場合、賛成票は、「私はこのパッチを自分でテストし、良好であることを確認しました」という非常に強い暗黙のメッセージを伝えます。 同様に、反対票は通常、投票者がパッチをテストして良くないことを発見したことを意味しますが、(このケースでの拒否権は) 他の技術的な根拠に基づいている可能性があります。
Apache の投票プロセスは、これまで遭遇したことがない場合は、少し奇妙に見えるかもしれません。 投票は -1 から +1 の間の数値で表され、'-1' は「いいえ」、'+1' は「はい」を意味します。
中間の値は、投票者がどれほど強く感じているかを示します。 以下に、小数投票の例と、投票者がそれらによって伝えようとしている可能性のある内容を示します。
+0： 「強くは感じませんが、これで大丈夫です。」
-0： 「邪魔はしませんが、これはやらない方がいいと思います。」
-0.5： 「このアイデアは好きではありませんが、自分の気持ちを合理的に正当化することはできません。」
++1： 「すごい！これが好きです！やりましょう！」
-0.9： 「これは本当に好きではありませんが、他の誰もがそれを進めたいのであれば邪魔はしません。」
+0.9： 「これはクールなアイデアで気に入っていますが、手伝うために必要な時間やスキルがありません。」
リリースに関する PMC メンバーからの投票は、拘束力があると見なされるためには、+1、0、-1 を使用する必要があります。
投票期間は、地理的な場所に関係なく、すべての関係者が参加する機会を提供するために、通常、少なくとも 72 時間継続する必要があります。
コード変更の投票では、+1 の投票は提案に賛成しますが、-1 の投票は拒否権であり、すべての拒否者が -1 の投票を撤回するまで提案を無効にします。
提案者が投票がレイジーコンセンサスを使用していると宣言しない限り、コード変更提案を可決するには 3 つの +1 票が必要です。
投票者が表現している意見はブール値であるため、「この変更を承認/承認しない」となるため、このタイプの投票には整数を使用することをお勧めします。
パッケージをリリースする準備ができているかどうかに関する投票では、多数決承認を使用します。つまり、少なくとも3人の PMC メンバーがリリースに賛成票を投じる必要があり、否定的な票よりも肯定的な票が多くなければなりません。 リリースは拒否できません。通常、誰かが重大な問題を特定した場合、コミュニティはリリース投票を取り消しますが、ほとんどの場合、最終的な決定はリリース管理者としての役割を果たす個人にあります。 プロセスの詳細はプロジェクトごとに異なる場合がありますが、「3票以上の+1票の最小定足数」ルールは普遍的です。
リリース管理者、または ASF 投票の誰もが暗黙の +1 を持っていないことに注意してください。 明示的な投票のみが有効です。 リリース管理者は、レビュー担当者と同様に、リリース時に投票することが推奨されます。
資格のある投票者による -1 投票は、コード変更提案を阻止します。 これは拒否権を構成し、誰にも覆されたり、無効にされたりすることはありません。 拒否権は、個人が拒否権を撤回するまで存続します。
拒否権が気まぐれに使用されるのを防ぐために、投票者は、変更がなぜ悪いのか (セキュリティの脆弱性を開く、パフォーマンスに悪影響を与える、など) を示す技術的な正当性とともに拒否権を提供する必要があります。 正当性がない拒否権は無効であり、影響はありません。
投票の代替案は、レイジーコンセンサスの概念を使用して、何かの受け入れやすさを測定することです。
レイジーコンセンサスは、単に「沈黙は同意を与える」という発表です。 誰かがこの方法でコミュニティの感覚を判断したい場合、次のようなメールメッセージでそうする可能性があります。
"The patch below fixes bug #8271847; if no-one objects within three
days, I'll assume lazy consensus and commit it."
レビューアンドコミットポリシーが有効になっている場合、コード変更にレイジーコンセンサスを適用することはできません。
人々は対立を避け、誰かが担当している、ルール、プロセス、停滞に代わるものを探してうろつく傾向があります。 これらのいずれも、対立を解決するという困難な作業を行うための優れた代替案にはなりにくい傾向があります。