这是章程的版本 1。
本文档定义了 Apache ZooKeeper 项目的运作章程。它定义了项目的职责和角色、谁可以投票、投票如何进行、如何解决冲突等。
ZooKeeper 是 Apache 软件基金会 的一个项目。该基金会拥有 Apache 代码的版权，包括 ZooKeeper 代码库中的代码。基金会常见问题解答 解释了基金会的运作和背景。
ZooKeeper 作为 Apache 项目的典型，它遵循一套原则，统称为 Apache 方式。如果您是 Apache 开发的新手，请参阅 孵化器项目，以了解有关 Apache 项目如何运作的更多信息。
Apache 项目定义了一组具有相关权利和职责的角色。这些角色决定了个人在项目中可以执行哪些任务。角色在以下部分中定义。
项目中最重要的参与者是使用我们软件的人员。我们的大多数贡献者最初都是用户，并从用户的角度指导其开发工作。
用户通过以错误报告和功能建议的形式向贡献者提供反馈，为 Apache 项目做出贡献。此外，用户还通过在邮件列表和用户支持论坛上帮助其他用户参与 Apache 社区。
所有为 ZooKeeper 项目贡献时间、代码、文档或资源的志愿者。对项目做出持续且受欢迎的贡献的贡献者可能会被邀请成为提交者，尽管此类邀请的确切时间取决于许多因素。
项目的提交者负责项目的技术管理。提交者可以访问指定子项目的存储库。子项目上的提交者可以对有关该子项目的任何技术讨论进行有约束力的投票。
提交者访问权限仅限于邀请，并且必须经过活跃 PMC 成员的懒惰共识批准。提交者被视为名誉提交者，由他或她自己声明，或在超过六个月的时间内没有审查补丁或向项目提交补丁。名誉提交者可以向 PMC 申请恢复提交访问权限，该权限必须经过活跃 PMC 成员的懒惰共识批准。
提交访问权限可以由所有活跃 PMC 成员（如果他或她也是 PMC 成员，则除有问题的提交者外）一致投票撤销。
所有 Apache 提交者都必须与 Apache 软件基金会签订已签署的 贡献者许可协议 (CLA)。有一个 提交者常见问题解答，其中提供了有关提交者要求的更多详细信息。
对项目做出持续贡献的提交者可能会被邀请成为 PMC 成员。贡献形式不限于代码。它还可以包括代码审查、在邮件列表上帮助用户、文档等。
PMC 负责管理和监督 Apache ZooKeeper 代码库，并对董事会和 ASF 负责。PMC 的职责包括
PMC 会员资格可以由除相关成员之外的所有活跃 PMC 成员一致投票撤销。
PMC 主席由 ASF 董事会任命。主席是 Apache 软件基金会（Apache ZooKeeper 副总裁）的职务持有者，并对 ZooKeeper PMC 范围内的项目管理对董事会负有主要责任。主席向董事会按季度报告 ZooKeeper 项目内的发展情况。
当 PMC 的现任主席辞职时，PMC 将投票推荐一位新主席，采用懒散共识，但该决定必须得到 Apache 董事会的批准。
在 ZooKeeper 项目中，不同类型的决策需要不同的批准形式。例如，上一节描述了几项需要“懒散共识”批准的决策。本节定义了如何进行投票、批准类型以及哪种类型的决策需要哪种类型的批准。
有关项目的决策通过在主要项目开发邮件列表 [email protected] 上投票做出。在必要时，PMC 投票可以在私有 ZooKeeper PMC 邮件列表 [email protected] 上进行。投票通过以 [VOTE] 开头的主题行明确表示。投票可能包含多个待批准的项目，这些项目应明确分开。通过回复投票邮件进行投票。投票可能有四种类型。
| 投票 | 含义 |
|---|---|
| +1 | “是”、“同意”或“应执行该操作”。一般而言，此投票还表示投票者愿意“使其发生”。 |
| +0 | 此投票表示愿意继续进行所考虑的操作。但是，投票者将无法提供帮助。 |
| -0 | 此投票表示投票者通常不同意提议的操作，但并不足以阻止该操作继续进行。 |
| -1 | 这是否定投票。在需要达成共识的问题上，此投票计为否决。所有否决都必须包含解释为什么否决是适当的。没有解释的否决无效。-1 投票也可能包含替代行动方案。 |
鼓励 ZooKeeper 项目中的所有参与者通过投票表示他们是否同意或反对某个特定行动。对于技术决策，只有活跃提交者的投票具有约束力。对于那些有约束力投票的人来说，非约束力投票仍然很有用，以便了解 ZooKeeper 社区更广泛地对某项行动的看法。对于 PMC 决策，只有 PMC 成员的投票具有约束力。
投票也可以应用于已对 ZooKeeper 代码库所做的更改。这些通常在提交时发送的提交消息中以否决 (-1) 的形式出现。请注意，这种情况应该很少发生。在提交代码之前，应尽一切努力讨论问题，当它们仍然是补丁时。
有可以寻求的批准类型。不同的操作需要不同类型的批准。
| 批准类型 | 定义 |
|---|---|
| 共识 | 要通过此项，所有具有约束力投票权的投票者都必须投票，并且不能有约束力否决 (-1)。由于让所有符合条件的选民投票不切实际，因此很少需要共识投票。 |
| 懒惰共识 | 懒惰共识需要 3 个约束性 +1 投票，并且没有约束性否决。 |
| 懒惰多数 | 懒惰多数投票需要 3 个约束性 +1 投票，并且约束性 +1 投票多于 -1 投票。 |
| 懒惰批准 | 具有懒惰批准的操作在未收到 -1 投票时被隐式允许，此时，根据操作类型，必须获得懒惰多数或懒惰共识批准。 |
| 2/3 多数 | 某些操作需要 2/3 的活跃提交者或 PMC 成员通过。此类操作通常会影响项目的根基（例如采用新的代码库来替换现有产品）。较高的门槛旨在确保此类更改得到大力支持。要通过此投票，至少需要 2/3 的约束性投票持有者投票 +1。 |
有效的、有约束力的否决不能被推翻。如果投了否决票，必须附上一个有效理由，解释否决的原因。如果否决的有效性受到质疑，任何具有约束力投票权的人都可以确认。这并不一定表示同意否决——仅仅表示否决是有效的。
如果你不同意有效的否决，你必须游说投否决票的人撤回他的或她的否决。如果否决没有被撤回，被否决的动作必须及时逆转。
本节描述了项目中进行的各种动作、该动作所需的相应批准以及对该动作拥有约束力投票权的人。它还指定了投票必须保持开放的最短时间，以工作日为单位。一般来说，不应该在已知项目感兴趣的成员无法参与的时间发起投票。
| 动作 | 描述 | 批准 | 约束力投票 | 最短时间（天） |
|---|---|---|---|---|
| 代码更改 | 对项目的代码库进行的更改，并由提交者提交。这包括源代码、文档、网站内容等。 | 懒惰批准（不计算贡献者的投票），如果收到 -1，则转向懒惰多数 | 活跃提交者 | 1 |
| 发布计划 | 定义发布的时间表和动作。该计划还提名一名发布经理。 | 懒惰多数 | 活跃提交者 | 3 |
| 产品发布 | 当项目的某个产品的发布准备就绪时，需要投票接受该发布作为项目的官方发布。 | 懒惰多数 | 活跃 PMC 成员 | 3 |
| 采用新代码库 | 当现有已发布产品的代码库要被替代代码库替换时。如果这样的投票未能获得批准，现有的代码库将继续存在。这也涵盖在项目中创建新的子项目。 | 2/3 多数 | 活跃 PMC 成员 | 6 |
| 新提交者或恢复 | 当为项目提议一名新提交者时。 | 懒惰共识 | 活跃 PMC 成员 | 3 |
| 新 PMC 成员或恢复 | 当为 PMC 提议一名提交者时。 | 懒惰共识 | 活跃 PMC 成员 | 3 |
| 提交者移除 | 当寻求移除提交权限时。注意：此类动作也将由 PMC 主席提交给 ASF 董事会。 | 共识 | 活跃 PMC 成员（如果 PMC 成员，则不包括有问题的提交者）。 | 6 |
| PMC 成员移除 | 当寻求移除 PMC 成员时。注意：此类动作也将由 PMC 主席提交给 ASF 董事会。 | 共识 | 活跃 PMC 成员（不包括有问题的成员）。 | 6 |
| 修改章程 | 修改此文档。 | 2/3 多数 | 活跃 PMC 成员 | 6 |