| 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，以协助确定利益相关方。
迭代
修改第二个段落：
当然，您应该邀请利益相关方提供有关您的 RFC 的反馈，方法是将其添加到 CL 中的“Reviewers”（对于需要 +1 的利益相关方）或“CC”字段（对于“咨询的”利益相关方），就像对普通代码审核所做的一样。此外，您还可以通过电子邮件将您的 CL 发送至 eng-council-think@fuchsia.dev，以征求其他反馈。利益相关方应通过在代码审核工具中对您的 RFC 发表评论来向您提供反馈。
添加以下文本：
任何人都可以通过评论 RFC CL 为给定 RFC 提出其他利益相关方（包括他们自己），但这些方案有时不会被接受。如果存在广泛协议，则 RFC 作者应添加利益相关方。FEC 可能还会要求作者添加利益相关方。
利益相关方可能会选择拒绝并要求将其移除，也可能会将审核委托给相关领域的其他专家。FEC 可以要求移除某个利益相关方，或者在“审核者”下移交“咨询者”。
反馈可能包含非利益相关方的评论。作者应根据需要回复这些评论，但不必解决这些评论就进入最后一个调用阶段了。如果评论指向谁是利益相关方，FEC 可以帮助解决此问题。
上次通话
修改第二个段落：
通常情况下，评估人员会签字为“+1”，教员签字时为“+2”。已咨询的利益相关方如果希望表达自己对 RFC 的热情，也可以用 +1 来签字（并非必须这样做）。
对元数据的更改
对创建 RFC 的补充：
已咨询 - 批准或拒绝后需要。已就此 RFC 咨询了相关负责人，但无需对其执行 +1 操作。
对 RFC 模板的更改
将以下可选部分添加到 RFC-0000: RFC 模板中（在“Motivation”之后、“Design”之前）：
利益相关方
谁与此 RFC 被接受是否相关？（本部分为可选内容，但建议阅读。）
教员：
FEC 指定的人员，通过 RFC 流程照管此 RFC。
审核者：
列出用户在决定是否接受此 RFC 时，FEC 会将他们的投票（+1 或 -1）纳入考虑范围。在适用的情况下，还应列出开发者应关注的领域，例如“FIDL”或“安全”。在某些情况下，此部分最初可能会留空，并在初始一轮社交后完成利益相关方发现。一般来说，“审核人员”应列在 Gerrit 中的“Reviewer”（评价者）行中，“咨询”人员应抄送。应注意确保审核人员的数量在可管理范围内，但具体数量取决于相关 RFC 的范围。
咨询人员：
列出应审核 RFC，但无需审批的人员。
社交：
本部分可用于说明在进入 RFC 流程的“迭代”阶段之前，设计是如何社交化的。例如：“此 RFC 经过了组件框架团队的设计审核。”
缺点、替代方案和未知情况
此 RFC 会给 RFC 作者带来少量额外开销。