项目选择

有许多开源项目，但最有成效的是调查那些在几个关键指标上与 CPython 足够相似的项目：

1. 贡献者的数量及其活跃度（存在规模问题，使得非常小项目的治理模式对我们的目的而言不太有启发性）；
2. 主要或部分由社区驱动（公司驱动的项目可以采用不同的治理方案，因为公司层级对主要参与者拥有权力）；
3. 面临需要某种正式决策流程的重要设计决策。

关键人物及其职能

在 Rust 项目中，有团队负责特定领域。对于语言特性，有“语言团队”；对于工具，有“开发工具”和“Cargo”等。有争议的问题由协调者推动讨论，协调者通常不是决策者。通常，协调者是提议变更的作者（参见下面的“争议决策流程”）。他们确保所有关键决策者以及感兴趣的社区成员都参与其中。他们通过迭代推动达成一致结果。

在实践中，这意味着决策很少会升级到核心团队。

贡献者最常见的角色是团队成员。没有团队成员身份的 issue 分类/代码审查权限很少见。贡献者拥有完整的提交权限，代码所有权分离基于信任。不鼓励直接向编译器仓库写入，所有更改都通过拉取请求进行，并在审查和批准后由集成机器人合并。

新团队成员由现有团队成员提名加入。

常规决策流程

主要工作通过 GitHub issues 和拉取请求进行。任何团队成员批准拉取请求后，即可合并，无需进一步流程。所有合并的拉取请求都将进入 Rust 的下一个稳定版本。

通过 @提及相关人员非常重要。收听所有 GitHub 活动的邮件洪流并不受欢迎。

在 IRC 和 Discord 上有对公众开放的规划和分类会议。它们不太受欢迎，因为大部分工作都是通过 GitHub 进行的。讨论也在官方 Rust 论坛上进行（https://users.rust-lang.org/ 和 https://internals.rust-lang.org/）。有一个专门的审核团队负责记录笔记并执行 行为准则。

争议决策流程

较大或有争议的工作通过 RFC 流程进行。它允许每个人表达自己的想法，并通过迭代达成解决方案。当相关团队成员的所有阻塞性顾虑都得到解决后，他们会签署 RFC，然后进入“最终评论期”。这不需要所有参与者达成共识，而是不应存在强烈反对提议的共识。

10 天后，除非团队成员提出任何新的阻塞性顾虑，否则 RFC 将被 *合并*。“合并”表示现在可以不间断地进行实现该功能和集成的工作。RFC 不需要有参考实现才能被接受。

“最终评论期”的其他可能结果是：

• *推迟* RFC（类似于 PEP 中的“延迟”状态），
• 如果阻塞性顾虑可以解决，则 *重新讨论*，或者
• 如果阻塞性顾虑无法解决，则 *关闭*。当 RFC 被标记为 *关闭* 时，有 7 天的宽限期来辩论是否应该关闭。

实际上，最初经常对 RFC 提出担忧，但很少导致 RFC 被完全否决。

此流程对于争议较小和/或较小的更改非常适用。对于最大的争议性更改，讨论会变得难以控制。这是 Rust 团队目前（截至 2018 年 8 月）关注的一个话题（参见：“倾听与信任，第一部分”、“倾听与信任，第二部分”、“倾听与信任，第三部分”、“分阶段 RFC 流程提案”）。

规划新版本

每六周，Rust 编译器会发布包含当时所有内容的版本。目前还没有 LTS 通道或发布，但正在计划此概念，以使再分发者能更好地跟上开发。

每隔几年，会发布一个所谓的 “版本”。这些是里程碑式的发布，包含全套更新的文档和工具。它们可能与以前的版本不兼容。外部软件包在其 crate 元数据中选择加入破坏性更改。Rust 编译器支持其发布之前存在的所有版本。任何受支持版本之间的 crate 链接都是可能的。

流程随时间的变化

Rust 编程语言由 Graydon Hoare 启动，他将其作为个人项目开发了几年。当 Mozilla 开始赞助该项目时，团队逐渐壮大，Graydon 担任 BDFL 风格的人物。他于 2013 年 离开了项目。此后 Rust 在没有 BDFL 的情况下运行。RFC 流程后来才建立。最初，一些设计讨论在闭门周度视频会议中进行，该会议于 2015 年 5 月（Rust 1.0 发布之前）被 关闭，并自然地被开放讨论和团队的直接影响力所取代。

