| RFC-0214：Fuchsia 流失率政策 | |
|---|---|
| 状态 | 已接受 |
| 区域 |
|
| 说明 | 列出权利和责任，以减少在更改上花费的工程时间。 |
| 问题 | |
| Gerrit 更改 | |
| 作者 | |
| 审核人 | |
| 提交日期（年-月-日） | 2022-12-22 |
| 审核日期（年-月-日） | 2023-04-03 |
摘要
更新了 Fuchsia 的治理模型，添加了报告更改成本、主动通知受影响团队以及限制受影响团队的工作量的要求，以纳入平台流失率政策。
设计初衷
Fuchsia 现在是一个大型项目，由多个独立团队共同努力，以实现各种客户的目标。与此同时，像 Fuchsia 这样的平台必须以需要整个代码库中许多贡献者间歇性投入精力的方式进行演变，这种方式在非正式场合中被称为“流失”。
目标
- 使 Fuchsia 工程实践与项目的支持和稳定性目标保持一致。
- 准确估算迁移和其他外部强制更改所需的时间。
- 明确 RFC 设计和 FPS 人员配置决策之间的界限。
- 提供一系列迁移策略供团队考虑。
非目标
- 更改已开始的大型更改的策略。
- 确定应进行哪些更改。
- 强制要求所有更改都采用特定的迁移策略。
- 降低更改速率。
- 针对无需客户团队执行任何操作的更改设置政策。
利益相关方
教员：
- abarth@google.com
Reviewers:
- abarth@google.com
- keir@google.com
- shayba@google.com
咨询了：
- neelsa@google.com
- tombergan@google.com
社交：
此 RFC 最初是作为 Google 内部文档撰写的，在 Fuchsia 团队（包括 Fuchsia 工程委员会的成员）中广泛共享。
实现
此提案是对 Fuchsia 治理模型的更改，详见“受影响的团队”和“发起团队”子标题。如果此 RFC 获得批准，我们将通过更新 FEC 章程、添加治理政策和修改新贡献者指南来实现该 RFC。
非正式地讲，如果更改需要其他贡献者进行开发工作或更改工作流，则会被视为“全 Fuchsia 范围”更改。这包括影响 ABI、SDK 的任何公共部分、产品的内容或生成的代码的更改。
所有 Fuchsia 范围的更改都会给许多 Fuchsia 贡献者带来工程费用。此政策可集中管理这些费用，以尽可能降低费用。在本政策中，“受影响的团队”是指为了适应流失情况，必须批准或更改自己的代码、工作流或文档的任何团队。
发起更改的贡献者或团队有责任解决任何破坏问题。在大多数情况下，这意味着采用“先还原，再诊断”的方法。
受影响的团队
如果您的团队受到已获批准的更改的影响，请执行以下操作：
在 2 个工作日内回复收到的 CL 评价或其他更改。
协助更改作者达成令人满意的结果，例如批准其工作、回复调查问卷、明确拒绝建议的更改、要求对更改进行具体修改，以及/或者回答更改作者关于主题的问题。
如果您超过 10% 的时间都花在应对流失问题上，可以向 eng-council@fuchsia.dev 举报此问题
如果更改涉及风格指南（例如 lint、编译器警告等），您可以决定如何快速解决新的样式违规问题。
发起团队
如果没有流失政策，对于导致流失的更改，我们不会有任何正式的要求或预期。本部分增加了此类更改的作者的责任。
如果您的团队发起变更并将负责完成所有工作，请按以下步骤操作：
- 向 FEC 发送邮件，说明对其他团队的影响微乎其微。
- 发送邮件至 announce@fuchsia.dev，告知贡献者迁移事宜。
- 继续迁移。
如果您的团队发起的更改需要其他团队付出大量精力（包括由 RFC 发起的更改），请执行以下操作：
- 制定一项计划，向 FEC 证明您的团队将至少将 80% 的非自动化工作量转变为手动工作量。方案必须包含受影响团队的列表和更改的预计费用。
- FEC 批准您的方案后，请通知受影响的团队。他们必须能够在至少两个季度内使用季度规划来安排工作，因此请在季度开始前一周通知相关团队。
- 继续迁移。
向后兼容性
此政策不会影响任何正在进行的迁移。
文档
为协助更改作者，fuchsia.dev 上将提供迁移计划示例。
缺点、替代方案和未知情况
此方案的主要缺点是，在流程开始时必须涉及 FEC。请务必让更改作者及时收到 FEC 和受影响贡献者的回复。
一种备选政策要求受影响的贡献者批准更改。这样做的好处是，更改作者始终可以取得进展。我们之所以拒绝此替代方案，是因为它剥夺了受影响的贡献者就拟议更改的价值和弊害提供反馈的机会。
另一种替代方案是采用更严格的方法，即所有迁移都必须是软过渡，使用可用的版本控制机制，并采用更慢的节奏，以便将工作量分摊到所有 Fuchsia 贡献者身上。这与拟议的政策不同，因为它没有为受影响的团队设置互动预期。我们否决了此方案，因为它没有对审核时间表设置任何限制，这会使发起团队难以进行规划和及时取得进展。
在先技术和参考文档
在阅读此提案时，是否有任何背景资料可能对您有所帮助？例如，其他操作系统是否解决了此提案要解决的问题？