核心审查员¶
一般职责¶
OpenStack-Ansible 核心审查员团队 负责 OpenStack-Ansible 项目的许多方面。这些包括但不限于
指导社区贡献者进行解决方案设计、测试和审查流程
积极审查补丁提交，考虑补丁是否：- 具有功能性 - 符合项目的用例和愿景 - 在测试、文档和发行说明方面是否完整 - 考虑到从先前版本升级的问题
协助错误分类和交付错误修复
维护 gate 并分类失败
维护准确、完整和相关的文档
确保测试级别充分，并在添加功能时保持相关性
回答问题并参与邮件列表讨论
与其他 OpenStack 团队进行沟通
本质上，核心审查员共享以下共同理念
他们对项目在其 使命 中的成功负有责任。
他们重视健康、充满活力和活跃的开发者和用户社区。
他们为了改进项目做出了长期、持续的时间投入。
他们将时间花在确保项目成功所需的事情上，不一定是那些最有趣或最有趣的事情。
核心审查员的责任不限于合并代码。
核心审查员期望¶
核心审查员团队的成员预计会
参加并参与每周 IRC 会议
监控并参与 #openstack-ansible 频道中的讨论
监控并参与 OpenStack-Ansible 邮件列表中的讨论
参与 OpenStack 项目团队聚会 (PTG) 中的团队会议
参与 OpenStack 首脑会议中的论坛会议
积极且持续地审查补丁提交
请注意，参加 PTG、首脑会议、中期周期和其他代码冲刺的亲自参加不是成为核心审查员的要求。团队将尽最大努力促进在所有活动中的虚拟参加。旅行不应被轻视，我们意识到参加这些活动的人员所涉及的成本。
代码合并职责¶
虽然鼓励每个人审查更改，但核心审查员团队的成员有能力在 Code-Review (CR) 标签上设置 +2/-2，以及在这些存储库的 Workflow (+W) 更改上设置 +1。这是一种额外的责任，不容轻视。正确合并代码不仅需要理解代码本身，还需要理解代码如何影响文档、测试、升级影响以及与其他项目之间的交互。这也意味着您关注发布里程碑，并了解您正在合并的补丁是否标记为发布，尤其是在功能冻结期间。
代码合并策略¶
以下您将找到有关 Code-Review 流程的一般策略，以及何时可以认为补丁已准备好合并以及何时设置 +W。
负责审查更改的 Core Reviewer 的责任是在更改通过策略后设置 +W 标签。此外，在设置 +W 之前，请确保所有依赖补丁（在提交消息中标记为 Depends-On）已合并，以避免不必要的重新检查或依赖补丁在 gate 中失败的情况。
所有更改可以分为多个类别，并且可能对每个类别应用略有不同的策略。
新功能、蓝图、设计更改¶
至少 2 名核心审查员（不包括补丁所有者）对 Code-Review 标签投票 +2
投票的 Code-Reviewer 应代表至少 2 个不同的组织或无隶属关系，以实现多样性
错误修复、版本更新¶
至少 2 名核心审查员（不包括补丁所有者）对 Code-Review 标签投票 +2
允许所有投票的 Core Reviewer 与同一组织相关联
自动化 (bot) 更改¶
至少 1 名核心审查员（不包括补丁所有者）对 Code-Review 标签投票 +2
回溯到稳定分支¶
至少 2 名核心审查员，包括补丁所有者，对 Code-Review 标签投票 +2。
允许所有投票的 Core Reviewer 与同一组织相关联
回溯到未维护的分支¶
至少 1 名核心审查员（不包括补丁所有者）对 Code-Review 标签投票 +2
