Apache ZooKeeper项目章程

这是章程的第1版。

引言

本文档定义了Apache ZooKeeper项目运作的章程。它定义了项目的角色和职责、谁可以投票、投票如何进行、冲突如何解决等。

ZooKeeper是Apache软件基金会的一个项目。基金会拥有包括ZooKeeper代码库在内的Apache代码的版权。基金会常见问题解答解释了基金会的运作和背景。

ZooKeeper是典型的Apache项目，它遵循一套原则，统称为Apache之道（Apache Way）。如果您刚接触Apache开发，请参阅孵化器项目（Incubator project），了解更多关于Apache项目如何运作的信息。

角色和职责

Apache项目定义了一系列具有相关权利和职责的角色。这些角色规定了个人在项目内部可以执行哪些任务。这些角色在以下章节中定义。

用户

项目中最重要的参与者是使用我们软件的人。我们的大多数贡献者都是从用户开始的，并从用户的角度指导他们的开发工作。

用户通过以错误报告和功能建议的形式向贡献者提供反馈来为Apache项目做出贡献。此外，用户还通过在邮件列表和用户支持论坛上帮助其他用户来参与Apache社区。

贡献者

所有向ZooKeeper项目贡献时间、代码、文档或资源的志愿者。对项目做出持续且受欢迎贡献的贡献者可能会被邀请成为提交者（committer），尽管邀请的具体时间取决于许多因素。

提交者

项目的提交者负责项目的技术管理。提交者有权访问指定的一组子项目的仓库。子项目的提交者可以就该子项目的任何技术讨论投下具有约束力的票。

提交者权限仅通过邀请获得，并且必须获得活跃PMC成员的惰性一致（lazy consensus）批准。提交者通过自行声明或连续六个月未审查补丁或提交补丁到项目而被视为荣誉退职（emeritus）。荣誉退职的提交者可以向PMC申请恢复提交权限，这必须获得活跃PMC成员的惰性一致批准。

提交权限可以通过所有活跃PMC成员（如果相关提交者也是PMC成员，则不包括该提交者）一致投票决定撤销。

所有Apache提交者都必须向Apache软件基金会提交一份已签署的贡献者许可协议（CLA）。还有一个提交者常见问题解答，提供了更多关于提交者要求的详细信息。

对项目做出持续贡献的提交者可能会被邀请成为PMC成员。贡献的形式不限于代码。它还可以包括代码审查、在邮件列表上帮助用户、文档等。

项目管理委员会

PMC对董事会和ASF负责Apache ZooKeeper代码库的管理和监督。PMC的职责包括

• 决定作为Apache ZooKeeper项目产品发布的内容。特别是所有发布版本都必须经过PMC批准。
• 维护项目的共享资源，包括代码库仓库、邮件列表、网站。
• 代表项目发言。
• 解决关于项目产品的许可证争议。
• 提名新的PMC成员和提交者。
• 维护本章程和项目的其他准则。
• PMC成员资格仅通过邀请获得，并且必须获得活跃PMC成员的惰性一致批准。PMC成员通过自行声明或连续六个月未以任何形式为项目做出贡献而被视为荣誉退职。荣誉退职成员可以申请恢复PMC资格，这必须获得活跃PMC成员的惰性一致批准。

PMC成员资格可以通过所有活跃PMC成员（除相关成员外）一致投票决定撤销。

PMC主席由ASF董事会任命。主席是Apache软件基金会的职位持有者（Apache ZooKeeper副总裁），并对董事会负责管理ZooKeeper PMC范围内的项目。主席每季度向董事会报告ZooKeeper项目内的进展。

当现任PMC主席辞职时，PMC投票推荐新的主席（使用惰性一致），但该决定必须得到Apache董事会的批准。

决策制定

在ZooKeeper项目内部，不同类型的决策需要不同形式的批准。例如，前一章节描述了几项需要“惰性一致”批准的决定。本章节定义了投票如何进行、批准的类型以及哪种类型的决策需要哪种类型的批准。

投票

有关项目的决定通过在主要项目开发邮件列表 dev@zookeeper.apache.org 上投票做出。必要时，PMC投票可以在ZooKeeper PMC私有邮件列表 private@zookeeper.apache.org 上进行。投票通过以 [VOTE] 开头的邮件主题明确标示。投票可能包含多个批准事项，这些事项应明确分开。投票通过回复投票邮件进行。投票可能有四种类型。