团队数量随着时间增长。核心团队做出的技术决策数量正在减少，取而代之的是将其委托给各自的团队。

引入“最终评论期”的概念是为了鼓励更多的公开讨论，并能够在 *即将* 发生的更改之前做出反应，而不是不得不撤销已经做出的仓促决定。

关键人物及其职能

OpenStack 社区由许多不同的 项目团队 组成，这些团队负责生产软件的不同组件（块存储管理、计算管理等）或管理社区遵循的流程的不同部分（例如跟踪发布计划）。每个团队都由一名 *项目团队负责人* (PTL) 领导，PTL 由该项目的 *活跃项目贡献者* 选举产生。

活跃项目贡献者 (APC) 是特定项目团队的近期贡献者。APC 身份正式要求两件事：成为 OpenStack 基金会的个人成员（成员资格免费），并且在过去一年（两个开发周期）内在项目团队管理的仓库中合并了一项更改。

当选的 PTL 任期为一个开发周期（大约 6 个月）。一个人担任 PTL 的连续任期没有限制，通常会连续担任几个任期。团队在一个周期内只有一名候选人自愿担任 PTL 的情况也很常见，在这种情况下，无需进行选举。

PTL 代表团队处理所有事务，除非他们明确委托了某些职责。例如，许多团队指定一名独立的 *发布联络员* 来管理开发周期的发布流程。在团队成员无法达成共识的情况下，PTL 也充当最终决策者。

虽然所有 APC 都会投票选举团队的 PTL，但在许多其他情况下，只有 *核心审阅者* 团队会被咨询团队的政策决策。任何人都可以审查任何 OpenStack 项目的任何补丁。当有人证明他们对项目的技术问题有很好的理解，在审查中提供有用的反馈，并理解项目的发展方向时，他们可能会被邀请成为核心审阅团队的成员。与许多其他社区不同，此身份并不授予他们在未经审查的情况下提交代码的权利。相反，它要求他们致力于审查其他贡献者编写的代码，并参与团队决策讨论。要求某人成为核心审阅团队的成员是信任的强烈体现。

技术委员会 (TC) 负责管理整个 OpenStack 的开发。技术委员会的 13 名成员由所有项目团队的 APC 直接选举产生。每位成员任期为两个开发周期（大约 1 年），选举分为两部分，以便任何时候只有大约一半的成员任期届满，以确保连续性。TC 制定总体政策，例如添加新项目团队的标准、Python 2 的弃用政策、测试要求等。

常规决策流程

所有 PTL 或 TC 成员的选举都使用 https://civs.cs.cornell.edu 运行 *孔多塞特* 选举。选择此系统是因为它强调共识候选人而非严格的受欢迎度。

OpenStack 贡献者社区主要依赖 3 个工具进行讨论：openstack-dev 邮件列表、位于 https://review.openstack.org 的 gerrit 代码审查实例，以及 Freenode 上的一组 OpenStack 专用 IRC 频道。有一些团队的贡献者主要在中国，他们难以访问 IRC。这些团队倾向于使用微信等替代平台。

用于讨论任何给定决策的工具将根据其权重和影响而异。鼓励每个人使用邮件列表或 gerrit 来支持跨更广泛时区和防火墙的异步讨论，特别是为了向社区其他成员公布最终决策。

仅限于单个团队的政策决策通常由项目的核心审阅团队做出，并且政策和决策流程可能因团队而异。有些小组将其团队政策写入其文档库，并使用代码审阅工具 (gerrit) 对其进行投票。有些团队在 IRC 上讨论政策，无论是临时性的还是在定期会议期间，并在那里做出决策。有些团队使用邮件列表进行这些讨论。团队的 PTL 负责确保讨论得到管理并传达结果（无论是直接执行还是确保将任务委托给其他人）。

所有团队政策决策都需要与技术委员会设定的总体政策兼容。由于 TC 倾向于做出适用于整个贡献者社区的更广泛的治理决策，因此讨论和投票这些决策的流程描述得更正式，包括指定通过所需的票数和讨论所需的最小时间长度。例如，大多数动议需要 1/3 的成员（5 名）通过，并且在收到足够票数通过后必须至少保持开放 3 天，以确保有时间登记异议。有关更多详细信息，请参阅 技术委员会章程 和 内部规定。

