| RFC-0248：问题陈述 | |
|---|---|
| 状态 | 已接受 |
| 区域 |
|
| 说明 | 为 RFC 流程添加了问题陈述阶段，并尝试简化作者的流程。 |
| Gerrit 更改 | |
| 作者 | |
| 审核人 | |
| 提交日期（年-月-日） | 2024-02-22 |
| 审核日期（年-月-日） | 2024-05-03 |
问题陈述
Fuchsia RFC 有时会“停滞不前”，需要很长时间才能达成一致，或者在要解决的问题上存在分歧。部分子团队认为 RFC 流程非常缓慢。这种情况可能以多种形式出现，但一种常见的反模式是在流程后期就 RFC 实际要解决的问题产生分歧。如果确定利益相关方需要很长时间，或者 CL 审核人员迟迟不提供反馈，RFC 也可能会停滞不前。我们应为时间紧迫的 RFC 提供简化的流程，并在需要时提供升级到 Fuchsia 工程委员会 (FEC) 的途径。
摘要
此 RFC 对 RFC 流程文本进行了多项更改。其中包括：
- 阐明了就问题达成一致的重要性。
- 添加了以下选项：在发现问题后但在确定具体解决方案之前，与 FEC 联系以寻求协调员的帮助。
- 明确了作者可以选择开始原型设计或退出 RFC 流程的位置。
利益相关方
辅导员：
abarth@google.com
审核者：
FEC 成员：abarth@google.com、cpu@google.com RFC 作者：harshanv@google.com、wittrock@google.com
已咨询：
RFC 作者：待办事项，确定一些熟悉该流程的人员
共同化：
FEC 在多次会议中讨论了此 RFC，并与 RFC 作者进行了多次信息收集讨论。
要求
- RFC 流程应“快速失败”，并帮助作者避免在错误的问题上投入大量时间。
- RFC 流程应提供明确的升级途径，以便在需要及时反馈时进行升级。
- RFC 流程应避免给作者带来过重的流程负担。
- RFC 流程应鼓励作者测试自己的想法并“边做边学”。
设计
请参阅 RFC 模板变更。建议的 RFC 流程阶段如下：
- 第 1 步：确定问题
- 第 2 步：问题陈述
- 第 3 步：分配主持人
- 第 4 步：利益相关者发现
- 第 5 步：社会化
- 第 6 步：起草和迭代
- 第 7 步：最后一次通话
- 第 8 步：提交
对于许多 RFC，该流程与之前非常相似，因为作者已经在 RFC 中撰写问题陈述。不过，提前提出问题陈述并分配促成者，可让作者尽早从 FEC 获得帮助，以便识别利益相关者并获得他们的反馈。工程委员会可以作为流程中任何问题的升级点。
我们鼓励作者在整个过程中（尤其是撰写完整文章之前）对自己的想法进行原型设计。这有助于验证创意，并尽早发现其他限制，让作者有机会在投入大量时间之前进行调整。此外，原型还可以降低 RFC 需要后续修订的可能性。
实现
签入有关 RFC 流程变更的 CL，并向 Fuchsia 团队进行技术讲座，介绍如何完成该流程。
工效学设计
虽然此变更确实在 RFC 流程中引入了额外的步骤，但这些步骤通常相当快。如果作者已经撰写了 RFC，那么只要他们确信自己的问题陈述和解决方案不会引起利益相关者的争议，就可以选择在一天内“快速完成”流程的早期阶段。
如果其中一个步骤花费的时间较长（例如，作者发现了问题，但收到的反馈是此问题未正确提出），那么额外的延迟时间会带来价值，因为作者可以在投入时间来撰写完整的设计文档之前纠正错误。
向后兼容性
无需更新较旧的 RFC。
安全性和隐私权注意事项
通过在流程中更早地确定利益相关者，此变更应能鼓励安全和隐私权团队在相关情况下更早地参与进来。
文档
所有相关的文档更改都包含在 RFC CL 中。这些更改会影响 RFC 流程和 RFC 模板。
缺点、替代方案和未知因素
我们可以保持 RFC 流程不变。该流程目前存在的问题仍会存在，但可以通过 FEC 的积极参与来缓解。