回溯移植和 Ansible 包含

每个集合社区都可以设置自己的规则和工作流程来管理 Pull Request、错误报告、文档问题和功能请求，以及添加和替换维护者。维护者遵循以下规则审查和合并 Pull Request：

集合维护者

集合范围的维护者是指在集合中拥有 write 或更高访问级别的贡献者。他们拥有提交权限，并且可以合并 Pull Request 以及其他权限。

当集合维护者认为对文件的贡献足够重要时（例如，修复复杂的错误、添加功能、提供定期审查等等），他们可以邀请作者成为模块维护者。

模块维护者

模块范围的维护者存在于具有 collection bot 的集合中，例如，community.general 和 community.network。

成为模块维护者是成为集合维护者之前的阶段。模块维护者是在 .github/BOTMETA.yml 中列出的贡献者。范围可以是任何文件（例如，模块或插件）、目录或存储库。因为在大多数情况下，范围是模块或一组模块，所以我们将这些贡献者称为模块维护者。当创建与他们维护的文件相关的问题/Pull Request 时，collection bot 会通知模块维护者。

模块维护者通过 collection bot 实现间接提交权限。当两个模块维护者在更改他们维护的模块的 Pull Request 上评论关键字 shipit、LGTM 或 +1 时，collection bot 会自动合并 Pull Request。

有关 collection bot 及其接口的更多信息，请参阅 Collection bot 概述。

发布集合

集合维护者负责发布集合的新版本。通常，发布集合包括

规划和公告。
生成更改日志。
创建发布 Git 标签并推送它。
通过 Zuul 仪表板在 Ansible Galaxy 上自动发布发布 tarball。
最终公告。
（可选）提交将新集合包含到 Ansible 包中的请求。

有关详细信息，请参阅发布集合。

回溯移植

集合维护者根据集合的语义版本控制和发布策略，将合并的 Pull Request 回溯移植到稳定分支。

手动回溯移植过程类似于 ansible-core 回溯移植指南。

为了方便起见，可以使用 GitHub 机器人自动实现回溯移植（例如，使用 Patchback 应用程序）和标记，就像在 community.general 和 community.network 中所做的那样。

在 Ansible 中包含集合

如果集合未包含在 Ansible 中（未与 Ansible 包一起发布），维护者可以通过在 ansible-collections/ansible-inclusion 存储库下创建讨论来提交集合以供包含。有关更多信息，请参阅存储库的 README，以及 Ansible 社区软件包集合要求。

辞去集合维护者职务

时代在变化，您继续担任集合维护者的能力也可能会发生变化。我们要求您不要默默地辞职。

如果您觉得没有时间再维护您的集合，您应该

通知其他维护者。
如果集合位于 ansible-collections 组织下，还应通知相关的实时聊天、IRC 或 Matrix 上的 community 聊天频道，或通过电子邮件 [email protected] 通知。
查看集合中的活跃贡献者，以在其中找到新的维护者。与其他维护者或社区团队讨论潜在的候选人。
如果您未能找到替代人选，请在集合中创建一个置顶问题，宣布该集合需要新的维护者。
通过 Bullhorn 新闻通讯发布相同的公告。
请在场讨论其他维护者或社区团队找到的潜在候选人。

请记住，这是一个社区，因此您将来可以随时回来。