RFC-0214:Fuchsia 流失政策

RFC-0214:Fucsia 流失政策
状态已接受
领域
  • 一般措施
  • 治理
说明

列举权利和职责,减少花在更改工作上的工程时间。

问题
  • 114568
Gerrit 更改
  • 781865
作者
审核人
提交日期(年-月-日)2022-12-22
审核日期(年-月-日)2023-04-03

总结

更新 Fuchsia 的治理模型以包含平台流失政策,方法是添加要求来报告更改的费用、主动通知受影响的团队并限制让受影响团队的工作量。

设计初衷

Fuchsia 现在是一个大型项目,有多个独立团队正在努力实现各种客户的目标。同时,Fucsia 等平台必须做出改进,需要整个代码库中的许多贡献者进行间歇性工作,这通常称为“流失”。

目标

  1. 使 Fuchsia 工程实践与项目既定的支持和稳定性目标保持一致。
  2. 准确估算迁移及其他外部强制更改所花费的时间。
  3. 阐明了 RFC 设计与 FPS 人员配置决策之间的边界。
  4. 提供一系列迁移策略供团队考虑。

非目标

  1. 针对已开始的大规模更改更改策略。
  2. 确定应做出哪些更改。
  3. 为所有更改指定特定的迁移策略。
  4. 降低更改频率。
  5. 针对无需客户团队采取任何行动的更改设置政策。

利益相关方

教员

  • abarth@google.com

审核者

  • abarth@google.com
  • keir@google.com
  • shayba@google.com

咨询人员

  • neelsa@google.com
  • tombergan@google.com

社交

此 RFC 最初是作为一个在 Fuchsia 团队(包括 Fuchsia Eng Council 成员)中广泛共享的 Google 内部文档。

实现

此提案是对 Fuchsia 治理模型的更改,列在“受影响的团队”和“启动团队”子标题中。如果接受此 RFC,我们将通过更新 FEC 章程、添加治理政策并修改新的贡献者指南来实现此 RFC。

简单来说,如果某项更改需要其他贡献者进行开发工作或涉及到工作流更改,则该更改会被视为“紫红色”。这包括会影响 ABISDK 的任何公开部分、产品内容或生成的代码的更改。

所有 Fuchsia 范围的更改都会给许多 Fuchsia 贡献者带来工程成本。此政策集中了这些费用,以尽量减少这些费用。 在本政策中,“受影响的团队”是指必须批准或更改自己的代码、工作流或文档才能应对用户流失的任何团队。

发起更改的贡献者或团队需负责解决任何中断问题。大多数情况下,这意味着采用“先还原,然后诊断第二项”方法。

受影响的团队

如果您的团队受到已获批准的更改的影响:

  • 请在 2 个工作日内对收到的 CL 审核或其他更改做出回应。

  • 支持变更作者得出令人满意的结论,例如批准其工作、回复调查问卷、明确拒绝建议的更改、请求对变更进行特定修改,和/或回答变更作者就主题提出的问题。

  • 如果超过 10% 的时间用于应对用户流失,您可以通过 eng-council@fuchsia.dev 标记此问题

  • 如果更改包含在样式指南(例如 lint、编译器警告等)中,您需要决定解决新样式违规问题的速度。

启动团队

如果没有用户流失政策,就没有针对导致用户流失的更改的正式要求或预期。本部分增加了此类更改作者的责任。

如果您的团队要发起变更并将完成全部工作:

  1. FEC 发送邮件,说明对其他团队的影响最小。
  2. 向 announce@fuchsia.dev 发送电子邮件,向参与者通知迁移事宜。
  3. 继续迁移。

如果您的团队发起的更改需要其他人完成大量工作(包括由 RFC 发起的更改),请执行以下操作:

  1. 创建一个方案,向 FEC 证明您的团队将花费至少 80% 无法通过自动化技术处理的手动工作。方案必须包含受影响团队的列表以及更改的估算费用。
  2. FEC 批准您的方案后,通知受影响的团队。他们必须能够至少在两个季度内使用季度规划来安排工作,因此在季度开始前超过一周通知团队。
  3. 继续迁移。

向后兼容性

此政策不会影响任何活跃迁移。

文档

为帮助更改人员,我们在 fuchsia.dev 上提供了迁移计划示例。

缺点、替代方案和未知情况

这种方案的主要缺点是,需要在流程开始时参与 FEC。请务必让 FEC 和受影响的贡献者及时回复。

有一项替代政策要求受影响的贡献者批准更改。 这样做的好处是始终允许更改作者推进。我们忽略了此替代方案,因为它让受影响的贡献者有机会针对提议的更改的价值和危害提供反馈。

另一种替代方案是更为严格的方法,其中所有迁移都必须使用可用的版本控制机制进行软转换,并以较慢的速度将工作分散到所有 Fuchsia 贡献者。这与所提议的政策不同,它不为受影响的团队设定任何互动预期。此替代方案被忽略了,因为它在审核时间轴上没有限制,使启动团队很难规划和及时完成进度。

早期技术和参考资料

在阅读此提案时,是否可以提供一些相关的背景资料?例如,其他操作系统是否解决了此提案解决的相同问题?