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