| RFC-0248：問題陳述式 | |
|---|---|
| 狀態 | 已接受 |
| 領域 |
|
| 說明 | 在 RFC 程序中新增問題陳述階段，並嘗試簡化作者的程序。 |
| 更小鳥 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年月分) | 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 參與來緩解。