| 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。）
已咨询。FEC 征求了其对 RFC 的反馈，但在决定接受或拒绝 RFC 时不会考虑其 +1 或 -1 的利益相关方。
共同化
添加以下文本：
在此阶段，RFC 作者应开始确定此 RFC 的利益相关方。
草稿
添加以下文本：
RFC 作者应与 RFC 领域的专家协商，提出一组初始利益相关方。利益相关方组最初可能为空或不完整。如有任何不明确之处，他们应咨询 FEC 以寻求帮助，确定利益相关方。
迭代
修改第二段：
在机制上，您应邀请利益相关方提供有关 RFC 的反馈，方法是将他们添加到 CL 中的“审核人”（对于需要 +1 的利益相关方）或“抄送”字段（对于“已咨询”的利益相关方），就像您进行正常代码审核一样。此外，您还可以向 eng-council-discuss@fuchsia.dev 发送电子邮件，征求更多反馈。利益相关方应通过在代码审核工具中对您的 RFC 发表评论来向您提供反馈。
添加以下文本：
任何人都可以通过评论 RFC CL 为给定的 RFC 提出额外的利益相关方（包括他们自己），但这些提案可能并不总是被接受。如果达成广泛共识，RFC 作者应添加利益相关方。FEC 也可能会要求作者添加利益相关方。
利益相关方可以“选择退出”并要求被移除，也可以委托他人进行审核（例如，委托给相关领域的另一位专家）。FEC 可能会要求移除利益相关方，或在“审核人”和“已咨询”之间移动利益相关方。
反馈可能包括非利益相关方的评论。作者应在相关情况下回复这些评论，但并不一定需要解决这些评论才能进入最后一次点单阶段。如果评论指出在谁是利益相关方方面存在分歧，FEC 可以帮助解决此问题。
最后一次点单
修改第二段：
通常，审核人会使用 +1 签名，而教员会使用 +2 签名。已咨询的利益相关方也可以使用 +1 签名，以表达他们对 RFC 的热情，但这并非必需。
元数据的更改
已咨询 - 批准或拒绝后必须填写。已咨询此 RFC 但不需要 +1 的利益相关方。
RFC 模板的更改
将以下可选部分添加到 RFC-0000：RFC 模板（在“设计初衷”之后， 在“设计”之前）：
利益相关方
谁会关心此 RFC 是否被接受？（此部分是可选的，但建议填写。）
教员：
FEC 指定的人员，负责引导此 RFC 完成 RFC 流程。
审核人：
列出 FEC 在决定是否接受或拒绝此 RFC 时会考虑其投票（+1 或 -1）的人员。在适用情况下，还应列出他们预计关注的领域，例如“FIDL”或“安全性”。 在某些情况下，此部分最初可能留空，并在第一轮共同化后完成利益相关方发现。一般来说，“审核人”应列在 Gerrit 的审核人行中，“已咨询”的人员应被抄送。应注意控制审核人的数量，使其易于管理，但具体数量将取决于相关 RFC 的范围。
已咨询：
列出应审核 RFC 但不需要其批准的人员。
共同化：
此部分可用于描述在进入 RFC 流程的“迭代”阶段之前，设计是如何共同化的。例如：“此 RFC 经过了组件框架团队的设计审核。”
缺点、替代方案和未知因素
此 RFC 为 RFC 作者引入了少量额外开销。