| RFC-0067：Fuchsia RFC 流程的补充 | |
|---|---|
| 状态 | 已接受 |
| 区域 |
|
| 说明 | 引入了“最后通告”步骤；指出了退出条件；添加了修改 RFC 的流程。 |
| Gerrit 更改 | |
| 作者 | |
| 审核人 | |
| 提交日期（年-月-日） | 2020-12-14 |
| 审核日期（年-月-日） | 2020-02-17 |
摘要
本 RFC 建议对 RFC-0001 中详述的 Fuchsia RFC 流程进行一些补充。引入了“最后通话”步骤，以取代“批准”步骤。会指出流程的每个步骤的退出条件。介绍了修改 RFC 的流程。
设计初衷
我们之所以做出这些更改，是为了解决我们在该流程上收到的反馈，并明确说明一些事项。
“最后通话”步骤要求工程委员会成员在 RFC 迭代趋于一致时向 eng-council-discuss@fuchsia.dev 发送电子邮件。引入此步骤旨在通过发送推送式通知来征求任何其他反馈，以便在做出最终决定之前扩大 RFC 的覆盖面。
明确指出流程每个步骤的退出条件，旨在总结和阐明该步骤应达到的预期结果。
除此之外，在“迭代”步骤结束后，工程委员会必须确认利益相关方，并根据需要进行任何更改。这是为了确保利益相关方名单完整无缺，并在进入流程的下一阶段之前与他们进行了咨询。
实现
对 RFC 流程的每一步提出的更改
社交
没有建议的更改。添加了以下退出条件。
退出条件：没有具体规定。这取决于作者的判断。 此步骤旨在帮助作者明确目标和潜在解决方案。如果他们认为已完成此操作，则可以继续执行下一步。
草稿
为此步骤添加以下退出条件。
退出条件：创建包含 RFC 的 CL。
迭代
此步骤的其他变化包括：让作者在流程早期征求更广泛的反馈，并由工程委员会验证最终的利益相关方名单。以下文本将添加到 RFC 流程中：
“此外，您还可以将 CL 发送至 eng-council-discuss@fuchsia.dev，以获取更多反馈。”
“在此步骤结束时，请向 eng-council@fuchsia.dev 提供利益相关方及其角色的列表。工程委员会将确认所确定的利益相关方，并根据需要提出任何更改建议。与新发现的任何利益相关方进行迭代。”
除上述内容外，我们还会添加以下备注，以帮助审核员撰写反馈：
“给审核者的提示：RFC 流程旨在鼓励提出多种观点和进行热烈讨论。在公开论坛中提供负面反馈通常会很困难。如有需要，审核者可以联系其主管、同事或工程委员会，请对方帮助他们制定反馈，以便在 CL 中有效传达。”
退出条件：所有利益相关方均已确定并获得工程委员会批准；征求并采纳了反馈。
最后一次点单
“批准”步骤将更名为“最后一次确认”。此处的额外步骤是，在对 RFC 做出决定之前，让工程委员会成员征求任何最终反馈。系统会将以下文本添加到此步骤中：
“RFC 迭代趋于一致后，作者必须发送电子邮件至 eng-council@fuchsia.dev，请求将 RFC 的状态更改为‘最后通告’。在进入决策步骤之前，工程委员会成员会向所有利益相关方和 eng-council-discuss@fuchsia.dev 发送电子邮件，征求任何最终反馈。RFC 将在接下来的 7 个日历日内接受反馈。”
退出条件：所有利益相关方提供反馈；所有反馈均已得到解决。
提交
如果已获批准的 RFC 中存在异议，则必须将相应的理由和做出的任何权衡纳入 RFC 中。系统会在此部分添加以下文本：
如果已批准的 RFC 中存在异议，在移除标记后，工程委员会成员会指明 RFC 中是否需要记录任何其他信息。为此，我们将在此部分中添加以下文本：
“工程委员会会指明您的 RFC 中是否需要记录任何其他信息，例如采用其他方法或做出权衡的理由。”
被拒 RFC 将被分配下一个可用的 RFC 编号。有效文本将发生如下变化：
“如果项目决定拒绝您的 RFC，工程委员会的成员会对您的 CL 进行评论，说明 RFC 已被拒绝，并提供拒绝原因，还会为 RFC 分配编号。”
退出条件：已分配 RFC 编号；已纳入所有适用的理由、权衡和工程委员会反馈；RFC 已合并。
修改 RFC 的流程
如果符合以下条件，则可以修改现有 RFC：
- 对已批准内容的说明。
- 机械性修订，例如更新链接、文档、用法等
- 后续发现的任何设计改进或细微更改，例如在实现过程中发现的。
对于设计变更，请说明原始设计目标是什么，以及这些目标为何发生变化以及如何发生变化。
对于设计上的任何重大更改，请提交新的 RFC。
- 在新 RFC 中，请引用原始 RFC，并在标题中明确说明更改类型，例如附录。
- 如果原始 RFC 中的设计已废弃，请修改原始 RFC 以指明这一点，并引用新 RFC。
- 如果有多个 RFC 对同一区域进行更改，请创建一个新的 RFC 来编译现有 RFC。请同时修改现有 RFC 以引用新 RFC。
如果 RFC 流程正在更新，请同时更新 RFC 流程页面。
缺点、替代方案和未知情况
缺点：在“最后通话”步骤中，虽然我们向 eng-council-discuss@ 引入了推送式通知，但我们可能会错过在 7 个日历日内收到反馈。这是为确保 RFC 不会保持打开状态太长时间而做出的权衡。
未知事项：随着 RFC 流程的越来越广泛使用，该流程将不断发展。