贡献者指南
这些是针对在 ansible 和 ansible-collections GitHub 组织中拥有提交权限的人员的指南。
《Ansible 核心》的贡献者必须是红帽员工，作为 Ansible 核心团队的成员。《Ansible 集合》的贡献者是社区成员或 Ansible 工程师。请在您提交之前阅读这些指南。
这些指南适用于所有人。同时，这不是一份流程文档。因此，请运用您的良好判断。您被授予提交权限是因为我们信任您的判断力。
也就是说，明智地运用这种信任。
如果您滥用信任，破坏组件和构建等，信任程度会下降，您可能会被要求不要提交，或者您可能会失去提交权限。
Ansible 核心功能、高级设计和路线图
作为核心团队成员，您是开发 路线图 的团队中不可或缺的一部分。请积极参与，并推动您想要看到的特性和修复。同时，请记住，红帽作为一家公司，将承诺在各种版本中提供某些特性、修复、API 等。红帽公司和 Ansible 团队必须按计划完成并发布这些更改。对用户、社区和客户的义务必须优先考虑。由于这些承诺，您想自己开发的特性可能无法进入某个版本，因为它会影响 Ansible 中的许多其他部分。
任何其他新的特性和高级设计更改都应通过提案流程 (待定) 进行，以确保社区和核心团队有机会审查该想法并批准它。核心团队对基于提案将新特性合并到 Ansible 核心 中负有全部责任。
Ansible 集合功能、高级设计和路线图
集合维护者定义集合本身的功能、高级设计和路线图，并负责根据与社区讨论的提案将新特性合并到 Ansible 集合 中。
我们在 GitHub 上的工作流程
作为贡献者，您可能已经知道这一点，但我们的工作流程构成了我们许多团队策略的基础。请确保您了解以下工作流程步骤。
将您想要进行一些工作的存储库分叉到您自己的个人存储库中。
在您需要提交的特定分支上工作。
创建一个拉取请求，将其返回到上游存储库，并标记您想让其进行审查的人员；将某人指定为您的拉取请求的主要“所有者”。
根据提供的评论调整代码。
请存储库贡献者中的某人进行最终审查并合并。
贡献者工作流程补充
核心团队意识到这有时可能是一个困难的过程。有时，团队会通过直接提交或合并他们自己的拉取请求来打破规则。本节是一组指南。如果您只是更改文档中的逗号，或进行非常小的更改，您可以运用您的最佳判断。这是另一项信任事宜。该流程对于任何重大更改都至关重要，但对于小事或快速完成某些事项，请运用您的最佳判断，并确保团队中的人员了解您的工作。
核心角色
通用规则
拥有直接提交权限的个人被赋予了允许他们执行各种操作的权力，这可能比我们能写下来的还要多。与其说是规则，不如说是通用 _指南_，拥有这种权力的个人应该运用他们的最佳判断。
不要
直接提交。
合并您自己的拉取请求。其他人应该有机会审查和批准拉取请求合并。如果您是核心贡献者，那么对于非常小的更改，您在这方面拥有少量自由裁量权。
忘记备用环境。考虑备用方案 - 是的，有些人拥有糟糕的环境，但他们是最需要我们帮助的人。
拖累您的社区团队成员。讨论您审查的任何拉取请求的技术优点。避免消极和人身攻击。有关如何成为一名良好社区成员的更多指导，请阅读我们的 社区行为准则。
忘记维护负担。维护成本很高的特性可能不值得添加。
破坏剧本。始终牢记向后兼容性。
忘记保持简单。复杂性会带来各种问题。
请
压缩，尽可能避免合并，使用 GitHub 的压缩提交或 cherry-pick（如果需要，二分查找会感谢您）。
积极参与。没有项目活动（通过合并、分类、提交等）的贡献者的权限将被暂停。
考虑向后兼容性（回到“不要破坏现有剧本”）。
编写 测试，并确保您正在审查的其他人拉取请求得到充分的覆盖。包含测试的拉取请求比没有测试但应该包含测试的拉取请求优先级更高。虽然并非所有更改都需要测试，但请确保为新特性、错误修复和功能更改添加测试。
与其他贡献者讨论，尤其是在您不确定某件事时。
记录！如果您的拉取请求是新特性或行为更改，请确保您已更新所有相关文档，或已通知合适的人员执行此操作。它还有助于添加与该文档兼容的
ansible-core或collection版本（避免稳定版和开发版文档之间出现混淆，以及向后兼容性等）。考虑范围，有时可以概括修复。
保持简单，这样事物就可以维护、调试和理解。
预计贡献者将继续遵循 Ansible 社区其他成员遵循的相同社区和贡献指南。