每个项目管理委员会 (PMC) 对其软件产品的版本发布进行投票，并选举新的 PMC 成员和提交者加入其 Apache 项目。
PMC 是 ASF 中最重要的组织。它们是实际决定项目发布哪些软件并完成 ASF 大部分实际工作的团队。
本文档是关于 ASF 中组织如何以及为何以其方式运作的背景信息。有关官方政策信息和“操作指南”样式指南，请参阅“参考文献”下的文档或 /dev。
内容
选入特定 Apache 项目 PMC 的提交者代表 ASF 对该项目进行监督，决定项目的发布策略。PMC 成员应以个人身份行事，在 PMC 或开发人员列表上采取行动时，应为项目的最佳利益做出决策。
每个项目的 PMC 都是独立的。PMC 可以自由设定其项目的社区和技术方向，并直接负责监督版本发布和社区的健康发展。PMC 负责确保其项目遵循董事会或 ASF 其他公司管理人员设定的某些核心要求，例如遵循法律、品牌和基础设施相关要求，并确保其社区在 Apache 之道的基本框架内运作。
PMC 成员提名项目的新贡献者为提交者或 PMC 成员，并投票决定是否选举新的提交者或 PMC 成员。PMC 成员对任何项目事宜均有约束力投票权。
PMC 必须至少有三个 (3) 名活跃成员。这是因为产品发布所需的最低积极 (+1) 票数为 三个。
董事会通过每月会议上的决议创建 管理特定命名项目的 PMC。新的顶级项目 (TLP) 通常是在 Apache 孵化器中的 Podling 成功毕业投票后创建的。董事会任命副总裁（公司的一名管理人员）担任项目 PMC 的主席。
PMC 主席担任普通 PMC 成员，对项目事宜只有一票，就像其他 PMC 成员一样。PMC 主席的主要职责是向董事会提供有关其项目健康状况和状态的季度报告。预计 PMC 主席将订阅 board@ 邮件列表，并了解董事会对该项目的任何疑虑，并负责与整个 PMC 合作解决董事会的任何疑虑。
PMC 主席还负责在任何新成员添加到 PMC 时更新官方 PMC 名单。请参阅 如何添加新的 PMC 成员。不再参与项目的 PMC 成员也可以 请求辞去 PMC 职务。
更改 **PMC 主席/副总裁** 需要董事会决议在每月会议上获得批准，因为这涉及任命 ASF 的管理人员。请遵循 PMC 主席变更流程。
作为 ASF 的正式委员会，PMC 提供项目运营和发布的法律监督，确保软件发布作为 ASF 作为一个组织的行为进行，而不是个人开发人员的行为。这确保了 ASF 作为一个组织，而不是个人提交者，承担 Apache 项目产品产生的任何法律责任。所有 PMC 主席都提供 季度报告给董事会，确保董事会对所有 ASF 项目进行监督。
所有 PMC 成员都应订阅其项目的 private@ 列表，并且肯定应该至少订阅 dev@ 列表以了解项目的运作。
几乎所有 PMC 通信都应在 dev@ 列表或任何其他适当的公共邮件列表上进行。每个 PMC 的 private@ 列表用于需要保密的事项，例如讨论人事事宜、是否邀请新的提交者或 PMC 成员，或尚未公开披露的安全相关问题。确保 PMC 关于项目未来的讨论在公共 dev@ 列表上进行，确保所有社区，包括非提交者，都可以关注讨论并对问题发表评论。虽然只有 PMC 成员或提交者对项目事宜有约束力投票权，但健康的 PMC 会积极与项目的更大社区合作。
PMC 可以自由使用 JIRA/Bugzilla、维基和其他基础设施托管的工具，这些工具提供公共查看和评论功能，以及正常的项目邮件列表。PMC 应向基础设施团队提出项目所需服务的具体请求。
一些 PMC 赞助面对面会议、电话会议或 IRC 聊天以集思广益项目想法，但必须将所有信息带回其项目的公共列表以供进一步讨论并做出最终决定。许多 PMC 要么直接组织，要么让其技术领域的贡献者或组织组织聚会、BarCamp 或其他以最终用户教育和共享技术信息为重点的面对面活动。
鉴于我们项目的分布式和志愿者性质，PMC 的面对面会议非常少见。所有项目业务都在项目的普通公共邮件列表上进行。
PMC 可以自由设定其项目中的绩效标准，只要决策以 Apache 之道的方式协作进行。健康的 PMC 定期审查非提交者的贡献（具体代码补丁、报告或评论的错误，或只是在其项目列表上的有益互动）以评估贡献者作为潜在提交者的资格。确保 PMC 成员指导其项目中有帮助的新贡献者可以增强项目社区。
PMC 在他们期望贡献者成为提交者或 PMC 成员的承诺和工作水平方面差异很大。一些 PMC 从其现有的提交者中投票选举新的 PMC 成员（即，流程为贡献者 -> 投票 -> 提交者 -> 投票 -> PMC），而其他 PMC 始终同时将新当选的提交者选举为 PMC 成员（贡献者 -> 投票 -> 提交者和 PMC 成员）。PMC 独自负责管理投票和授予新提交者的提交权限；但是，董事会在新当选的 PMC 成员正式成为 PMC 的一部分之前必须认可他们（如上文“法律”部分所述）。
一个 PMC 中的绩效不可转移到其他 PMC；每个项目的 PMC 独立管理该项目的提交者列表。在某个项目上有悠久历史的 PMC 成员或提交者通常会因其他项目的 PMC 成员了解其过去活动而闻名，但他们需要在他们希望成为提交者的每个单独项目中建立绩效。许多 PMC 与其他 PMC 紧密合作，并且人员方面有相应的大量重叠；但每个 PMC 的绩效都是独立的。
虽然“提交者”一词的字面意思是“可以在源代码库中创建新版本的人”，但提交者的概念是一个社会概念：如果 PMC 邀请某人成为提交者，并且他们接受了邀请，那么这个人就是提交者。
虽然只有 PMC 成员对项目发布有约束力投票权，但总的来说，PMC 成员在 dev@ 列表上与项目的提交者和贡献者平等参与。PMC 成员可以通过确保项目的邮件列表对新手友好，以及成员在邮件列表上推广和遵循社区标准，来帮助发展一个健康和多元的项目社区。
虽然许多项目具有重叠的社区，因此也有一些共享的个人或技术关系，但从根本上讲，每个项目在项目工作的大部分方面都是其自己的社区。虽然所有项目都是整体 ASF 的一部分，并且共享某些基本要求和 Apache 之道的一部分，但所有技术方向和大多数社区重点都在每个单独的项目中。
PMC 向董事会报告其项目社区的健康状况和多样性。虽然 PMC 成员的构成（就 PMC 上个人的就业或隶属关系而言）没有严格的要求，但董事会确实期望 PMC 独立于外部商业影响运作。董事会将联系那些无法或不愿确保其行动代表整个社区或以旨在使特定商业利益受益的方式行事，并将要求他们进行纠正。
董事会不为其任何项目或活动提供技术指导。PMC 是其项目的管理机构，并期望他们独立于外部商业影响，为整个项目社区的最佳利益管理项目的技术。
虽然这可能会让一些人感到意外，但它反映了 ASF 的有意结构，以确保其项目拥有最大的自由。董事会和 ASF 很乐意为任何愿意遵循 Apache 之道的软件项目社区提供一个家园。ASF 的使命是提供软件以造福大众。我们很乐意帮助志同道合的社区提供这些软件，相信社区将围绕有用的软件形成，并理解有很多不同的方法可以有效且协作地构建软件。