重要的设计决策通常通过审查 规范文档 来讨论，该文档有点类似于 PEP，涵盖了需求、替代方案和实现细节。从所有贡献者那里征求反馈意见，然后由项目的核心审阅团队成员最终批准或拒绝规范。有些团队只需要 2 名审阅者批准设计，而其他团队则需要在设计获得批准之前有更强的共识迹象。每个团队都设定了 每个开发周期内批准规范的截止日期，以鼓励贡献者尽早制定重要新功能的设计，并避免在周期后期因变更而产生的风险。

较小的技术决策通常通过审查实施更改所需的补丁来做出。任何人都可以审查任何补丁并提供技术反馈，但最终需要团队的两名核心审阅者批准大多数更改（对于诸如拼写错误等琐碎更改或解除 CI 门禁系统阻塞的修复通常会做出例外）。

争议决策流程

有争议的，或仅仅是复杂的决策，常常超出规范审查的范围，扩展到邮件列表讨论。它们也经常导致在定期举行的面对面社区聚会中进行讨论。由于社区的许多成员无法参加这些活动，因此会总结讨论，并尽可能使用在线工具做出最终决策。

PTL 负责决定何时就影响单个团队的决策达成共识，并在极少数情况下，如果未达成共识且绝对需要做出决策时，做出最终决定。TC 在团队 *之间* 的问题无法以其他方式解决的情况下，充当类似的最终决策小组。这种决策升级最终很少有必要，因为直接参与的贡献者通常更倾向于达成共识协议，而不是将决策升级给其他人。

规划新版本

OpenStack 大约每 6 个月发布一个主要版本。这些是基于日期的协调发布，其中包括所有成员项目在那个时间点完成的工作。有些项目团队比每 6 个月发布一次更频繁（对于构建其他团队使用的库的团队尤其如此）。这些较小的发布通常在有内容（新功能或错误修复）足以证明其合理性时产生。

每个开发周期的日程表，包括截止日期和最终发布日期，由发布管理团队与基金会工作人员协调提出（发布通常与面对面活动的日历保持一致），然后社区有机会在最终日期确定之前提供反馈。

每个开发周期的优先级决策在团队级别和 TC 级别做出。核心评审团队优先处理内部工作，例如修复错误和实现新功能。TC 选择 社区目标，这通常需要所有团队完成一定量的工作。在每个周期开始时就这些优先级达成一致有助于团队协调其工作，这尤其重要，因为实现将需要多个团队成员的评审。

流程随时间的变化

在过去的 8 年中，OpenStack 项目团队的数量从 2 个增长到 63 个。技术委员会的组成也随之变化，以适应这种增长。最初，TC 由 PTL 组成，但随着成员数量的增长，该小组有效运作变得不切实际。

社区也曾围绕“项目领域”而非项目团队进行组织。一个项目领域涵盖了一组功能，例如收集遥测数据或管理块存储。当多组人想使用不同的解决方案处理同一组功能时，这种组织方式失败了。围绕所交付的代码组织团队，允许不同的团队对相同的需求有不同的解释。例如，现在有几个团队致力于不同的部署工具。

关键人物及其职能

Jupyter 治理中的关键人物是 BDFL Fernando Perez 和指导委员会。贡献者可以获得核心贡献者的特殊身份。有些人也可能是机构贡献者，他们是在机构合作伙伴处履行官方职责而为项目做出贡献的个人。

项目创始人 Fernando Perez 是现任也是第一任 BDFL。BDFL 可以任职至其意愿。BDFL 的 继任计划 在主要治理文档中有所描述。总而言之，BDFL 可以任命下一任 BDFL。作为一项礼节，BDFL 预计将咨询指导委员会。如果 BDFL 无法任命继任者，指导委员会将推荐一人。

核心贡献者是被授予权利的个人，例如提交权限，以便在他们的专业领域或 子项目 中以项目的最佳利益行事。现有核心贡献者通常通过从项目负责人（经验丰富的核心贡献者，如项目仓库的 README 中所列）那里获得共识来推荐某人获得核心贡献者权利。

要被推荐并邀请成为指导委员会成员，个人必须是项目贡献者，其贡献在质量和数量上都很可观，并且持续至少一年。潜在的委员会成员由现有委员会成员提名，并在询问潜在成员是否有兴趣并愿意担任该职位后由现有委员会投票决定。

常规决策流程

