项目选择

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

1. 贡献者数量及其活动（对于我们的目的来说，非常小项目的治理模式没有提供多少启发，因为存在扩展问题）；
2. 主要是或部分由社区驱动（由公司驱动的项目可以负担不同的治理方案，因为公司层级对主要参与者有权力）；
3. 面临需要某种正式决策流程的重要设计决策。

关键人物及其职能

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

实际上，这意味着很少将决策升级到核心团队。

贡献者最常见的角色是团队成员。没有团队成员身份的问题分类/代码审查权限很少见。贡献者拥有完整的提交权限，代码所有权分离基于信任。不建议写入编译器存储库，所有变更都通过拉取请求，并在经过审查和批准后由集成机器人合并。

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

常规决策流程

主要工作通过 GitHub 问题和拉取请求进行。任何团队成员批准拉取请求都可以将其合并，无需进一步流程。所有合并的拉取请求都将包含在 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 通道或版本，但计划在未来实现这一概念，以帮助重新分发者更好地跟上开发进度。

每隔几年就会发布一个所谓的 “版本”。这些是里程碑版本，包含完整的更新文档和工具集。它们可能与以前的版本不兼容。外部包选择在它们的板条箱元数据中进行破坏性更改。Rust 编译器支持其发布之前的所有版本。任何支持的版本之间的板条箱链接都是可能的。

流程随时间的变化

Rust 编程语言是由 Graydon Hoare 开始的，他在几年内将其作为个人项目进行开发。当 Mozilla 开始赞助该项目时，团队慢慢发展壮大，Graydon 成为一个类似 BDFL 的角色。他于 2013 年 离开了项目。Rust 从那以后没有 BDFL 了。RFC 流程是在后来才建立的。最初，一些设计讨论发生在封闭的每周视频会议中，该会议在 2015 年 5 月（Rust 1.0 发布之前）被关闭，并由公开讨论和团队的直接影响有机地取代。

团队数量随着时间的推移而增长。核心团队做出的技术决策数量正在减少，而是将这些决策委派给各自的团队。

引入“最终评论阶段”的概念是为了鼓励更多公开讨论，并让人们能够对即将发生的变更做出反应，而不是不得不撤销已经做出的仓促决定。

关键人物及其职能

OpenStack 社区由许多不同的 项目团队 组成，负责生产软件的不同组件（块存储管理、计算管理等）或管理社区遵循的流程的不同部分（例如跟踪发布计划）。每个团队都由项目团队负责人 (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 进行Condorcet选举。选择此系统是因为它强调共识候选人而非严格的流行度。

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 中列出的经验丰富的核心贡献者）那里征求共识来推荐某人获得核心贡献者权利。

要被推荐并被邀请作为指导委员会成员，个人必须是项目贡献者，并且在至少一年的时间里，其贡献质量和数量都非常大。潜在的委员会成员由现有的委员会成员提名，并在询问潜在成员是否有兴趣并愿意担任该职务后，由现有的委员会进行投票。

常规决策流程

Jupyter 项目由这些组织中的一系列 GitHub 组织和子项目组成。主要工作通过 GitHub 问题和拉取请求进行。任何团队成员批准拉取请求都允许将其合并，无需进一步的流程。所有合并的拉取请求最终都会出现在子项目的下一个稳定版本中。

每周都会举行一次公开的项目级会议，会议会被录制并在 YouTube 上发布。一些较大的 GitHub 组织（Jupyter 项目的子项目，例如 JupyterLab 和 JupyterHub）可能每周或每月举行额外的公开团队会议。讨论发生在 Gitter、Jupyter 邮件列表上，以及最常发生的 GitHub 上的公开问题和/或拉取请求上。

有争议的决策流程

Jupyter 项目治理的基础是

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

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

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

投票

对于技术决策，很少（如果有的话）进行投票。

对于其他项目问题，指导委员会可以通过治理 PR 或电子邮件提案呼吁进行投票以做出决定。通过需要至少 80% 的指导委员会成员投票，并且至少 2/3 的投票必须是正面的。

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

规划版本

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

流程随时间的变化

该流程随着时间的推移保持一致，这种方法为我们服务良好。展望未来，项目领导将由 BDFL 和指导委员会组成。这种治理模式是对项目正在做的事情的正式化（在 2015 年指导委员会采用主要治理文件之前），而不是改变方向。

关键人物及其职能

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

核心团队成员通过核心团队内部的提名和投票加入，技术委员会拥有否决权（迄今为止尚未行使）。技术委员会每 18 个月（每发布一次主要 Django 版本）由核心团队成员选举产生，并从核心团队成员中选举产生。核心团队内部的小组由兴趣自行选择。

常规决策流程

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

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

有争议的决策流程

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

DEP 的想法应该首先在 django-developers 邮件列表中公开审查。在它被粗略验证后，作者将组成一个团队，其中包含三个角色。

• 作者负责编写 DEP 并引导讨论；
• 实现者负责准备 DEP 的实现；
• 负责人是核心开发人员，将成为 DEP 的主要审阅者。

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

反馈回合结束后，负责人会要求技术委员会进行审查并宣布。委员会可以作为一个团队对 DEP 进行裁决，也可以指定一名成员进行审查并决定。

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

规划新版本

发布按照固定的时间表进行，每 18 个月发布一个主要版本。有了付费成员来确保必要的任务完成，按时发布是例行公事。

流程随时间的变化

Django 最初有两个 BDFL：Jacob Kaplan-Moss 和 Adrian Holovaty。他们在项目发展 9 年后退休了（Adrian 的帖子，Jacob 的帖子）。在他们辞职后，DEP 流程被定义。

关键人物及其职能

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

常规决策流程

微软是该项目开发的地方，它拥有强大的计划文化，因此开发路线图会提前发布，微软举行的设计讨论记录会迅速公布，会议有时会通过 Skype 广播。

通过 GitHub 上的拉取请求鼓励外部贡献。通过 GitHub 上的问题提出新的用例或功能的建议。这就像一个临时 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），每个人负责一个或多个产品。这个层级对于本 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 做出的决策通常是任意且最终的，尽管他们通常会提供其理由。

规划新版本

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

团队会收到发布日期、发布主题的通知，并在上述决策过程后制定自己的计划。更改发布日期被认为是有争议的决定。