| 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 作者：TODO，找出幾位熟悉該程序的同仁
社交：
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 積極參與，就能減輕這些問題的影響。