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