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