| RFC-0067：向 Fuchsia RFC 流程添加内容 | |
|---|---|
| 状态 | 已接受 |
| 领域 |
|
| 说明 | 推出“上次通话”步骤；指明退出条件；添加流程以修改 RFC。 |
| Gerrit 更改 | |
| 作者 | |
| 审核人 |
|
| 提交日期（年-月-日） | 2020-12-14 |
| 审核日期（年-月-日） | 2020-02-17 |
总结
此 RFC 建议对 Fuchsia RFC 流程进行一些补充，详见 RFC-0001。我们推出了“上次通话”步骤来代替“批准”步骤。系统会说出流程的每个步骤的退出条件。 并引入了修改 RFC 的过程。
设计初衷
我们之所以做出这些变更，是为了回应用户对该流程的反馈，并明确进行一些澄清。
当 RFC 的迭代收敛时，“上次调用”步骤要求工程委员会成员向 eng-council-think@fuchsia.dev 发送电子邮件。引入此步骤会尝试在做出最终决定之前发送推送式通知，以征求任何其他反馈，从而扩大 RFC 的覆盖范围。
明确指出流程每个步骤的退出条件，旨在总结和阐明对该步骤的要求。
除此之外，在“迭代”步骤结束时，工程委员会必须确认利益相关方，并根据需要进行更改。这是尝试确保利益相关方名单是完整的，并且在进入流程的下一阶段之前已咨询相关负责人。
实现
对 RFC 流程每个步骤的更改建议
社交
此处没有建议的更改。添加以下退出条件。
退出条件：没有明确说明。这由作者自行决定。 此步骤旨在帮助作者明确目标和可能的解决方案。如果他们认为已经完成了此步骤，则可以继续执行下一步。
草稿
为此步骤添加以下退出条件。
退出条件：创建包含 RFC 的 CL。
迭代
该步骤的补充包括：让作者在流程早期征集更广泛的反馈，以及获得由工程委员会验证的最终利益相关方列表。以下文本将添加到 RFC 流程中：
“此外，您可以通过电子邮件将您的 CL 发送至 eng-council-think@fuchsia.dev，以征求更多反馈。”
“在此步骤结束时，向 eng-council@fuchsia.dev 提供利益相关方及其角色的列表。工程委员会将就确定的利益相关方提供确认信息，并根据需要提出任何更改建议。与已确定的新利益相关方进行迭代更新。”
除了上述内容之外，我们还会添加以下备注，以帮助审核人员制定其反馈：
“审核者注意事项：RFC 流程旨在鼓励各种观点和积极的讨论。通常情况下，在公共论坛上给出负面反馈可能很难。如果需要，审核者可以联系其负责人、同行或工程委员会，帮助他们制定反馈，以便在 CL 中有效地提供。”
退出标准：工程委员会确定和批准的所有利益相关方；征集并纳入反馈。
上次通话
“批准”步骤将更名为“上次通话”。这里的另一个步骤是，让工程委员会成员在对 RFC 做出决定之前征求任何最终反馈。此步骤中将添加以下文本：
“RFC 的迭代收敛后，作者必须向 eng-council@fuchsia.dev 发送电子邮件，要求他们将 RFC 状态移至上次通话。在进入决策步骤之前，工程委员会成员将向所有利益相关方和 eng-council-think@fuchsia.dev 发送电子邮件，以征求任何最终反馈的意见。在接下来的 7 个日历日里，RFC 可接受反馈。”
退出条件：所有利益相关方的反馈；所有反馈均处理完毕。
提交
如果批准的 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-think@ 中引入了推送式通知，但在 7 个日历日内我们未必能收到反馈。这是为了确保 RFC 不会长时间保持打开状态的权衡。
未知：随着 RFC 流程日益普及，该流程也将不断发展。