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