| RFC-0067：Fchsia RFC 程序的額外項目 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 推出「最終通話」步驟，強調離開條件；加入修訂 RFC 的程序。 |
| 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年/月) | 2020-12-14 |
| 審查日期 (年/月) | 2020-02-17 |
摘要
這個 RFC 提議在 RFC-0001 中詳述的 Fuchsia RFC 程序。「上次呼叫」步驟取代了「核准」步驟。系統會呼叫程序中每個步驟的離開條件。 我們導入了修改 RFC 的程序。
提振精神
這些變更的動機是解決透過程序收到的意見回饋，並明確釐清問題。
執行「上次通話」步驟時，Eng Council 成員若在 RFC 上的疊代作業發生時，傳送電子郵件至 eng-council-discuss@fuchsia.dev。 此步驟會藉由傳送推送樣式通知，在做出最終決定之前請求其他意見回饋，藉此擴大 RFC 的觸及範圍。
明確指出程序的每個步驟的結束條件，嘗試總結及釐清該步驟的預期性質。
此外，在「疊代」步驟結束時，Eng Council 必須確認利害關係人並進行必要變更。這會嘗試確保利害關係人名單填寫完成，且在進入程序的下一階段前已取得過。
實作
對 RFC 程序中的每個步驟提出變更
社交
沒有提議的變更。新增下列結束條件。
離開條件：未指定。這取決於作者是否可自行斟酌。 這個步驟可以幫助作者精準掌握目標和可能的解決方案。 如果使用者認為已達成這個目標，就可以繼續進行下一個步驟。
草稿
為這個步驟新增下列結束條件。
離開條件：建立包含 RFC 的 CL。
疊代
這個步驟還有更多內容，包括讓作者在開發初期就徵求更多意見，以及取得由工程委員會驗證的利害關係人最終名單。下列文字會新增至 RFC 程序：
「此外，您可以將 CL 傳送電子郵件至 eng-council-discuss@fuchsia.dev，請求其他意見回饋。」
「在這個步驟結束時，請將利害關係人及其職務清單提供給 eng-council@fuchsia.dev。工程委員會會向確定的利害關係人提供確認，並在必要時提出修改建議。並請找出任何新的利害關係人進行疊代。」
除了上述內容，我們也會加入下列附註，協助審查人員引用意見回饋：
「給審查人員的注意事項：RFC 程序的用意是鼓勵各種觀點並熱烈進行討論。通常在公開論壇中提出負面意見回饋可能並不容易。如有需要，審查人員可以聯絡自己的待開發客戶、同儕或工程委員會，協助他們制定意見回饋，進而在 CL 中有效送達。」
退場標準：經 Eng Council 識別並核准的所有相關人員；徵詢及整合意見。
上次通話時間
「核准」步驟將重新命名為「上次通話」。另外還有一個步驟，就是請 Eng Council 成員先徵求所有最終意見回饋，再針對 RFC 做出決定。這個步驟會新增下列文字：
「當 RFC 上的疊代作業開始後，作者必須傳送電子郵件給 eng-council@fuchsia.dev，要求對方將 RFC 的狀態移至最後呼叫。工程委員會成員會傳送電子郵件給所有利害關係人，並將 eng-council-discuss@fuchsia.dev 徵求最終意見回饋，再開始進行決策步驟。RFC 團隊將在未來 7 天內開放提供意見。」
退出標準：所有利害關係人提供的意見回饋；所有意見均已回答。
提交
如果在已核准的 RFC 中發生拒絕，則必須將相應的原因和任何優缺點納入 RFC。系統會將下列文字新增至這個部分：
如果有人在核准的 RFC 中發現拒絕，當標記清除時，Eng Council 成員會指示是否需要在 RFC 中記錄任何額外資訊。為此，系統會在這個部分新增下列文字：
「工程理事會會指出是否需要在 RFC 中記錄任何其他資訊，例如採用不同做法或取捨的理由。」
系統會為遭拒的 RFC 指派下一個可用的 RFC 號碼。運算文字將變更如下：
「如果專案決定拒絕您的 RFC，Eng Council 的成員會為您的 CL 加上註解，指出 RFC 遭到拒絕，提供拒絕理由並指派 RFC 編號。」
離開條件：指派的 RFC 號碼；納入任何適用的理由、取捨和 Eng Council 意見回饋；已合併 RFC。
修訂 RFC 的程序
如果符合下列條件，即可修改現有的 RFC：
- 已核准的項目說明。
- 機械修訂條款，例如更新連結、說明文件、使用情況等。
- 日後在設計中發現的任何改善或輕微變更，例如實作期間。
如要調整設計，請說明原本的設計目標、原因與變化。
如有任何重大設計變更，請提交新的 RFC。
- 在新 RFC 中，請參照原始 RFC，並在標題中明確指出變更類型，例如附加條款。
- 如果原始 RFC 中的設計已淘汰，請修改原始 RFC 以呼叫並參照新的 RFC。
- 如果多個 RFC 對同一區域進行變更，請建立新的 RFC 編譯現有的 RFC。請一併修訂現有的 RFC，以參照新的 RFC。
如果 RFC 程序正在更新，請一併更新 RFC 程序頁面。
缺點、替代方案和未知
缺點：在「上次通話」步驟中，我們已向 eng-council-discuss@ 導入推送樣式通知，您可能無法在 7 個日曆天期間內收到意見回饋。這種取捨的用意是確保 RFC 長時間不會維持開啟狀態。
不明：隨著 RFC 程序的使用率越來越高，程序也會不斷演進。