项目章程
Apache Ant™ 项目章程
本文档定义了 Apache Ant 项目运作的章程。它定义了项目的角色和职责、谁可以投票、投票如何进行、冲突如何解决等。
Ant 是Apache 软件基金会 的一个项目 。该基金会拥有 Apache 代码的版权，包括 Ant 代码库中的代码。基金会 常见问题解答 解释了基金会的运作和背景。
Ant 是典型的 Apache 项目，因为它按照一组原则运行，统称为“Apache Way”。如果您是 Apache 开发新手，请参阅 Incubator 项目 以获取有关 Apache 项目如何运作的更多信息。注意：孵化器项目最近才成立，尚未详细解释 Apache Way。
角色和责任
Apache 项目定义了一组具有相关权利和责任的角色。这些角色控制个人可以在项目中执行哪些任务。角色在以下部分中定义
用户
该项目最重要的参与者是使用我们软件的人。我们的大多数开发人员都是从用户开始的，并从用户的角度指导他们的开发工作。
用户通过以错误报告和功能建议的形式向开发人员提供反馈来为 Apache 项目做出贡献。此外，用户还通过在邮件列表和用户支持论坛上帮助其他用户来参与 Apache 社区。
开发商
所有为 Ant 项目贡献时间、代码、文档或资源的志愿者。为项目做出持续、受欢迎的贡献的开发人员可能会被邀请成为提交者，尽管此类邀请的确切时间取决于许多因素。
提交者
项目的Committer负责项目的技术管理。所有提交者都对项目的源存储库具有写入权限。提交者可以对有关该项目的任何技术讨论进行具有约束力的投票。
提交者访问只能通过邀请进行，并且必须得到活跃 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 项目中，不同类型的决策需要不同形式的批准。例如， 上一节描述了几个需要“惰性共识”批准的决策。本节定义了投票的执行方式、批准类型以及哪些类型的决策需要哪种类型的批准。
表决
有关该项目的决定是通过主要项目开发邮件列表 (dev@ant.apache.org) 上的投票做出的。如有必要，PMC 投票可以在 Ant PMC 私人邮件列表上进行。投票由以 [VOTE] 或 [PMC-VOTE] 开头的主题行清楚地指示。投票可能包含多个需要批准的项目，这些项目应该明确分开。投票是通过回复投票邮件进行的。投票可能有四种风格
| +1 | “是”、“同意”或“应该执行该操作”。总的来说，这次投票也表明了选民“让它发生”的意愿 |
| +0 | 这次投票表明愿意继续考虑采取行动。然而，选民将无能为力。 |
| -0 | 这次投票表明投票者总体上不同意拟议的行动，但也没有足够的担心来阻止行动的继续进行。 |
| -1 | 这是投反对票。在需要达成共识的问题上，这一票算作否决。所有否决必须包含对否决为何适当的解释。没有解释的否决无效。-1 票包含替代行动方案也可能是适当的。 |
鼓励 Ant项目的所有参与者通过投票来表达对特定行动的同意或反对。对于技术决策，只有活跃提交者的投票才具有约束力。对于那些拥有约束力投票的人来说，非约束性投票仍然有用，可以了解更广泛的 Ant社区对某项行动的看法。对于 PMC 的决定，只有 PMC 成员的投票才具有约束力。
投票还可以应用于对 Ant 代码库所做的更改。这些通常采用否决 (-1) 的形式来回复提交时发送的提交消息。
批准
这些是可以寻求的批准类型。不同的行动需要不同类型的批准
| 共识 | 为此，所有拥有约束力选票的选民都必须投票，并且不能有约束力否决权 (-1)。由于让所有合格选民投票是不切实际的，因此很少需要共识投票。 |
| 懒惰共识 | 惰性共识需要 3 个具有约束力的 +1 票，并且没有具有约束力的否决权。 |
| 懒惰的大多数 | 惰性多数投票需要 3 个具有约束力的 +1 票以及更多具有约束力的 +1 票（-1 票）。 |
| 懒惰批准 | 除非收到 -1 票，否则隐式允许采用惰性批准的操作，此时，根据操作类型，必须获得惰性多数或惰性共识批准。 |
| 2/3 多数 | 有些行动需要 2/3 的活跃提交者或 PMC 成员才能通过。此类操作通常会影响项目的基础（例如采用新的代码库来替换现有产品）。较高的门槛旨在确保此类变更得到强有力的支持。要通过此投票，需要至少 2/3 具有约束力的投票持有者投票 +1 |
否决权
有效的、有约束力的否决权不能被否决。如果否决，必须附有解释否决理由的正当理由。否决权的有效性如果受到质疑，可以由拥有具有约束力的投票的任何人确认。这并不一定意味着同意否决权——仅仅意味着否决权是有效的。
如果您不同意有效的否决，您必须游说否决者撤回否决。如果不撤回否决，必须及时撤销被否决的行动。
行动
本节描述了项目内采取的各种行动、该行动所需的相应批准以及对该行动具有约束力的投票者。
| 行动 | 描述 | 赞同 | 具有约束力的选票 |
|---|---|---|---|
| 代码变更 | 对项目代码库进行的更改并由提交者提交。这包括源代码、文档、网站内容等。 | 懒惰的批准，然后懒惰的共识。 | 活跃的提交者。 |
| 发布计划 | 定义发布的时间表和操作。该计划还任命了一名发布经理。 | 懒惰多数 | 活跃的提交者 |
| 产品发布 | 当项目产品之一的版本准备就绪时，需要进行投票才能接受该版本作为项目的正式版本。 | 懒惰的大多数 | 活跃 PMC 成员 |
| 采用新代码库 |
当现有的已发布产品的代码库要替换为替代代码库时。如果这样的投票未能获得批准，现有的代码库将继续下去。 这还包括在项目内创建新的子项目 |
2/3 多数 | 活跃的提交者 |
| 新提交者 | 当为项目提议新的提交者时 | 惰性共识 | 活跃 PMC 成员 |
| 新PMC成员 | 当向 PMC 提议提交者时 | 惰性共识 | 活跃 PMC 成员 |
| 提交者移除 |
当寻求删除提交权限时。 注意：此类行动也将由 PMC 主席提交给 ASF 董事会 |
共识 | 活跃的 PMC 成员（如果是 PMC 成员，则不包括相关提交者）。 |
| PMC 成员移除 |
当寻求罢免 PMC 成员时。 注意：此类行动也将由 PMC 主席提交给 ASF 董事会 |
共识 | 活跃的 PMC 成员（不包括该成员）。 |
投票时间
投票开放时间为 1 周，以便所有活跃选民有时间考虑投票。与代码更改相关的投票不受严格的时间表限制，但应尽可能及时进行。