在7月時,Python之父Guido van Rossum由於疲於處理社群爭議,決定卸下仁慈的獨裁者(Benevolent Dictator For Life,BDFL)位子,而經過社群熱烈討論與票選後,接受了PEP 8016指導委員會(Steering Council Model)的提案,以填補Python社群決策角色空缺。

為了解決Python PEP 572指派表示式(Assignment Expressions)提案的爭議,在社群討論還未到一個階段時,Guido van Rossum獨裁的做出決定,逕行決定接受PEP 572,而這項決定引來了社群內大批反對者的攻擊,Guido van Rossum在身心俱疲的情況,對社群發出公開信,表示將從BDFL的位子卸任,且不會指定BDFL的繼任者,他要社群透過提案的方式,決定Python重要事務的決策方法。

而之後總共出現了7項治理模型的PEPs(Python Enhancement Proposals),投票已經在12月16日結束,最後被接受的提案為PEP 8016指導委員會模型。PEP 8016和大多數提案一樣,核心都是創立一個委員會,但訂定的委員會規模不同,PEP 8016的指導委員會由核心團隊選出的5人組成。而其定義的核心團隊與現行的核心開發人員或提交者不同,該PEP明確指出除了開發者之外,其他角色也能獲得核心團隊的資格,只需要現有成員的三分之二多數票就能成為團隊成員,而且委員會無否決權。

PEP中沒有明確定義委員會否決權,而這是在提案中有被討論到的問題,核心開發者Nathaniel J. Smith認為,這個想法來自Django治理文件,而這對該PEP產生了重大影響。社群希望否決權永遠不會被使用,但是在必要的情況,當有需要移除不適任的核心團隊成員,超過四分之一的委員會成員投票同意就能執行。

PEP 8016委員會的設置任務重點,便是維護Python專案的品質以及CPython的實作,確保社群可以容易的對專案進行貢獻。指導委員會模式賦予委員會廣泛的決策權力,但同時又希望委員會盡可能不使用該權利,而是進行廣泛地授權,積極尋求共識而非下指令,並且能定義一個標準的PEP決策過程,希望不需要透過委員會投票決定,委員會應該成為最終上訴的組織。委員會不能改變治理PEP,只有核心團隊三分之二投票同意才能進行。

指導委員會的服務時間以一個功能版本發布為周期,每次版本發布後進行改選,候選人由核心團隊成員提名,每個核心團隊成員可以匿名投票給0到5名候選人,總票數最高的5人成為指導委員會成員。PEP也規範了利益迴避原則,以避免委員會遭企業控制,委員會中不能有2個以上的成員來自同一企業,該情況如在委員會任期中發生,則必須有足夠人數的成員辭職以符合規定。

大多數參與票選的治理模型PEP的核心思想都很相似,除了委員會規模不同外,也有部分有特別差異,像是PEP 8010提出的技術領袖治理模型,或多或少想保留仁慈的獨裁者的模式,而PEP 8012的社群治理模型,則是一個去中心權威的模型,與PEP 8010的設計理念完全相反,而有趣的是,PEP 8012得票數第二,PEP 8010則是最不受歡迎的選項。


Advertisement

更多 iThome相關內容