Ironic/CoreTeam
团队
ironic-core 团队负责评审所有提交到（'master' 分支）受 ironic 治理的仓库的变更。 这包括以下仓库（此列表并非详尽无遗）：
- openstack/ironic -- 构成 OpenStack Ironic 项目的主要服务
- openstack/python-ironicclient -- 我们的 Python 客户端库和 CLI
- openstack/ironic-python-agent -- 我们用于硬件带内配置的 ramdisk 代理
- bifrost -- 用于运行 Ironic 单独部署的 Ansible 剧本
- ironic-lib -- 其他 Ironic 项目使用的通用函数库
与 ironic-core 团队类似，ironic-stable-maint 团队负责评审提交到任何稳定（非 'master'）分支的仓库的所有变更。 对于稳定分支，有更严格的 评审指南。
ironic-python-agent-core 团队是领导以下项目评审工作的另一个团队。 该团队的成员可能也是也可能不是 ironic-core 的成员。
- openstack/ironic-python-agent
ironic-specs-core 团队负责评审设计规范。 并非所有 ironic-core 成员都有时间专门用于设计评审（而且有些人更愿意专注于代码）。 此外，一些操作员经常参与设计过程，但没有时间定期评审代码，因此他们不是 ironic-core 的成员。
- openstack/ironic-specs
ironic-inspector-core 团队负责以下项目
- openstack/ironic-inspector
bifrost-core 团队是领导以下项目评审工作的另一个团队。 该团队的成员可能也是也可能不是 ironic-core 的成员。
- openstack/bifrost
并非所有团队都在这里提及。 您可以在以下位置找到其他与 ironic 相关的团队（其中一些）：
请注意，即使您不是这些团队的成员，也鼓励大家帮助评审变更。 所有评审都非常有价值，并且会受到核心团队成员的重视。 参与评审过程是加入任何团队道路上最重要的任务。
添加或移除成员
上述每个评审组都应反映相应团队的积极参与。 ironic-core 和 ironic-specs-core 团队由项目 PTL 领导，而 ironic-python-agent-core 和 ironic-inspector-core 则分别委托给 JayF 和 dtantsur。
新增成员或移除现有成员应由现有核心团队定期讨论，任何变更都应与 openstack-dev 邮件列表发送电子邮件。 任何核心成员都可以随时发起此类讨论。 如果成员不再满足团队成员资格的期望，PTL 可以随时将其移除。 在添加或删除成员时，无需投票，但通常会征求现有团队的意见以更改团队结构。
请注意，公开讨论候选人的问题可能会对候选人产生负面影响。 被提名然后公开 -1'd 的影响充其量是不愉快的，最坏的情况是有害的。 因此，最好在公开投票之前，在现有的核心团队中进行初步的非正式讨论，以确保对候选人有足够的共识和合作意愿。
通常也会私下联系候选人，在任何公开讨论之前确认他们是否愿意接受该职位，尽管可以从项目的评审活动中推断出他们对项目的现有承诺，但这并非必要。
成员期望
核心评审团队的成员资格是一项重要的承诺，不应轻率对待。 维持此团队的成员资格需要花费大量时间。 此外，重要的是投入的时间是持续的。 核心团队成员的参与不一致会对团队和项目整体造成损害。
团队成员预计会定期（几乎每天）参与代码评审。 成员还应及时了解项目中发生的事情，主要是在 openstack-dev 邮件列表和 IRC 上。 请注意，IRC 使用非常频繁，因此成员应在#openstack-ironic尽可能多的时间里。 这些活动对于能够根据项目的当前状态提供高质量的评审至关重要，并且与团队其他成员的评审一致，并与记录的评审指南一致。
用于确定评审参与度的一个指标就是评审的数量。虽然对评审数量没有明确的期望，但成员通常预计与团队中大多数其他成员大致相同。您可以在这里找到统计数据
评审的数量当然不是唯一重要的因素。重要的是评审质量要高，以便您随着时间的推移赢得其他核心团队成员的尊重。这是通过定期提供高质量的建设性批评来实现的。您对变更的深思熟虑的建议是建立您对补丁的 +1 可信度的关键。
所有这些都很重要，但最重要的是获得核心团队大多数成员的信任。 没有明确定义的清单说明您必须做哪些事情才能获得这种信任，但此处描述的所有期望都是一个起点。
评审优先级
并非所有评审都是一样的。团队成员应注意优先处理他们投入评审的时间。通常，优先级应基于补丁关联的 bug 或蓝图的优先级。除此之外，较旧的评审应优先处理。请查看 ReviewWorkflowTips 页面，了解如何将优先级处理纳入您的工作流程。
其他说明
- -2 无法被任何其他核心成员覆盖，因此请谨慎使用。 这是一种表示“这太糟糕了，我将单方面否决它”的方式
- 避免“利益冲突的感知”
- 补丁不应仅由提出补丁的公司中的核心团队成员评审和批准（尤其对于大型功能而言）
- 不要批准自己的补丁
- 批准补丁需要至少两个 +2
- 有风险的补丁应该留出更长的时间，以便更多的核心成员有机会评审
- 除了可以仅用一个 +2 批准的琐碎补丁。 您可以使用常识来决定。 由于常识并不总是普遍存在，因此以下是一些可以使用常识的地方
- 解决评审反馈的修复
- 文档字符串和内联注释[1] 中的语法/澄清修复
- 全局需求（来自 OpenStack Proposal Bot）更新（取决于更改，但大多数可能都符合条件）
- 翻译补丁
- 对 'development' 配置文件（如 .gitignore）的更新
- 尝试每天评审至少 1 个补丁（平均而言）
- 并让团队知道如果您休假较长时间，以免他们想知道为什么您没有评审任何内容：)
[1] http://lists.openstack.org/pipermail/openstack-dev/2015-February/057794.html
