| RFC-0122：RFC 相關人員 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 修改有關識別及管理利害關係人的 RFC 程序 |
| Gerrit 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2021-06-21 |
| 審查日期 (年-月-日) | 2021-08-16 |
摘要
這項 RFC 修訂了 RFC 程序和 RFC 範本，清楚說明如何識別及管理 RFC 的利害關係人。這項更新會在 RFC 範本中新增「利害關係人」部分，並說明可能的利害關係人角色。
提振精神
目前，Fuchsia 工程委員會 (FEC) 負責確保每個 RFC 都經過適當利害關係人審查。這種責任集中化的做法有一些缺點。雖然這項工作仰賴 FEC 委員會成員對 Fuchsia 機構的瞭解 (預期資格)，但缺乏可供外部查看的構件，因此無法有機地記錄這項知識，讓其他人瞭解 Fuchsia 專案的這方面資訊。
此外，在識別利害關係人時，特別是識別審查人員 (其意見和投票在決策過程中具有阻礙權重) 與其他意見僅供參考的人員時，會出現一些混淆情況。舉例來說，在 Fuchsia 上建構 UI 的任何人，都可能受到圖像變更的影響，但圖像主管的意見會更具份量。
將利害關係人識別納入 RFC 程序，有助於明確討論誰必須核准 RFC，以及原因。明確找出利害關係人，有助於解決上述兩項問題。
我們希望透過這項 RFC 程序異動，協助 RFC 作者瞭解哪些意見僅供參考，哪些意見會阻礙程序進行，並確保每項 RFC 都有適當數量的審查人員，以及明確的選擇指南，讓 RFC 程序更容易進行。這項異動也讓所有人都能參與討論利害關係人及其各自的角色，進一步創造公平的競爭環境。
利害關係人
主持人：abarth
審查人員：abarth (FEC 成員)、wittrock、pascallious (共同作者)。近期的 RFC 作者：bprosnitz、simonshields、aaronwood、dgilhooley。
諮詢對象：FEC 成員。
社交化：這份 RFC 草案已傳送至 FEC 討論郵寄清單，供大家提出意見。
設計
提案請求 (RFC) 程序異動 (依章節)
角色與職責
我們進一步將利害關係人的角色和責任細分為：
協助人員。由 FEC 指派，負責在 RFC 流程中引導這項 RFC 的人員。目前必須是 FEC 成員。
審查者。當 FEC 決定接受或拒絕 RFC 時，會考量這些利害關係人的 +1 或 -1。(雖然 +2 是程式碼 CL 的「核准」，但我們通常會請審查人員 +1 或 -1，表示他們是否支持，並請促成者在核准後 +2)。
諮詢對象。徵求意見回饋的利害關係人，但 FEC 決定是否接受 RFC 時，不會考慮其 +1 或 -1。
社交
新增下列文字：
在這個階段，RFC 作者應開始找出這項 RFC 的利害關係人。
草稿
新增下列文字：
RFC 作者應與 RFC 領域的專家諮詢，提出最初的利害關係人名單。利害關係人組合一開始可能留空或不完整。如有任何疑慮，應諮詢 FEC，協助找出利害關係人。
反覆提問
編輯第二段：
在機制方面，您應邀請利害關係人對 RFC 提供意見，方法是在 CL 中將他們新增至「審查者」(需要 +1 的利害關係人) 或「副本」欄位 (「諮詢」利害關係人)，就像一般程式碼審查一樣。此外，您也可以傳送電子郵件至 eng-council-discuss@fuchsia.dev，徵求其他意見回饋。利害關係人應在程式碼審查工具中，於 RFC 留下註解，提供意見回饋。
新增下列文字：
任何人都能在 RFC CL 中留言，提議為特定 RFC 新增利害關係人 (包括自己)，但這些提議不一定會獲得接受。如果大家普遍同意，RFC 作者應新增利害關係人。FEC 也可能會要求作者新增利害關係人。
利害關係人可以「選擇不參與」，要求移除自己，或委派他人審查 (例如，委派給相關領域的另一位專家)。FEC 可能會要求移除利害關係人，或將利害關係人從「審查員」移至「諮詢對象」。
意見回饋可能包含非利害關係人的留言。如果這些留言與作者相關，作者應回覆留言，但不必解決留言問題，即可進入最後一通電話階段。如果留言指出對於誰是利害關係人有異議，FEC 可以協助解決這個問題。
最後點單
編輯第二段：
通常審查員會以 +1 簽核，主持人則會以 +2 簽核。如果諮詢的利害關係人希望表達對 RFC 的熱情，也可以簽署 +1，但這並非必要。
中繼資料變更
建立 RFC 的新增內容：
已諮詢 - 獲得核准或遭到拒絕後，必須填寫。已諮詢過這項 RFC，但不需要 +1 的利害關係人。
RFC 範本異動
在 RFC-0000：RFC 範本中新增下列選用區段 (位於「動機」之後、「設計」之前)：
利害關係人
誰會受到這項 RFC 是否通過的影響？(這個部分為選填，但建議填寫)。
協助人員：
由 FEC 指派，負責在 RFC 程序中引導此 RFC 的人員。
審查者：
列出投票者 (贊成或反對)，FEC 會在決定是否接受或拒絕這項 RFC 時，將這些投票納入考量。如適用，也請列出預期專注的領域，例如「FIDL」或「安全性」。在某些情況下，這個部分一開始可能會留空，並在初步的社交化階段後完成利害關係人探索。一般來說，「審查人員」應列在 Gerrit 的審查人員行中，而「諮詢對象」則應加入副本。請注意，審查員人數應維持在可管理的範圍內，但確切人數取決於相關 RFC 的範圍。
已諮詢：
列出應審查 RFC 的人員，但不必取得他們的核准。
社交：
本節可用於說明設計在進入 RFC 程序的「疊代」階段前，是如何進行社交化。例如：「This RFC went through a design review with the Component Framework team.」(這項 RFC 已通過元件架構團隊的設計審查)。
缺點、替代方案和未知事項
這項 RFC 會為 RFC 作者帶來少許額外負擔。