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