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