| RFC-0122：RFC 利害關係人 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 修訂 RFC 程序以識別及管理相關人員 |
| 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年/月) | 2021-06-21 |
| 審查日期 (年/月) | 2021-08-16 |
摘要
這個 RFC 會修改 RFC 程序和 RFC 範本，以便更清楚地識別和管理 RFC 相關人員。這會在 RFC 範本中新增「利害關係人」區段，並清楚說明可能的利害關係人角色。
提振精神
目前，Fchsia Eng Council (FEC) 負責確保每項 RFC 都經過適當的相關人員審查。這項責任集中管理會產生一些缺點。雖然這仰賴 FEC 議會成員對 Fuchsia 機構的瞭解 (即預期評估)，但其中缺少一個外部可見的成果，可讓系統以自然的方式記錄這些知識，讓他人可以學習 Fuchsia 專案的這個部分。
此外，利害關係人的身分可能會讓您困惑，特別是在識別評論者時，他們的意見和投票會在決策過程中影響封鎖權重；而對於意見接受建議的人而言，這項資訊更是如此。舉例來說，在 Fuchsia 之上建構 UI 的使用者都可能會受到圖形變更的影響，但圖形主管的意見也會佔用較多權重。
將利害關係人識別程序納入 RFC 程序後，我們就可以明確討論必須核准 RFC 的人員以及原因。這項明確利害關係人識別有助於解決上述兩個問題。
此 RFC 程序變更的用意是協助 RFC 作者瞭解哪些意見回饋是建議以及哪些意見回饋遭封鎖，並藉此確保每個 RFC 都有適當數量的審查人員，並提供明確的選擇準則，讓此程序更易於瀏覽。這項變更也會讓相關人員討論誰的身分，以及他們各自擔任的職責，進而在公平的環境中發揮更大效益。
相關人員
講師：abarth
審查人員：abarth (FEC 成員)、wittrock、pascallious (coauthors)。目前有不少最新的 RFC 作者：bprosnitz、simonshields、Aaronwood、dgilhooley。
顧問：FEC 的成員。
社交化：這個 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 區域的專家時，建議一組初始相關人士。利害關係人一開始可能會留空或不完整。如果有任何歧義，客戶應諮詢 FEC，以協助找出利害關係人。
疊代
編輯第二個段落：
原則上，您應該邀請相關人員對 RFC 提供意見回饋，方法是將對方新增至 CL 中的「審查人員」(適用於需要 +1 的相關人員) 或「副本」欄位 (適用於「受制於」的利害關係人)，就像進行一般程式碼審查一樣。此外，您也可以將 CL 傳送電子郵件至 eng-council-discuss@fuchsia.dev 尋求其他意見回饋。相關人員應在程式碼審查工具中對您的 RFC 加上註解，以提供您的意見。
新增下列文字：
任何人都可以對 RFC CL 評論 (包括自己在內) 提議其他利害關係人，但不一定每次都會接受這些提案。如果協議涉及廣泛協議，RFC 作者應新增利害關係人。美國聯邦選舉委員會 (FEC) 也可能會要求作者新增利害關係人。
利害關係人可選擇「選擇退出」並要求移除，或將評論委任給相關領域的其他專家。FEC 可要求移除利害關係人，或將利害關係人移到「審查人員」之間。
意見回饋可能包含非利害關係人的留言。作者應視情況回應這些註解，但不必做出設定，就能進入最後一個呼叫階段。如果註解指出「誰是利害關係人」，FEC 可以協助解決這個問題。
上次通話
編輯第二個段落：
審查人員通常會按下 +1 號進行署名，講師需要按下 +2 號留下。如果受諮詢的利害關係人想表達他們對 RFC 的熱忱，也可以用 +1 簽名，但這並非必要。
中繼資料異動
建立 RFC 下列項目：
諮詢 - 核准或拒絕後必填。已諮詢這個 RFC 但不需要 +1 的利害關係人。
RFC 範本變更
將下列選用區段新增至 RFC-0000: RFC 範本 (「Motivation」之後，「Design」之前)：
相關人員
誰擔心是否接受這個 RFC？(本節為選填，但建議填寫)。
講師：
受 FEC 指派的人員透過 RFC 程序阻斷這個 RFC。
審查者：
FEC 會考量投票結果 (+1 或 -1) 的使用者，在決定該 RFC 是否接受或拒絕時，將納入考量。在適用情況下，請一併列出他們應注意的區域，例如「FIDL」或「安全性」。在某些情況下，這個部分可能是空白，導致利害關係人在進行初步的社交作業後完成探索。一般而言，「評論者」應列於德國的評論者行，而被「遭到檢舉」的使用者則應寄送副本。您應小心處理審查人員的數量，但確切數量取決於相關 RFC 的範圍。
顧問：
列出應審查 RFC，但不需要經過核准的人員。
社群媒體化：
本節可能用來說明在進入 RFC 程序的「疊代」階段之前，設計的社交方式。例如：「這是與元件架構團隊一起進行設計審核的 RFC。」
缺點、替代方案和未知
這個 RFC 會對 RFC 作者造成少量額外負擔。