| RFC-0214：Fuchsia 流失率政策 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 列舉權利和責任，以減少工程師花在變更上的時間。 |
| 問題 | |
| Gerrit 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2022-12-22 |
| 審查日期 (年-月-日) | 2023-04-03 |
摘要
更新 Fuchsia 的治理模式，加入要求以回報變更成本、主動通知受影響的團隊，以及限制受影響團隊的工作量，納入平台流失政策。
提振精神
Fuchsia 目前是一個大型專案，有多個獨立團隊努力達成各種客戶的目標。同時，Fuchsia 等平台必須以需要許多程式碼集貢獻者不時投入心力的做法進行演進，這在非正式場合中稱為「流失」。
目標
- 讓 Fuchsia 工程實作與專案的支援和穩定性目標保持一致。
- 準確估算遷移作業和其他外部異動所需的時間。
- 明確界定 RFC 設計與 FPS 人力配置決策之間的界線。
- 提供一系列遷移策略供團隊參考。
非目標
- 變更已開始進行的大規模變更策略。
- 決定要進行哪些變更。
- 針對所有變更，規定特定的遷移策略。
- 降低變更率。
- 設定政策，適用於不需要客戶團隊付出額外努力的變更。
相關人員
協助人員：
- abarth@google.com
審查者：
- abarth@google.com
- keir@google.com
- shayba@google.com
諮詢：
- neelsa@google.com
- tombergan@google.com
社會化：
這份 RFC 最初是 Google 內部文件，廣泛分享給 Fuchsia 團隊，包括 Fuchsia Eng Council 成員。
實作
這項提案是對 Fuchsia 治理模式的變更，詳情請參閱「受影響的團隊」和「發起團隊」副標題。如果這個 RFC 獲得核准，我們會更新 FEC 章程、新增治理政策，並修訂新的貢獻者指南，以便實施這項 RFC。
非正式來說，如果變更需要其他貢獻者進行開發工作或變更工作流程，就會被視為「Fuchsia 全體」變更。這包括影響 ABI 的變更、SDK 的任何公開部分、產品的內容，或產生的程式碼。
所有 Fuchsia 全局變更都會為許多 Fuchsia 貢獻者帶來工程成本。這項政策會將這些費用集中管理，以便盡可能降低成本。就本政策而言，「受影響的團隊」是指任何必須核准或變更自身程式碼、工作流程或文件，以便因應流失的團隊。
發起變更的作者或團隊有責任解決任何中斷情形。在大多數情況下，這表示您必須採取「先還原，再診斷」的做法。
受影響的團隊
如果您的團隊受到核准的異動影響：
在兩個工作天內回覆 CL 審查或其他變更。
協助變更作者得出令人滿意的結論，例如核准他們的工作、回覆問卷調查、明確拒絕提議的變更、要求對變更進行特定修改，以及/或回答變更作者對主題的疑問。
如果您花費超過 10% 的時間回應客戶流失問題，可以將這個問題回報給 eng-council@fuchsia.dev
如果變更內容屬於風格指南 (例如 Lint、編譯器警告等)，您可以決定要多快解決新的風格違規問題。
啟動團隊
沒有客戶流失政策，就沒有正式規定或期望，無法避免造成客戶流失的變更。本節會為這類變更的作者新增責任。
如果您的團隊正在發起變更，且將負責 100% 的工作：
- 傳送電子郵件給FEC，說明對其他團隊的影響最小。
- 傳送電子郵件至 announce@fuchsia.dev，通知貢獻者移轉作業。
- 繼續遷移。
如果您的團隊啟動變更，需要其他人付出大量心力 (包括 RFC 啟動的變更)：
- 請建立計畫，向FEC說明您的團隊將投入至少 80% 的人工作業時間，以處理自動化無法處理的部分。計畫必須列出受影響的團隊，並估算變更的成本。
- FEC 核准企劃書後，請通知受影響的團隊。他們必須能夠在至少兩個季度內，使用季度規劃來排定工作，因此請在季度開始前至少一週通知團隊。
- 繼續遷移。
回溯相容性
這項政策不會影響任何有效的遷移作業。
說明文件
為了協助變更作者，我們會在 fuchsia.dev 上提供遷移計畫範例。
缺點、替代方案和未知事項
這項提案的主要缺點，是需要在程序一開始時就加入FEC。變更作者必須及時收到 FEC 和受影響的貢獻者提供的回應。
另一種替代政策則要求受影響的內容提供者核准變更。這樣一來，變更作者就能隨時進行變更。這個替代方案已遭否決，因為這會讓受影響的內容提供者無法針對建議變更的價值和危害提供意見。
另一種做法是採用更嚴格的做法，所有遷移作業都必須使用可用的版本控制機制進行軟遷移，並以較慢的速度進行，以便將工作分散至所有 Fuchsia 貢獻者。這與建議的政策不同，因為我們並未為受影響的團隊設定參與度預期值。這個替代方案已遭到駁回，因為它沒有設定審查時間表的限制，導致發起團隊難以規劃及及時取得進展。
既有技術與參考資料
閱讀這份提案時，是否有任何背景資料可能有所幫助？舉例來說，其他作業系統是否解決了這個提案要解決的問題？