Fuchsia 現在是一個大型專案，擁有多個獨立團隊，致力於達成各種客戶的目標。同時，Fchsia 等平台也必須以不同方式不斷演進，需要各個程式碼集的眾多貢獻者經常採取行動，也就是所謂的「流失」。
這項政策已經過 RFC-0214 修訂。
目標
- 根據專案所述的支援和穩定性目標，調整 Fuchsia 工程做法。
- 準確預估遷移和其他外部變更所花費的時間。
- 說明 RFC 設計與 FPS 人員配置決策之間的界線。
- 提供一系列遷移策略供團隊參考。
非目標
- 針對已開始的大規模變化調整策略。
- 決定要進行哪些變更。
- 針對所有變更制定特定的遷移策略。
- 降低變更頻率。
- 針對客戶團隊不必費力進行的異動設定政策。
政策
相反地，如果變更需要投入心力進行開發或由其他貢獻者進行變更，則系統會將變更視為「全能通用」。包括會影響 ABI、SDK 的任何公開部分、產品的內容或產生的程式碼的變更。
所有 Fuchsia 變更都會對許多 Fuchsia 貢獻者產生工程費用。這項政策會集中處理這些費用，以便盡可能降低費用。 就這項政策而言，「受影響的團隊」是指必須核准或變更自己的程式碼、工作流程或文件的團隊，才能配合使用者流失。
發起變更以解決任何中斷問題，由貢獻者或團隊負責。在多數情況下，這意味著採取「先還原為第二段」的方法。
受影響的團隊
如果您的團隊受到核准的變更影響：
在兩個工作天內回覆收到的 CL 評論或其他異動。
協助變更作者達成令人滿意的結論，例如核准作品、回覆問卷調查、明確拒絕提議的變更、要求變更變更，以及/或回答變更作者有關主題的問題。
如果您花 10% 的時間回應流失情形，則可以使用 eng-council@fuchsia.dev 標記這個問題
如果變更在樣式指南中 (例如 Lint、編譯器警告等)，請決定如何快速解決新的樣式違規事項。
發起團隊
如果沒有流失政策，就沒有會造成使用者流失的變更正式要求或期望。本節說明此類變更的作者負責。
如果團隊正在推動改變，而且會完全完成工作，您可以：
- 傳送郵件給 FEC，說明將對其他團隊的影響降到最低。
- 傳送電子郵件至 announce@fuchsia.dev 通知遷移人員。
- 繼續執行遷移作業。
如果您的團隊發起的變更需要其他人花費許多心力，包括 RFC 所發起的變更，做法如下：
- 制定計畫，向 FEC 證明您的團隊將花費至少 80% 的手動工作，但無法透過自動化功能處理。方案必須包含受影響的團隊清單，以及變更的預估費用。
- FEC 核准您的方案後，請通知受影響的團隊。他們必須能夠使用每季規劃 (至少兩季) 排定工作時間，因此請在本季開始的一週前通知團隊。
- 繼續執行遷移作業。