Project Jupyter 由许多 GitHub 组织和这些组织内的子项目组成。主要工作通过 GitHub issues 和拉取请求进行。任何团队成员批准拉取请求后，即可合并，无需进一步流程。所有合并的拉取请求都将进入子项目的下一个稳定版本。

每周举行一次公开的项目范围会议，并录制后发布到 YouTube。一些较大的 GitHub 组织，例如 JupyterLab 和 JupyterHub，作为 Project Jupyter 的子项目，可能会每周或每月举行额外的公开团队会议。讨论发生在 Gitter、Jupyter 邮件列表上，最常见的是在 GitHub 上的开放 issue 和/或拉取请求中。

争议决策流程

Project Jupyter 治理的基础是

• 开放与透明
• 积极贡献
• 机构中立性

在日常项目活动中，指导委员会成员与其他所有贡献者和社区成员一起，以平等的身份参与所有讨论、代码审查和其他项目活动。在这些日常活动中，委员会成员不因其委员会成员身份而拥有任何特殊权力或特权。然而，由于其贡献的质量和数量以及对项目软件和服务的专业知识，预计委员会成员将向可能经验较少的贡献者提供有益的指导，无论是在技术方面还是在项目方向方面。

对于有争议的问题，贡献者社区会共同完善潜在解决方案，必要时进行迭代，并通过建设性地、公开地分享信息和观点来建立共识。当常规社区讨论无法在合理时间内就某个问题达成共识时，指导委员会可以做出决定。

投票

技术决策很少进行投票，如果发生，也极其罕见。

对于其他项目问题，指导委员会可以通过治理 PR 或电子邮件提案发起投票。接受需要至少 80% 的指导委员会投票，并且至少 2/3 的票数为正面。

BDFL 可以独自接受或拒绝更改，或推翻指导委员会的决定；尽管这将是极其罕见的事件。作为仁慈的 BDFL，在实践中，BDFL 选择将该权力委托给社区讨论渠道和指导委员会的共识。

规划发布

由于 Project Jupyter 拥有许多项目，而不仅仅是一个单一项目，因此发布计划主要由项目的核心贡献者驱动。

流程随时间的变化

该流程一直保持一致，并且这种方法对我们很有帮助。展望未来，项目领导层将由 BDFL 和指导委员会组成。这种治理模式是对项目现有做法（在 2015 年指导委员会通过主治理文档之前）的正式化，而不是方向的改变。

关键人物及其职能

该项目认可三种贡献者：核心团队成员、技术委员会和 Fellows。常规核心提交者不再行使他们的“提交权限”，而是依赖拉取请求被审查和接受。技术委员会指导技术选择。Fellows 是受雇承包商，负责分类新工单，审查和合并来自提交者和社区的补丁，包括非琐碎的补丁。

核心团队成员通过核心团队内部的提名和投票添加，技术委员会拥有否决权（至今尚未行使）。技术委员会每 18 个月（每个主要的 Django 版本）由核心团队成员选举产生。核心团队内的子团队根据兴趣自行选择。

常规决策流程

大多数日常决策由 Fellows 和其他活跃的核心团队成员做出。

核心团队投票决定新成员，这需要 4/5 的投票多数，无法定人数要求。技术委员会拥有否决权。此权力从未行使过。

争议决策流程

技术委员会偶尔会批准 Django 增强提案 (DEP)，但这种情况很少见。DEP 流程大致模仿 PEP，并记录在 DEP 1 中。DEP 主要用于设计主要新功能，但也用于提供一般准则和流程的信息。

DEP 的想法应首先在 django-developers 邮件列表上公开验证。粗略验证后，作者组建一个包含三个角色的团队：

• *作者* 负责编写 DEP 并指导讨论；
• *实施者* 负责准备 DEP 的实施；
• *牧羊人* 是一名核心开发者，将是 DEP 的主要审阅者。

DEP 草案提交后，被分配一个编号并进行讨论。作者收集反馈并根据需要引导讨论。为避免无休止的开放式讨论，建议的场所包括：独立的邮件列表、维基页面、在 DEP 的拉取请求上工作。

反馈轮结束后，牧羊人要求技术委员会进行审查和宣布。委员会可以作为一个团队对 DEP 进行裁决，或者指定一名成员进行审查和决定。

在任何无法达成共识的情况下，技术委员会拥有最终决定权。这从未行使过。

