| 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 作者：待辦事項，找出幾位熟悉程序的人員
社會化：
這份 RFC 已在多場 FEC 會議中討論過，也與 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 的積極參與來減輕。