投票	含义
+1	+1: “是”、“同意”或“应该执行该行动”。通常，此投票也表示投票者愿意“促成其发生”。
+0	+0: 此投票表示愿意让正在考虑的行动继续进行。然而，投票者将无法提供帮助。
-0	-0: 此投票表示投票者通常不赞同拟议的行动，但也不介意到足以阻止该行动继续进行。
-1	-1: 这是一个反对票。在需要达成共识的问题上，此投票视为否决票（veto）。所有否决票必须包含解释为何该否决是合适的理由。没有解释的否决票无效。-1票也可能包含替代行动方案。

鼓励所有ZooKeeper项目参与者通过投票表达对特定行动的赞同或反对。对于技术决策，只有活跃提交者的投票具有约束力。不具约束力的投票对于拥有约束力投票的人理解该行动在更广泛的ZooKeeper社区中的看法仍然有用。对于PMC决策，只有PMC成员的投票具有约束力。

投票也可以应用于已对ZooKeeper代码库进行的更改。这通常以否决票（-1）的形式回复在提交代码时发送的提交消息。请注意，这种情况应该很少发生。在代码提交之前，应尽一切努力在问题还是补丁阶段进行讨论。

批准类型

可以寻求的批准类型有几种。不同的行动需要不同类型的批准。

批准类型	定义
一致同意	要通过此项，所有拥有约束力投票权的投票者都必须投票，并且不能有具有约束力的否决票（-1）。由于让所有符合条件的投票者都投下票不切实际，因此很少需要一致同意投票。
惰性一致	惰性一致需要3个具有约束力的+1票且没有具有约束力的否决票。
惰性多数	惰性多数投票需要3个具有约束力的+1票，并且具有约束力的+1票数量多于-1票数量。
惰性批准	惰性批准的行动在未收到-1票的情况下默认允许，一旦收到-1票，根据行动类型，必须获得惰性多数或惰性一致批准。
三分之二多数	某些行动需要活跃提交者或PMC成员的三分之二多数才能通过。此类行动通常影响项目的基础（例如，采用新的代码库替换现有产品）。较高的门槛旨在确保此类变更获得强有力的支持。要通过此投票，需要至少三分之二的具有约束力投票权持有者投+1票。

否决票

有效的、具有约束力的否决票不能被推翻。如果投下否决票，必须附带说明否决理由的有效解释。否决票的有效性，如果受到质疑，可以由任何拥有约束力投票权的人确认。这不一定表示同意该否决票——仅表示该否决票是有效的。

如果您不同意有效的否决票，您必须游说投下否决票的人撤回其否决票。如果否决票未被撤回，被否决的行动必须及时撤销。

行动

本章节描述了项目内部进行的各种行动、该行动所需的相应批准以及对该行动拥有约束力投票权的人。它还规定了投票必须开放的最短时间长度，以工作日计算。一般来说，在已知项目相关成员无法参与时，不应发起投票。

行动	描述	批准	约束力投票权	最短持续时间（天）
代码变更	由提交者对项目代码库进行的更改并提交。这包括源代码、文档、网站内容等。	惰性批准（不计算贡献者的投票），如果收到-1票则转为惰性多数	活跃提交者	1
发布计划	定义发布的日程表和行动。计划还提名一位发布经理。	惰性多数	活跃提交者	3
产品发布	当项目的某个产品发布版本准备就绪时，需要进行投票以接受该版本作为项目的正式发布版本。	惰性多数	活跃PMC成员	3
采用新的代码库	当现有已发布产品的代码库要被替代代码库替换时。如果此类投票未能获得批准，现有代码库将继续使用。这也包括在项目内部创建新的子项目。	三分之二多数	活跃PMC成员	6
新提交者或恢复资格	当为项目提议新的提交者时。	惰性一致	活跃PMC成员	3
新PMC成员或恢复资格	当提议提交者加入PMC时。	惰性一致	活跃PMC成员	3
移除提交者	当寻求移除提交权限时。注意：此类行动也将由PMC主席提交给ASF董事会。	一致同意	活跃PMC成员（如果相关提交者也是PMC成员，则不包括该提交者）。	6
移除PMC成员	当寻求移除PMC成员时。注意：此类行动也将由PMC主席提交给ASF董事会。	一致同意	活跃PMC成员（除相关成员外）。	6
修改章程	修改本文档。	三分之二多数	活跃PMC成员	6