Apache Maven 项目角色
Apache Maven 项目不仅仅是它产生的软件。Apache 基金会有一句话：“社区胜于代码”，它是关于社区如何围绕一个项目发展的，这是最重要的事情。
阅读本文的每个人都是 Apache Maven 社区的一部分，即使您是 Apache Maven 社区的隐形成员，您仍然是社区的一部分。
我们可以通过多种方式对社区中的人进行分类，我们将以下内容作为其中一种方式。如果您不同意此分类，请不要生气。重要的是要记住，我们是一个社区而不是一个集团，因此您有权不同意社区中的其他人。
注意：不同意他人意见的权利伴随着不故意引起冒犯或不和的责任。
非正式角色
潜伏者
根本不使用 Maven，但对项目感兴趣的人。这可能包括正在开发与 Apache Maven 竞争的软件工具的人。
如果潜伏者能够从阴影中走出来并让自己可见，那就太好了，但是每个社区都需要它的潜伏者，所以如果你是一个在 Apache Maven 项目的边缘生闷气的潜伏者，请知道你是一个有价值的成员我们的社区。如果你觉得需要改变你的角色，我们会张开双臂欢迎你……（如果我们不张开双臂欢迎你，请告知 负责确保社区健康的项目管理委员会)
消费者
使用 Maven 但不积极加入社区的人。这不包括以下人员： 订阅了 Maven 邮件列表之一；活跃于 Maven 用户社区（例如stackoverflow；提交错误报告等）。
也许 Apache Maven 对您来说是完美的产品，并且完全符合您的需要和想要的，而且您永远不需要询问有关如何使用 Maven 的问题，因为对您来说应该如何使用 Maven 很明显……如果那是在这种情况下，您能否考虑在我们的社区中扮演更积极的角色，因为 Maven 在我们看来不是上述情况，您可能有我们错过的观点。
如果您确实对 Maven 有疑问（我们都有问题，所以 Maven 有问题并没有错），请告诉我们：
- 提交错误报告是让我们了解错误的最佳方式，
- 在用户邮件列表中提问是获得问题答案的最佳方式。
作为最后的手段，其他 Maven 用户社区是更多参与 Maven 社区的另一条途径，但请记住，Apache 基金会项目应该在 ASF 鼓励社区，因此如果您直接与 ASF 托管社区互动。
用户
使用 Maven 并加入社区的人。这包括有以下情况的人：
- 提交了错误报告，
- 问了一个关于Maven 用户列表的问题，
- 加入了其他 Maven 用户社区之一。
我们希望您的错误报告已引起注意。如果还没有，您为什么不看看您是否可以自己解决问题并提交补丁？
我们希望您的问题得到解答。如果还没有，想想其他所有问题都没有得到解答的用户，你知道其中有多少人的答案（即使只是部分答案）？你为什么不用你知道的答案来回答他们的问题呢？如果每个人都这样做，你的问题就会有答案。提前付款！
我们希望您在其他 Maven 用户社区之一的体验是积极的，那么为什么不加入规范的 Maven 用户社区并订阅Maven 用户列表呢？
贡献者
使用 Maven 的人已经加入了 Maven 社区并回馈社区。这包括以下人员：
- 提交 Maven 和 Maven 插件建议版本的测试结果报告，
- 回答关于Maven 用户列表（甚至是其他 Maven 用户社区）的问题，
- 提交补丁以解决 Apache 托管的 Maven 或 Maven 插件中报告的错误，
- 通过识别重复报告或相关问题来帮助整理错误报告。
我们为贡献者编写了指南。
继续贡献，您是我们社区的重要成员。如果我们喜欢我们所看到的，我们甚至可能会要求您考虑在我们的项目中担任正式角色。
正式角色
提交者
这些人被授予对 Apache Maven 代码存储库的写入权限，并 在 ASF 存档了已签署的贡献者许可协议 (CLA) 。
Apache Maven 项目使用 Commit then Review 策略，并有 许多应遵循的约定。
提交者负责确保他们提交的每个文件都包含在有效的 CLA 中。
想要成为 PMC 成员的提交者应设法证明 PMC 成员部分中列出的职责，以便 PMC 成员更容易决定提交者是否已准备好承担责任。
退休提交人
如果提交者决定他们目前不能继续履行提交者的职责，他们可以选择退休。
在任何时候，Apache Maven 项目的退休提交者都可以通过通知项目管理委员会来决定他们想再次成为活跃的提交者。当前的政策是提交者角色的恢复是自动的。
项目管理委员会
项目管理委员会作为一个整体是控制项目的实体。项目管理委员会的成员由 Apache 软件基金会董事会根据项目管理委员会的提名决定。
Apache Maven 项目的悠久传统是项目管理委员会大约每 6 个月审查一次活跃的提交者，以确定这些提交者中的任何一个是否适合推荐给董事会以纳入 PMC。需要注意的是，这只是一种传统，而不是一种权利。PMC 角色伴随着重大责任，因此，如果一个人没有表现出这些责任，他们可能不会被提名，或者他们的提名可能会被董事会拒绝。这样的决定并不反映该人的技术能力，实际上该人自己甚至可能决定拒绝提名。因此，此类定期审查的结果是保密的。
项目管理委员会具有以下职责：
- 积极管理 Apache 基金会董事会决议确定的项目；
- 确保该项目仍然是 Apache 基金会的健康顶级项目（如果 PMC 成员希望将项目托管在其他地方，他们应该从 PMC 辞职，说明他们的原因 - 如果 PMC 缩小到超出最小可行规模，那么由于PMC 的大部分成员希望将项目转移到其他地方，Apache 基金会董事会将在将项目转移到基金会阁楼时考虑到这一点）
- 根据 Apache 基金会董事会的要求准备报告，并确保这些报告可以及时提交给 PMC 主席；
- 捍卫属于该项目的商标；
- 提议积极的贡献者进行提交；
- 确保社区中的投票被用作建立共识的工具，而不是剥夺或疏远社区少数群体的武器；
- 在项目决策中具有约束力的投票；
- 确保提交给项目的代码是在有效的 CLA 下提交的，或者是在提交时明确表明应用了 Apache 许可证的代码（即，提交给问题跟踪器或邮件列表的小补丁被假定与除非提交者明确将这些补丁标记为未涵盖，否则意图被 Apache 许可证涵盖）
- 确保作为项目发布的一部分提供的第三方依赖项包含在兼容的许可证中。
- 对发布工件进行投票；
- 确保遵循开发者约定，或在必要时更新/改进；
- 了解并尊重社区的目标和流程，并帮助教育新成员了解这些目标和流程。
社区承诺标准
本着支持我们社区健康的精神，项目管理委员会成员避免采取破坏委员会本身运作的行动。
其他项目的推广
Apache 基金会目前没有要求项目交叉推广的政策。例如，Subversion 是一个 Apache 项目，但项目可以从 Subversion 和 Git（非 Apache 项目）中自由选择以进行源代码控制。
在考虑在 Maven 中集成技术时，因此不需要选择其他 Apache 项目而不是非 Apache 项目。
因此，选择与 Maven 集成的技术的主要要求是：
如果 PMC 成员提倡特定技术，他们应该声明他们对该技术或竞争技术的任何兴趣/参与 - 无论该项目是 Apache 项目还是在其他地方托管的项目。
有明确兴趣/参与的 PMC 成员应尽量避免对相关技术选择进行任何方向的有约束力的投票。
项目代码库的分支
社区发布的所有代码都应该有足够的机会进行审查：
- 由PMC，检查董事会授予的法律责任；和
- 由提交者（包括 PMC）检查技术方向和质量是否符合共识路线图（已就此类路线图达成一致）。
不言而喻，如果代码尽早提交到项目的源代码控制中，审查的机会就会大得多。同样，小提交比大提交更容易审查。
在 Apache 基金会之外维护 Maven 代码库的分支本身并没有错。个别开发人员可以有自己的工作风格，并且可能更喜欢分叉工作，这样他们就可以丢弃可见度较低的失败实验（尽管可以说这种失败实验的可见性对于其他人来说可能是有价值的文档）。一旦确定了该分支中的更改（由维护分支的人员），应将这些更改带回项目，这些更改应至少引入到托管在 Apache Maven 源代码控制上的分支中，以便于通过社区。PMC 应该鼓励将此类更改从一个分支（他们参与维护）尽早提交回 Apache Maven 源代码控制。
同样，如果为了从其他有才华的人那里获得贡献而在其他地方托管分叉，则 PMC 成员应努力将这些人和他们的才能作为提交者带到项目中。
最后，在 Apache 硬件之外托管分叉的情况下，代码来源的可追溯性较少，例如 Git 提交可以被压缩并重写历史以掩盖或隐藏贡献的来源。这并不意味着来自外部分支的代码固有地存在此类问题，而是意味着在处理源自 Apache 基金会源代码控制之外的长期运行分支的大量更改时，审查和验证出处的需求呈指数级增长.
项目管理主席
由于各种法律原因，Apache 软件基金会只能将某些事情委托给基金会的一名官员。
项目管理委员会负责提名幸运的受害者成为基金会的官员（须经董事会批准）。
然后这个人成为董事会和项目管理委员会之间的接口。他们在项目中没有任何其他额外的重要性，项目管理委员会作为一个整体负责项目的方向。
如果事情破裂并且没有达成共识并且没有明确的能力得出任何结论并且这符合基金会的利益，因为已经造成损害并且董事会希望主席充当基金会的官员并清理事情，那么主席可以作为最终决策者，但是，此时基金会董事会必须已经充分了解情况，并应积极监督主席。