规划新版本

发布按照固定的时间表进行，每 18 个月发布一个主要版本。由带薪的 Fellows 确保必要的工作完成，按时发布是常规操作。

流程随时间的变化

Django 最初有两位 BDFL：Jacob Kaplan-Moss 和 Adrian Holovaty。他们在项目历史的第九年退休了（Adrian 的帖子，Jacob 的帖子）。在他们卸任后，DEP 流程被定义。

关键人物及其职能

Microsoft 设有一个正式的设计团队和发布管理团队。该项目的主要负责人目前是 Anders Hejlsberg，因为一些最初的团队成员已离开公司。

常规决策流程

该项目开发方微软拥有强大的规划文化，因此开发路线图会提前很长时间发布，在微软举行的设计讨论记录会迅速公布，会议有时还会通过 Skype 进行直播。

鼓励通过 GitHub 上的拉取请求进行外部贡献。通过 GitHub 上的 issue 提出新用例或功能的建议。这就像一个临时的类似 PEP 的过程。社交媒体（Twitter）上也有一些讨论。

争议决策流程

Hejlsberg 是该项目的核心人物，负责语言设计，将社区需求整合为一个有凝聚力的整体。目前没有正式流程允许外部人员参与语言设计。

TypeScript 团队筛选并整合社区建议。这种设置的主要优点是设计强大且一致，具有可靠的调度和执行。虽然意图和计划是透明的，但这种模型的缺点是社区参与仅限于拉取请求和建议。

规划新版本

微软决定发布时间表，提前沟通发布日期和功能。夜间构建通常是稳定的（相当一部分用户使用这种发布形式）。

版本化发布每 1-3 个月进行一次，路线图可在 GitHub 上查看。

流程随时间的变化

TypeScript 可能是微软第一个完全公开开发（而非源代码可用）的知名项目。

微软将 TypeScript 开源是该项目从一开始就计划的功能。在首次公开发布之前，该语言完全由原始团队和早期内部用户识别的需求驱动。最初的开源是通过现已停用的 Microsoft CodePlex 平台进行的。它没有明确的接受外部贡献的常规流程。项目迁移后，社区参与度显著提高。

关键人物及其职能

Astropy 项目团队的职责分布在许多不同的角色中[1]，尽管一个人通常会身兼数职。

监督 Astropy 项目的主要机构是 Astropy *协调委员会* (CoCo)。其主要职责是处理任何财务问题，批准希望加入 Astropy 项目的新软件包，批准或拒绝 *Astropy 增强提案* (APE)[2]，以及通常是任何“领导力”导向或时间敏感的事项。截至撰写本文时，该委员会由四名成员组成，并可能随着委员会需求的变化而增减。

常规决策流程

争议决策流程

较为简单的争议性决策通常在 astropy-dev 邮件列表 [3] 上进行讨论，经过合理时间后，要么达成明确的共识/妥协（这种情况居多），要么 CoCo 做出决策以避免停滞。

更复杂的决策遵循 APE 流程，该流程仿照 PEP 流程。在此，CoCo 在开放给所有人的讨论期结束后做出最终决定。通常，CoCo 会遵循共识或多数意见。

规划新版本

主要发布时间是固定的（每 6 个月一次）；届时所有内容都会包含在内。

流程随时间的变化

CoCo 和“开放开发”的理念源于项目最初，经过对感兴趣的 Python 天文学家和相关软件工程师的一系列投票后确立。最初讨论的核心成果体现在《Astropy 愿景》文档 [4] 中。

正式角色的存在以及上述大部分内容都是随着社区规模的扩大而逐步演变而来的，每个演变都遵循 APE 流程，或者是在 astropy-dev [3] 中提出提案进行讨论和投票的常规流程。总的来说，所有这些演变都是对已存在实践的某种追认，只有在实践中得到检验后才被正式采纳。

自我评价

任何有时间的人都可以介入并提出建议（通常通过 PR）或投票选择他们的偏好，这导致了“我们都在一起”的感觉，从而带来了更好的协调工作。

此外，CoCo 主要作为打破僵局的机构，这意味着没有独裁者强加其意志的感觉，同时仍为那些对完全民主治理模式持谨慎态度的外部组织提供了明确的联系点。

参考资料

关键人物及其职能

