| RFC-0122：RFC 相关方 | |
|---|---|
| 状态 | 已接受 |
| 区域 |
|
| 说明 | 修改了有关确定和管理利益相关方的 RFC 流程 |
| Gerrit 更改 | |
| 作者 | |
| 审核人 | |
| 提交日期（年-月-日） | 2021-06-21 |
| 审核日期（年-月-日） | 2021-08-16 |
摘要
此 RFC 对 RFC 流程和 RFC 模板进行了修订，以更清晰地说明如何识别和管理 RFC 的利益相关方。它向 RFC 模板添加了“利益相关者”部分，并阐明了可能的利益相关者角色。
设计初衷
如今，Fuchsia 工程委员会 (FEC) 负责确保每个 RFC 都已由合适的利益相关方审核。这种责任集中化存在一些缺点。虽然这依赖于 FEC 委员会成员对 Fuchsia 组织的了解（一项预期资格），但它缺乏外部可见的制品，无法有机地记录这些知识，以便其他人了解 Fuchsia 项目的这一方面。
此外，在确定利益相关方方面也存在一些困惑，尤其是在区分审核者（其意见和投票在决策过程中具有阻碍性权重）和其他意见仅供参考的利益相关方时。例如，虽然在 Fuchsia 之上构建界面的任何人都有可能受到图形更改的影响，但图形负责人的意见会更重要。
通过将利益相关方识别纳入 RFC 流程，我们可以明确讨论谁必须批准 RFC，以及原因。这种明确的利益相关者识别有助于解决上述两个问题。
对 RFC 流程的这项更改旨在帮助 RFC 作者了解哪些反馈是建议性的，哪些反馈是阻碍性的，从而使流程更易于理解；此外，还提供了一种方法来确保我们为每个 RFC 安排了适当数量的审核者，并提供了有关如何选择审核者的明确准则。此项变更还让所有人都可以参与讨论利益相关者是谁以及他们各自的角色，从而进一步营造公平的竞争环境。
利益相关方
教员：abarth
审核人员：abarth（FEC 成员）、wittrock、pascallious（共同作者）。最近的几位 RFC 作者：bprosnitz、simonshields、aaronwood、dgilhooley。
咨询对象：FEC 成员。
社会化：此 RFC 的草稿已发送到 FEC 讨论邮件列表以征求意见。
设计
RFC 流程变更（按部分）
角色和职责
我们将相关负责人的角色和职责进一步细分为：
教员。由 FEC 指派的负责在 RFC 流程中引导此 RFC 的人员。现在，此人必须是 FEC 成员。
审核者。在 FEC 决定接受或拒绝 RFC 时，其 +1 或 -1 将被考虑的利益相关者。（虽然 +2 是代码 CL 的“批准”，但我们通常会要求审核者使用 +1 或 -1 来表明其支持或不支持，并要求促成者在批准后使用 +2。）
已咨询。征求了利益相关方对 RFC 的反馈，但在 FEC 决定接受或拒绝 RFC 时，不会考虑这些利益相关方的 +1 或 -1。
社交
添加以下文字：
在此阶段，RFC 作者应开始确定此 RFC 的利益相关者。
草稿
添加以下文字：
RFC 作者应咨询其 RFC 领域的专家，提出一组初始利益相关者。利益相关者集最初可能为空或不完整。如有任何疑问，他们应咨询 FEC 以寻求有关确定利益相关者的帮助。
迭代
修改第二段：
在机制上，您应像进行常规代码审核一样，将利益相关方添加到 CL 的“审核者”（对于需要 +1 的利益相关方）或“抄送”（对于“咨询”利益相关方）字段中，邀请他们就您的 RFC 提供反馈。此外，您还可以通过电子邮件将 CL 发送给 eng-council-discuss@fuchsia.dev，征求更多反馈。利益相关者应在代码审核工具中通过在 RFC 上留下评论来向您提供反馈。
添加以下文字：
任何人都可以通过在 RFC CL 上添加评论来为给定的 RFC 提议添加其他利益相关者（包括自己），但这些提议不一定会被接受。如果达成广泛共识，RFC 作者应添加利益相关者。FEC 还可能会要求作者添加利益相关方。
利益相关者可以“选择不参与”，要求移除自己的姓名，也可以委托他人（例如相关领域的另一位专家）进行审核。FEC 可能会要求移除利益相关者，或将利益相关者从“审核者”移至“咨询对象”。
反馈可能包括非利益相关者的评论。作者应在相关情况下回复这些评论，但不必解决这些评论才能进入最后一次通话阶段。如果评论表明存在关于谁是利益相关者的意见分歧，FEC 可以帮助解决此问题。
最后一次点单
修改第二段：
通常，审核者会使用 +1 签名，而促成者会使用 +2 签名。受咨询的利益相关者也可以通过 +1 来表达他们对 RFC 的热情，但这并非必需。
元数据变更
对创建 RFC 的补充：
已咨询 - 批准或拒绝后必须提供。就此 RFC 咨询过的利益相关者，但不需要其 +1。
对 RFC 模板的更改
将以下可选部分添加到 RFC-0000：RFC 模板（在“动机”之后、“设计”之前）：
利益相关方
哪些人会受到此 RFC 是否被接受的影响？（此部分为可选，但建议填写。）
辅导员：
由 FEC 指派负责引导此 RFC 完成 RFC 流程的人员。
审核者：
列出在 FEC 决定是否接受或拒绝此 RFC 时，其投票（+1 或 -1）将被考虑的人员。如果适用，还应列出他们预计会重点关注的领域，例如“FIDL”或“安全性”。在某些情况下，此部分最初可能留空，并在完成第一轮社交化后完成利益相关者发现。一般来说，“审核者”应列在 Gerrit 的审核者行中，而“咨询对象”应抄送给对方。应注意使审核者的数量保持在可管理的范围内，不过具体数量将取决于相关 RFC 的范围。
已咨询：
列出应审核 RFC 但无需批准的人员。
共同化：
此部分可用于说明在进入 RFC 流程的“迭代”阶段之前，设计是如何进行社会化的。例如：“此 RFC 已通过组件框架团队的设计审核。”
缺点、替代方案和未知因素
此 RFC 会给 RFC 作者带来少量额外开销。