摘要

本 PEP 提案延續單一技術專案領導者模式，委婉地稱作「終身仁慈獨裁者 (BDFL)」的 Python 治理模式，自本 PEP 起，將其稱作「恩典裁判決策官 (Gracious Umpire Influencing Decisions Officer, GUIDO)」。此名稱變更反映了 GUIDO 在與廣泛的開發社群協商後，作為 Python 語言決策過程的最終仲裁者，其角色視野的擴大；同時也體認到「終身」一詞，雖然可能是一種願景，但對於語言本身或 GUIDO 個人的福祉而言，不一定符合最佳利益。

本 PEP 說明

• 維持單一技術領導者模式的理由
• GUIDO 如何被遴選、選舉、留任、罷免及繼任的過程；
• GUIDO 在 Python 語言演進過程中的角色；
• 任期長度；
• GUIDO 與「Pythonista 委員會 (CoP)」的關係，該委員會就技術事務向 GUIDO 提供建議；
• CoP 的規模、選舉方式及角色；
• 決策委派流程；
• 為適應新治理模式而對 PEP 流程所做的任何變更；

本 PEP 並未指定新的 BDFL。如果此模式被採納，將與本 PEP 中描述的所有職位持有者姓名一同編入 PEP 13。

PEP 已拒絕

PEP 8010 已於 2018 年 12 月 17 日星期一，經由核心開發者投票否決，此投票過程詳見 PEP 8001。

PEP 8016 及其所描述的治理模式被選定取而代之。

開放討論點

在治理討論過程中，允許對本 PEP 的參數進行各種調整，例如 CoP 的確切規模、任期長度和投票程序。這些內容將在 PEP 準備好進行投票時被編纂成文。

本 PEP 中描述的投票程序和事件將預設採用 PEP 8001 中指定的投票方法，儘管該 PEP 在撰寫本文時仍在討論中，因此可能會有所變動。

隨著此模式經驗的累積，未來在任命 GUIDO 時，這些參數可能被允許甚至預期會進行調整，以提供更順暢的治理過程。

為何是單一技術領導者？

為何選擇此模式而非其他？歸根結底是「願景」。委員會設計有許多已知的缺點，導致語言根據當時貢獻者的不同興趣而累積新功能。一個著名的格言是「駱駝是委員會設計出來的馬」。一個由委員會設計的語言能否「協調一致」？它是否感覺像一種連貫、自洽的語言，規則合理且易於記憶？

單一技術領導者比委員會更能推動這一願景，無論該委員會規模是小（例如 3 或 5 人）還是涵蓋整個 Python 社群。每個參與者都會對「Python」是什麼有自己的願景，當這些個人願景發生衝突時，這可能導致猶豫不決或不合邏輯的選擇。CPython 應該快 3 倍，還是我們應該保留 C API？這是一個很難達成共識的問題，因為兩種選擇都沒有對錯。但比做出錯誤決定更糟的，可能是因為無法達成共識而接受現狀。

彈性

透過未充分說明（underspecification）的方式，賦予 GUIDO 和 CoP 不同程度的彈性。本 PEP 描述了衝突將如何解決，但期望所有參與者，包括核心開發者、社群成員和職位持有者，都能始終將 Python 及其使用者的最佳利益放在心上。本 PEP 假設相互尊重和最佳意圖將永遠促成共識，並且行為準則規範所有互動和討論。

GUIDO 的角色

GUIDO 最重要的角色之一是為 Python 語言的演進提供一個全面、廣泛、連貫的願景，涵蓋多個版本發布。這在決策具有持久影響和相互競爭的利益時尤為重要。例如，如果對 C API 進行向下不相容的更改導致 Python 效能提升兩倍，不同的社群成員很可能會在辯論的兩邊提出有說服力的論點，並且可能無法達成明確的共識。兩種選擇同樣有效。在諮詢 CoP 後，將由 GUIDO 的願景來引導最終決策。

GUIDO 是關於 PEPs 和其他問題（包括任何特定變更是否值得提出 PEP）決策的最終權威。如同現今的情況，許多——事實上或許是大多數——決策都是透過在問題追蹤器、合併請求和討論論壇上進行討論和解決，通常由特定領域的專家提供意見或領導。在這種操作程序運作良好的情況下，它可以保持不變。這也有助於減輕 CoP 和 GUIDO 的工作負擔，將最重要決策和最廣泛的局面視角留給中央權威。

同樣地，如果某項特定變更被認為需要一份 PEP，但 GUIDO 在與 CoP 協商後，確認有專家完全有能力做出最終決策，GUIDO 可以任命一位 PEP 代理人 (Delegate)。雖然 GUIDO 仍是最終權威，但預期 GUIDO 不會損害，事實上會支持代理人作為 PEP 最終仲裁者的權威。

當提案明顯違背 Python 的長期願景時，GUIDO 擁有完全的權力終止無效的討論、想法和提案。這樣做是對變革倡議者的同情，但同時也考慮到所有社群成員的健康和福祉。關於無果提案的有害討論對任何人都沒有好處，可以由命令終止。

總結來說：GUIDO 有權對任何主題，無論是技術性或非技術性，做出最終裁決，但治理 PEP 本身的變更除外。

權力來自社群

GUIDO 的權力最終歸屬於社群。一個失去大多數社群信任的 GUIDO 可以被罷免並重新進行投票。這是一個極其罕見且不太可能發生的事件。這是最壞情況下的足夠應急措施，因此不應輕易啟動。GUIDO 不應僅因為一項決定而害怕被罷免，即使該決定不受大多數 Python 開發者的青睞。罷免應保留給嚴重損害 Python 語言或社群的行為。

