| 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
审核者：
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 的谨慎参与来缓解。