微软有一个最终向 CEO 汇报的层级结构。CEO 之下有许多组织，其中一些专注于工程项目（与销售、市场营销或其他职能部门相对）。这些工程组织大致分为重要的产品家族——例如，曾经有一个“Windows 组”、“Xbox 组”和一个“服务器和工具组”。这些通常由 *执行副总裁* (EVP) 领导，他们向 CEO 汇报。

每位执行副总裁 (EVP) 之下都有许多 *公司副总裁* (CVP)，每位 CVP 负责一个或多个产品。这个层级对本 PEP 的目的而言变得相关——CEO 和 EVP 很少参与大多数决策流程，但他们设定了 CVP 做出决策的方向。

CVP 下的每个产品都设有一个团队，由 *项目经理* (PM) 和 *工程经理* 组成。工程经理带领的工程师团队大多不参与决策，尽管在某些情况下可能会作为专家被利用。在本节的其余部分，*工程* 指的是工程团队中专注于技术贡献的任何人，*PM* 指的是项目管理团队中专注于客户贡献的任何人。做出决策后，工程部门进行实施和测试工作，PM 部门与用户验证他们的问题是否已解决。

（这实际上是一个巨大的简化，以至于这些角色中的一些人对此描述感到冒犯。实际上，大多数 PM 或工程人员的工作都跨越了这两个角色之间的界限，因此它们应该被视为描述某人在当下正在做的工作的术语，而不是个人标识符或限制。）

团队通常代表一个特性，而 CVP 代表一个产品。例如，Visual Studio Code 有一个 CVP 负责该产品及其整体方向（在他们的 EVP 设定的背景下）的最终决策。但许多团队为 Visual Studio Code 贡献特性。

为了完全清晰，CEO、EVP 和 CVP 从不直接修改源代码。他们全部的角色是为直接下属提供指导，并对有争议的决策进行裁决。

常规决策流程

对外部用户不可见的产品代码更改仅由工程部门进行。个别工程师将由指定的工程经理分配任务，或者可以自行分配任务。晋升到越来越高级别的职位通常反映了对个人决策能力的信任，更资深的工程师被信任在团队其他成员的较少验证下做出决策。大多数错误都属于此流程（即，在不改变预期体验的情况下修复用户可见的问题是工程部门的决策）。

影响特定功能用户的决策由该功能的 PM 团队制定。他们将使用所有可用的数据源来识别问题，试验替代方案，并最终准备一份设计文档。PM 和工程部门的高级成员将审查设计以澄清细节，最终形成一个功能团队达成一致的工件。工程部门将使用此工件来实施工作，PM 部门随后将使用此工件来验证原始问题是否已解决。

功能团队的资深工程和 PM 团队成员应本着 CVP 设定的方向做出决策。团队定期与 CVP 开会，讨论最近的决策并确保一致性。与 CVP 期望不明显一致的决策将升级到争议流程。

争议决策流程

当决策需要跨团队协调，或者与之前的 CVP 指导不明显一致时，团队将升级决策。这些通常包括涉及改变方向、尝试触达新的或不同的用户群体、弃用和删除重要功能（或在短时间内）、或需要快速发布的更改的决策。

通常，CVP 并不熟悉功能团队工作的所有方面。因此，功能团队必须提供建议和足够的决策背景，以便 CVP 可以在 *无需额外知识* 的情况下做出决定。大多数情况下，首次尝试会导致 CVP 提出一系列问题，团队将研究、回答这些问题，并尝试在稍后日期再次做出决定。

CVP 经常提出的问题有：

• 此决策会影响多少用户？
• 将对现有用户的影响降至最低的计划是什么？
• 如何将更改“销售”/描述给潜在用户？

CVP 应该对整个领域有深刻的理解，以便他们可以自行评估一些问题，例如：

• 微软内部其他项目做出了哪些类似决策？
• 哪些其他项目有计划可能影响此决策？
• 微软外部的项目做出了哪些类似决策？
• 用户需要它吗？
• 这与他们的 EVP 设定的方向一致吗？

CVP 做出的决策通常是武断和最终的，尽管他们通常会提供其理由。

规划新版本

发布涉及协调多个功能团队，因此很少会尝试包含所有团队的意见。发布计划将根据更广泛的生态系统需求确定，例如计划的活动/会议或利用媒体关注的机会。

团队会被告知发布日期和发布主题，并根据上述决策流程制定自己的计划。更改发布日期被视为有争议的决策。