Fuchsia 现在是一个大型项目，有多个独立团队正在努力实现各种客户的目标。同时，Fucsia 等平台必须做出改进，需要整个代码库中的许多贡献者进行间歇性工作，这通常称为“流失”。
此政策已在 RFC-0214 中获得批准。
目标
- 使 Fuchsia 工程实践与项目既定的支持和稳定性目标保持一致。
- 准确估算迁移及其他外部强制更改所花费的时间。
- 阐明了 RFC 设计与 FPS 人员配置决策之间的边界。
- 提供一系列迁移策略供团队考虑。
非目标
- 针对已开始的大规模更改更改策略。
- 确定应做出哪些更改。
- 为所有更改指定特定的迁移策略。
- 降低更改频率。
- 针对无需客户团队采取任何行动的更改设置政策。
政策
简单来说，如果某项更改需要其他贡献者进行开发工作或涉及到工作流更改，则该更改会被视为“紫红色”。这包括会影响 ABI、SDK 的任何公开部分、产品内容或生成的代码的更改。
所有 Fuchsia 范围的更改都会给许多 Fuchsia 贡献者带来工程成本。此政策集中了这些费用，以尽量减少这些费用。 在本政策中，“受影响的团队”是指必须批准或更改自己的代码、工作流或文档才能应对用户流失的任何团队。
发起更改的贡献者或团队需负责解决任何中断问题。大多数情况下，这意味着采用“先还原，然后诊断第二项”方法。
受影响的团队
如果您的团队受到已获批准的更改的影响：
请在 2 个工作日内对收到的 CL 审核或其他更改做出回应。
支持变更作者得出令人满意的结论，例如批准其工作、回复调查问卷、明确拒绝建议的更改、请求对变更进行特定修改，和/或回答变更作者就主题提出的问题。
如果超过 10% 的时间用于应对用户流失，您可以通过 eng-council@fuchsia.dev 标记此问题
如果更改包含在样式指南（例如 lint、编译器警告等）中，您需要决定解决新样式违规问题的速度。
启动团队
如果没有用户流失政策，就没有针对导致用户流失的更改的正式要求或预期。本部分增加了此类更改作者的责任。
如果您的团队要发起变更并将完成全部工作：
- 向 FEC 发送邮件，说明对其他团队的影响最小。
- 向 announce@fuchsia.dev 发送电子邮件，向参与者通知迁移事宜。
- 继续迁移。
如果您的团队发起的更改需要其他人完成大量工作（包括由 RFC 发起的更改），请执行以下操作：
- 创建一个方案，向 FEC 证明您的团队将花费至少 80% 无法通过自动化技术处理的手动工作。方案必须包含受影响团队的列表以及更改的估算费用。
- 在 FEC 批准您的方案后，通知受影响的团队。他们必须能够至少在两个季度内使用季度规划来安排工作，因此在季度开始前超过一周通知团队。
- 继续迁移。