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