Pythonista 委員會（見下文）有責任發起不信任投票。

任期長度與任期限制

GUIDO 的任期應為三個 Python 版本，鑑於目前的發布頻率，約為 4.5 年。如果 Python 的發布頻率改變，GUIDO 的任期長度應調整為 4.5 年，並四捨五入到整數版本。如何進行四捨五入將留待潛在的發布頻率 PEP 決定。此後，將根據下文概述的程序舉行新的選舉。沒有任期限制，因此 GUIDO 可以隨心所欲地競選連任。

我們期望 GUIDO 能完成其整個任期，但人生總有意外。如果 GUIDO 需要在任期結束前辭職，空缺將按照下文概述的「遴選新 GUIDO」程序填補。然而，新的 GUIDO 只會任職到原 GUIDO 任期的剩餘時間，屆時將舉行新的選舉。辭職的 GUIDO 可以繼續任職，直到選出其接替者。

在過渡期間，CoP（見下文）可以履行 GUIDO 的職責，但他們也可能傾向於將實質性決策（例如技術 PEP 的批准）留給即將上任的 GUIDO。

遴選 GUIDO

每當 GUIDO 出現空缺，或在正常情況下 GUIDO 面臨連任時，就會啟動遴選程序。當遴選程序因 GUIDO 辭職，或在 GUIDO 常規任期結束前兩個月被觸發時，新的選舉程序便會開始。

投票前三週開放提名。候選人必須從目前的核心 Python 開發者名單中選出。非核心開發者沒有資格擔任 GUIDO。候選人可以自薦，但所有提名都必須有附議。提名和附議將以私有儲存庫上的合併請求形式進行。

一旦接受提名，被提名者可以使用相同的私有儲存庫發布簡短的立場聲明，也可以將其發布到提交者討論論壇。或許我們甚至會舉行辯論！選舉的這一階段持續兩週。

核心開發者隨後有三週時間進行投票，投票程序按照 PEP 8001 中所述。

Pythonista 委員會 (CoP)

協助 GUIDO 的是一個由經選舉產生的 Python 專家組成的小團隊。他們作為技術委員會成員之一。他們為 GUIDO 面臨的選擇提供見解和討論。諮詢可以由任何一方發起。例如，如果 GUIDO 對某個特定選擇仍猶豫不決，與 CoP 的討論可以幫助澄清剩餘問題，確定正確的問題，並提供對其他 Python 使用者影響的見解，這些是 GUIDO 可能不太熟悉的。CoP 是 GUIDO 值得信賴的顧問，預期雙方將建立密切的工作關係。

CoP 應由 3 名成員組成，從核心開發者中選出。他們的任期為 3 年，成員可以無限次競選連任。為確保連續性，CoP 成員以輪替方式選舉；每年有一名 CoP 成員面臨連任。

為在首次選舉中啟動交錯任期，得票最多的 CoP 成員將任職 3 年，得票第二多的將任職 2 年，而得票最少的 CoP 成員初期將任職 1 年。

所有投票平手的情況，將依照 PEP 8001 中待決定的程序處理。

提名和投票程序與 GUIDO 相同。包括為期三週的提名期（允許自薦，但必須有附議），隨後是發布立場聲明的一段時間，最後是投票。

經一致決議，CoP 可以對 GUIDO 啟動不信任投票，觸發該章節中的程序。

不信任投票

如上所述，CoP 可以透過一致決議，啟動對 GUIDO 的不信任投票。此程序不應輕易啟動，但一旦啟動，將觸發最多兩次投票。在這兩種情況下，投票都按照 PEP 8001 中的相同程序進行，所有核心開發者都可以參與不信任投票。

第一次投票是關於是否罷免現任 GUIDO。如果絕大多數 Python 開發者投票「不信任」，則 GUIDO 被罷免。然後進行第二次投票，以根據該職位持有者初始選拔程序選出新的 GUIDO。在沒有 GUIDO 的期間，重大決策將暫停，但正常的 Python 運作當然可以繼續。

日常運作

GUIDO 並非所有——甚至大多數——決策都需要。Python 開發者已經有很多委派、責任和自主決策的機會。問題追蹤器和拉取請求的功能與選擇此治理模式之前完全相同。大多數關於錯誤修復和次要改進的討論都可以在這些論壇上進行，就像過去一樣。

PEP 考量

GUIDO、CoP 成員以及 Python 社群中的任何其他人都可以提案 PEP。對潛在 PEP 的處理方式，無論 PEP 的作者是誰，都一視同仁。

然而，如果 GUIDO 撰寫 PEP，則應選出一位公正的 PEP 代理人 (Delegate)，並賦予其接受或拒絕該 PEP 的權力。GUIDO 應迴避決策過程。對於沒有明確共識的爭議性 PEP，由 GUIDO 撰寫的 PEP 的最終權力歸 CoP 所有。

PEP 提案進一步強化，規定必須始終選擇一名核心開發者作為 PEP 牧羊人 (PEP Shepherd)。此人確保遵循適當程序。牧羊人必須從核心開發者中選出。這意味著，雖然任何人都可以撰寫 PEP，但所有 PEP 都必須至少獲得一名核心開發者的某種程度贊助。

版本歷史

版本 2

• 更名為「技術領導者治理模式」
• 「單一領導者」->「單一技術領導者」
• 在 PEP 8001 獲得批准之前，其投票程序的採用是暫定的
• 描述 GUIDO 辭職後的情況
• 罷免投票需要核心開發者的絕大多數才能成功

版權

此文件已歸入公有領域 (public domain)。