これは規約のバージョン1です。
この文書は、Apache ZooKeeperプロジェクトが運用される規約を定義しています。プロジェクトの役割と責任、投票権を持つ者、投票方法、紛争解決方法などを規定しています。
ZooKeeperはApache Software Foundationのプロジェクトです。財団は、ZooKeeperコードベースを含むApacheコードの著作権を保有しています。財団のFAQは、財団の運用と背景を説明しています。
ZooKeeperは、Apache Wayとして総称される一連の原則に基づいて運用されている点で、典型的なApacheプロジェクトです。Apache開発が初めての方は、Apacheプロジェクトの運用方法に関する詳細についてはインキュベータープロジェクトを参照してください。
Apacheプロジェクトは、関連する権利と責任を持つ役割のセットを定義しています。これらの役割は、個人がプロジェクト内で実行できるタスクを規定します。役割は次のセクションで定義されています。
プロジェクトで最も重要な参加者は、当社のソフトウェアを使用する人々です。私たちの貢献者の大多数はユーザーとして始まり、ユーザーの視点から開発努力を導きます。
ユーザーは、バグレポートや機能提案の形で貢献者にフィードバックを提供することにより、Apacheプロジェクトに貢献します。また、ユーザーはメーリングリストやユーザーサポートフォーラムで他のユーザーを支援することにより、Apacheコミュニティに参加します。
ZooKeeperプロジェクトに時間、コード、ドキュメント、またはリソースを提供しているすべてのボランティア。プロジェクトに継続的で歓迎される貢献をするコントリビューターは、コミッターになるように招待される場合がありますが、そのような招待の正確なタイミングは多くの要因に依存します。
プロジェクトのコミッターは、プロジェクトの技術管理を担当します。コミッターは、指定されたサブプロジェクトのリポジトリにアクセスできます。サブプロジェクトのコミッターは、そのサブプロジェクトに関する技術的な議論について拘束力のある投票を行うことができます。
コミッターへのアクセスは招待制であり、アクティブなPMCメンバーの暗黙の了解を得る必要があります。コミッターは、自己申告または6ヶ月以上パッチのレビューやプロジェクトへのパッチのコミットを行わなかった場合、名誉コミッターとみなされます。名誉コミッターは、PMCからのコミットアクセス復旧を要求できますが、これはアクティブなPMCメンバーの暗黙の了解を得る必要があります。
コミットアクセスは、アクティブなすべてのPMCメンバー(問題のコミッターがPMCメンバーでもある場合は除く)による満場一致の投票によって取り消すことができます。
すべてのApacheコミッターは、Apache Software Foundationに署名されたコントリビューターライセンス契約(CLA)を提出する必要があります。コミッターFAQは、コミッターの要件についてさらに詳しく説明しています。
プロジェクトに継続的な貢献をしたコミッターは、PMCのメンバーになるように招待される場合があります。貢献の形態はコードに限定されません。コードレビュー、メーリングリストでのユーザーの支援、ドキュメントなども含まれます。
PMCは、Apache ZooKeeperコードベースの管理と監督について、ボードとASFに対して責任を負います。PMCの責任には以下が含まれます。
PMCのメンバーシップは、問題のメンバー以外のすべてのアクティブなPMCメンバーの満場一致の投票によって取り消すことができます。
PMCの議長はASFボードによって任命されます。議長はApache Software Foundation(ZooKeeper担当副社長)の役職者であり、ZooKeeper PMCの範囲内のプロジェクトの管理についてボードに対して第一義的な責任を負います。議長は、ZooKeeperプロジェクトの進展について四半期ごとにボードに報告します。
現PMC議長が辞任した場合、PMCは暗黙の了解に基づいて新しい議長を推薦するための投票を行い、その決定はApacheボードによって承認される必要があります。
ZooKeeperプロジェクト内では、さまざまな種類の決定に異なる承認形式が必要です。たとえば、前のセクションでは、「暗黙の了解」の承認を必要とするいくつかの決定について説明しています。このセクションでは、投票方法、承認の種類、およびどの種類の決定にどの種類の承認が必要かを定義します。
プロジェクトに関する決定は、主要なプロジェクト開発メーリングリストdev@zookeeper.apache.orgでの投票によって行われます。必要に応じて、PMC投票は非公開のZooKeeper PMCメーリングリストprivate@zookeeper.apache.orgで行うことができます。投票は、[VOTE]で始まる件名行で明確に示されます。投票には承認する複数の項目を含めることができ、これらは明確に区別する必要があります。投票は投票メールに返信して行います。投票には4つの種類があります。
投票 | 意味 |
---|---|
+1 | 「はい」、「同意」、「アクションを実行する必要があります」。一般的に、この投票は、投票者が「実現させる」ことに喜んで参加することを示しています。 |
+0 | この投票は、検討中のアクションを進めることに喜んで参加することを示しています。ただし、投票者は手伝うことができません。 |
-0 | この投票は、投票者が提案されたアクションに一般的に同意していないが、アクションを進めるのを妨げるほど懸念していないことを示しています。 |
-1 | これは否決票です。コンセンサスが必要な問題では、この投票は拒否権としてカウントされます。すべての拒否権には、拒否権が適切な理由の説明が含まれている必要があります。説明のない拒否権は無効です。-1投票に代替策を含めることも適切な場合があります。 |
ZooKeeperプロジェクトのすべての参加者は、投票によって特定のアクションへの賛成または反対を示すように促されます。技術的な決定では、アクティブなコミッターの投票のみが拘束力があります。拘束力のない投票は、拘束力のある投票を持つ人々が、より広いZooKeeperコミュニティにおけるアクションの認識を理解するのに役立ちます。PMCの決定では、PMCメンバーの投票のみが拘束力があります。
投票は、ZooKeeperコードベースに既に加えられた変更にも適用できます。これらは通常、コミットが行われたときに送信されるコミットメッセージへの拒否権(-1)の形をとります。これはまれなケースであるべきであることに注意してください。コードがコミットされる前に、パッチである間はまだ問題を議論するようあらゆる努力をする必要があります。
求められる承認の種類があります。異なるアクションには、異なる種類の承認が必要です。
承認の種類 | 定義 |
---|---|
コンセンサス | これを可決するには、拘束力のある投票を持つすべての投票者が投票する必要があり、拘束力のある拒否権(-1)があってはいけません。コンセンサス投票は、資格のあるすべての投票者が投票を行うことの非現実性のために、めったに必要ありません。 |
暗黙の了解 | 暗黙の了解には、3票の+1と拘束力のある拒否権がないことが必要です。 |
過半数 | 過半数投票には、3票の+1と-1票よりも多くの+1票が必要です。 |
暗黙の承認 | -1票が受信されない限り、暗黙の承認を持つアクションは暗黙的に許可され、その場合、アクションの種類に応じて、過半数または暗黙の了解の承認を得る必要があります。 |
3分の2の過半数 | 一部のアクションには、アクティブなコミッターまたはPMCメンバーの3分の2の過半数が必要です。このようなアクションは通常、プロジェクトの基礎に影響を与えます(例:既存の製品に代わる新しいコードベースを採用する)。より高い閾値は、このような変更が強く支持されるように設計されています。この投票を通過するには、拘束力のある投票者の少なくとも3分の2が+1と投票する必要があります。 |
有効な拘束力のある拒否権は覆すことができません。拒否権が与えられる場合、拒否権の理由を説明する有効な理由を添える必要があります。拒否権の有効性は、異議申し立てがあった場合、拘束力のある投票を持つ者によって確認できます。これは必ずしも拒否権への同意を意味するものではなく、拒否権が有効であることを意味するだけです。
有効な拒否権に同意しない場合は、拒否権を与えた人に拒否権の撤回を働きかける必要があります。拒否権が撤回されない場合、拒否されたアクションはタイムリーに元に戻す必要があります。
このセクションでは、プロジェクト内で実行されるさまざまなアクション、そのアクションに必要な対応する承認、アクションについて拘束力のある投票を持つ者について説明します。また、営業日単位で測定した投票を公開しておく必要のある最短期間も指定します。一般的に、プロジェクトの利害関係者が利用できないことが分かっている時期に投票を呼びかけるべきではありません。
アクション | 説明 | 承認 | 拘束力のある投票 | 最短期間(日) |
---|---|---|---|---|
コード変更 | プロジェクトのコードベースに加えられ、コミッターによってコミットされた変更。これには、ソースコード、ドキュメント、ウェブサイトのコンテンツなどが含まれます。 | 暗黙の承認(コントリビューターの投票は除く)、-1が受信された場合は過半数に移行 | アクティブなコミッター | 1 |
リリースプラン | リリースのタイムテーブルとアクションを定義します。このプランでは、リリースマネージャーも指名されます。 | 過半数 | アクティブなコミッター | 3 |
製品リリース | プロジェクトの製品の1つのリリースの準備が整った場合、そのリリースをプロジェクトの公式リリースとして承認するための投票が必要です。 | 過半数 | アクティブなPMCメンバー | 3 |
新しいコードベースの採用 | 既存のリリース済み製品のコードベースを代替のコードベースに置き換える場合。このような投票が承認を得られない場合、既存のコードベースはそのまま維持されます。これは、プロジェクト内の新しいサブプロジェクトの作成にも適用されます。 | 3分の2の多数決 | アクティブなPMCメンバー | 6 |
新規コミッターまたは復権 | プロジェクトに新規コミッターが提案された場合。 | 暗黙の了解 | アクティブなPMCメンバー | 3 |
新規PMCメンバーまたは復権 | コミッターがPMCに提案された場合。 | 暗黙の了解 | アクティブなPMCメンバー | 3 |
コミッター削除 | コミット権限の削除が求められた場合。注記:このような行為は、PMCチェアによってASFボードにも報告されます。 | コンセンサス | アクティブなPMCメンバー(問題のコミッターがPMCメンバーである場合は除く)。 | 6 |
PMCメンバー削除 | PMCメンバーの削除が求められた場合。注記:このような行為は、PMCチェアによってASFボードにも報告されます。 | コンセンサス | アクティブなPMCメンバー(問題のメンバーを除く)。 | 6 |
規約の変更 | このドキュメントの変更。 | 3分の2の多数決 | アクティブなPMCメンバー | 6 |