挑戰：沒有第二個 Guido

沒有第二個人擁有像 Guido van Rossum 那樣獨特的技能組合。這樣的人需要具備技術、溝通和組織經驗，才能成功領導專案。具體來說，這個人需要：

• 為專案設定並闡明一個具凝聚力的長期願景；
• 對執行時期、標準函式庫以及更廣泛的第三方函式庫背景具有深厚的技術理解；
• 以所有相關方都能接受的方式協商和解決爭議問題；
• 擁有閒暇時間，並具備足夠的精力來維持多年持續的參與。

風險：惡意終身獨裁者

如果我們找到的人不像我們的第一位獨裁者那樣適合這個職位，會怎麼樣？在這種情況下，可能會導致嚴重的後果。

獨裁者可能因為缺乏技術深度、「勢均力敵」的選舉、願景不一致、處理衝突能力差或倦怠等原因，而無法獲得足夠的信任。如果獨裁者以特定方式做出爭議性決策，缺乏足夠信任的獨裁者可能會導致專案內部的分裂。

獨裁者的設置會引發針對單一人物的遊說。除非該人物因財富、健康和穩定的生活狀況而免受影響，否則這會帶來惡意行為者在幕後操縱專案的風險。

最後，來自社群特定部分的獨裁者，可能會更重視該特定使用者群體的需求和利益，從而疏遠其他使用者。

觀察：我們實際上並不需要獨裁者

獨裁者模型的諷刺之處在於它需要選舉。更妙的是，我們甚至需要透過選舉來決定要使用哪種治理模型。

如果我們已經能夠透過社群流程解決兩個如此嚴重的問題，那為何不繼續將其用於所有後續的決策呢？

風險：模糊提案所帶來的朦朧美好感受

最後一件值得一提的事情是，當建議採用 BDFL 模型時，如果不明確指出 BDFL 應該是誰，就很容易規避上述批評。這樣一來，抱有希望的讀者可以將他們最好的期望和需求投射到抽象的 BDFL 身上，使這個想法看起來更具吸引力。這是一個錯誤。

如果在模型提案中不點名 BDFL，我們就不是在談論一個具體的模型。我們可以避免提出和回答這些棘手的問題。我們可以想像我們最理想的情況，一個我們希望擔任這個職位的候選人。

省略 BDFL 的名字也會使社群模型處於不公平的劣勢。我們已經了解我們的核心開發者群體中好的、壞的和醜陋的層面。它不是柏拉圖式的理想，也不是沒有摩擦的完美球體。事實上，我們預期會有很多摩擦和不完美之處。

因此，親愛的讀者，為了公平評估 BDFL 模型提案，您應該想像我們團隊中最糟糕的人擔任那個 BDFL。一個具體的人。想像那是我。

結論 雖然這曾是我們的歷史，但沒有 Guido，此模型無法在未來為語言的最佳利益服務。

風險：稀釋與混淆

此模型偏好一個小群體，介於三到五人之間。這樣一來，它與獨裁者模型的大部分批評相同，只是影響被放大。擁有不止一人，比如說三個人身居權位，會稀釋責任，同時仍帶來遊說、信任不足或疏遠社群部分成員的高度風險。

風險：內部衝突

此外，讓多人分擔治理責任，會為內部衝突、專案長期願景不一致創造充足的機會，並使其成員所需的持續時間投入倍增（如果他們因其他時間承諾而無法「達到法定人數」，那就不算法定人數委員會）。

就像面對一個沒有摩擦的球形 BDFL 一樣，在沒有考慮如果該委員會由三個您認為不適合該職位的人組成時，它會如何運作的情況下，就駁回委員會的想法。想像一下如果我有兩個朋友。

最重要的是，就像獨裁者一樣，我們不需要委員會。當我們成立委員會時，我們已經進行了兩次成功的選舉。為什麼不繼續投票呢？

結論 此模型與獨裁者模型有相似的風險，而且更糟。

核心團隊

Python 專案由核心開發者團隊開發。雖然成員資格由 GitHub 上「python」組織中「Python core」團隊的存在決定，但貢獻有許多形式：

• 向程式碼庫提交變更；
• 審查他人提交的拉取請求；
• 在問題追蹤器上分類錯誤報告；
• 在官方 Python 溝通管道上討論議題。

有些貢獻者可能被視為休眠狀態，換句話說，他們沒有為 CPython 最近兩個版本做出貢獻。任何休眠貢獻者都可以隨時恢復貢獻。

專家

《Python 開發者指南》列出了許多感興趣的領域，以及被公認為該領域專家的核心開發者姓名。專家或專家小組有以下職責：

