專案選擇

有許多開源專案，但最有成效的是調查那些在幾個關鍵指標上與 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 做出的決策通常是武斷和最終的，儘管他們通常會提供其理由。

規劃新版本

釋出涉及協調多個功能團隊，因此很少會嘗試包含所有團隊的意見。釋出計劃將根據更廣泛的生態系統需求確定，例如計劃的活動/會議或利用媒體關注的機會。

團隊會被告知釋出日期和釋出主題，並根據上述決策流程制定自己的計劃。更改釋出日期被視為有爭議的決策。