• 及時回應已分類至特定感興趣領域的問題追蹤器上的問題；
• 及時審查被識別為屬於特定感興趣領域的拉取請求；
• 監督特定感興趣領域演進中的整體設計一致性。

核心開發者可以自行決定分配和取消分配至特定的感興趣領域。已列出的該感興趣領域的現有專家必須被告知此變更，並須一致同意。

如果特定感興趣領域列出了多位專家，他們將在核心團隊內組成一個小組。他們共同負責該感興趣領域。

核心開發者應避免同時擔任過多感興趣領域的專家成員。本文檔特意沒有指定最大數量，它只是表明過度勞累會導致倦怠，並對專案在沒有特定貢獻者的情況下運作的能力構成風險。

管理員

有一個群體，其中一些人並非核心開發者，負責確保官方溝通管道上的討論遵守行為準則。他們會針對違規行為採取行動。

PEP，加強版

PEP 流程在PEP 1 中已有的資訊基礎上，增加了以下變更和澄清：

• PEP 在最終決策做出之前不會合併；在那之前，它們在 GitHub 上是開放的拉取請求；
  • 為了使審查更容易，所有對正在審查的 PEP 的變更都應作為獨立的提交進行，以允許進行細粒度比較；
• 提交的 PEP 需要指明感興趣的領域和相關專家，作為最終決策的實體；
• 如果 PEP 作者是相關感興趣領域的專家之一，他們必須指定該領域之外的另一人來代替他們參與最終決策；
• PEP 作者負責使用官方溝通管道收集和整合關於 PEP 的回饋意見，目標是建立共識；
• 所有社群成員都必須能夠提供回饋；
• 在某個時間點，其中一位具名專家會發布一份「總結評論」，闡述討論的現狀，特別是主要的分歧點和權衡；同時，該專家會提出「最終評論期動議」（FCP），並附帶建議的處置方式，可以是：
  • 接受；
  • 暫時接受；
  • 駁回；或
  • 延期 PEP。
• 要進入 FCP，PEP 必須由相關感興趣領域的所有專家簽署同意；
• FCP 持續十四個日曆日，以允許利害關係人在做出決定之前提出任何最終異議。

極具爭議的 PEP

如果核心貢獻者強烈反對某個特定的 PEP，在 FCP 期間，他們可以提出動議，透過投票駁回該 PEP。投票細節在下方「投票機制」中描述。

這應該是最後的手段，因此很少發生。它會使核心團隊分裂，對所有相關人員來說都是一個壓力很大的事件。然而，提交 PEP FCP 的專家應該對透過投票駁回動議的可能性有很好的判斷。在這種情況下，應注意避免過早提交 FCP。

對於相反的情況，即當專家想要駁回 PEP 但其他人希望其被接受時，則沒有追索權。這確保了相關專家對納入的內容擁有最終決定權。如果你真的想要那項變更，請想辦法說服他們。

官方溝通管道上的管理員首先強制執行行為準則，以確保所有相關方之間健康的互動。執行可能導致特定參與者被排除在進一步的討論之外，從而影響決策過程。

重新審視延期和被駁回的 PEP

如果一個 PEP 被延期或駁回，在再次嘗試相同想法之前，應首先聯繫相關專家。如果專家同意有充分證據證明重新審視該想法是合理的，則可以開啟一個編輯該延期或駁回的 PEP 的拉取請求。

未能事先獲得適當的專家支持，很可能會導致延期或駁回的 PEP 的拉取請求立即被拒絕。

提名新的核心開發者

一位倡導者透過在官方溝通管道上發布貼文，提名一個人成為新的核心開發者。隨後開啟投票。

如果任何現有的核心開發者對於被提名人獲得提交權限感到不適，他們最好在提名討論串中提出這個顧慮。如果沒有滿意的解決方案，他們可以投下反對票。

實際上，提名一個人成為核心開發者，常常會讓其他人感到驚訝，因為這個人還不是核心開發者。換句話說，這應該在候選人已經被他人充分認識和信任時進行。我們應該避免基於潛力進行提名。

不信任投票

• 將核心開發者從核心團隊中移除；
• 解散特定感興趣領域的專家團隊。

這些描述了核心開發者被強制從核心團隊中移除，或專家團隊被強制解散的情況。希望這些情況永遠不需要執行，但它們被明確提及是為了展示如何修復一個功能失調的感興趣領域。

如果核心開發者經投票被核心團隊移除，他們將失去與專案互動的能力。由管理員酌情決定是否移除他們在錯誤追蹤器和 GitHub 上發布內容的能力，或僅就他們未來的行為進行個案審查。

如果特定感興趣領域的專家團隊被解散，其他核心開發者可以隨意補足空缺。被解散的專家團隊成員不能自薦回歸。