將貢獻者晉升為核心開發者

一旦現有的核心開發者認為某位貢獻者已準備好加入核心群體，成為核心開發者，該核心開發者會詢問該貢獻者是否願意成為核心開發者。如果該貢獻者對這些新責任感興趣，則會組織一次投票。

投票限於核心開發者，公開進行，並開放 1 週。通常，提出晉升的核心開發者必須在投票描述中說明候選人的工作和技能。只有在三分之二（>= 2/3）的投票批准（「+1」）晉升時，貢獻者才會被晉升。僅計算「+1」和「-1」票；其他票（例如：無效、 「-0」、「+0.5」）將被忽略。

如果候選人獲得晉升，通常他們會獲得一位導師為期 1 個月的指導，以協助他們處理新的職責。

如果候選人未獲晉升，則可以在以後，當候選人獲得所需技能時，再次組織投票，例如 6 個月後。

Python 治理委員會的職責

Python 治理委員會職責

• 決定 PEP 如何被批准（或拒絕或延期）。
• 授予或撤銷 Python 團隊的權限。例如，允許團隊向貢獻者授予錯誤分類權限（在團隊組件上）。

為了決定 PEP 如何被批准（或拒絕或延期），有兩個選項

• 委員會選舉一位 PEP 委派者（以前稱為「BDFL 委派者」）：一位核心開發者，將對特定 PEP 做出最終決定。委員會選擇 PEP 委派者，該委派者可以由討論 PEP 的 Python 團隊提出。
• 委員會可以組織對 PEP 的投票，投票組織請參閱 PEP 流程。委員會決定何時組織投票。對於影響所有 Python 使用者的變更，例如語言變更，優先採用投票方式。

委員會維持 Python 的「願景」和一致性。它也確保重要功能得以完成。他們選擇 PEP 委派者的能力旨在幫助他們實現這個目標。

Python 治理委員會成員的選舉

投票由治理委員會組織。它會提前 3 週公布：候選人必須在此期間申請。投票限於核心開發者，並開放 1 週。為了避免自我審查，投票採用不記名投票：避免可能獲得更多權力的人（如果他們當選）產生敵意的風險。

投票採用 孔多塞方法 (Condorcet method) 的 舒爾茨／擊敗路徑／CSSD (Schulze/Beatpath/CSSD) 變體，使用線上服務，例如 孔多塞網路投票服務 (CIVS)。這種投票方法降低了平手的風險。它還會產生所有候選人的排名，這是委員會成立所必需的。

如果出現平手，將立即在平手的候選人之間重新組織一次投票，使用相同的投票方法，並持續 1 週。如果第二次投票再次導致平手，則由現任治理委員會負責選擇當選成員。

如果委員會成員辭職，將組織一次新的投票以替補其職位。

如果委員會成員的情況發生變化，不再滿足委員會的限制（例如：他們搬到與其他兩名委員會成員相同的公司），他們必須辭職。如果某成員的雇主被其他兩名成員的雇主收購，則任期較早結束的成員必須在收購完成後辭職。

成立 Python 治理委員會成員的選舉

為了啟動該流程，在委員會成立時選出 5 名成員。投票遵循與常規委員會投票相同的規則，不同之處在於選舉需要 5 名成員，並且投票由 PSF 董事會組織。

在委員會選舉中，若前 5 名得票者中有 3 人來自同一雇主，則其中排名最低者將失去資格，並由第 6 名候選人遞補進入前 5 名；此過程重複進行直到形成合法的委員會為止。

如果出現平手，將立即在平手的候選人以及隨後的候選人之間組織第二次投票，以填補剩餘席位。投票遵循與常規委員會投票相同的規則。如果第二次投票仍然導致平手，則由 PSF 董事會負責選舉成員並決定他們在投票結果中的排名。

投票結果中的順序對於當選成員必須是唯一的：#1 和 #2 當選任期 3 年，#2 和 #3 任期 2 年，#5 任期 1 年。

投票結果出現平手範例

• A
• B
• C
• D
• E、F
• G
• …

前 4 名候選人 (A、B、C 和 D) 立即當選。如果 E 與其他兩名當選成員為同一雇主工作，則 F 也當選。否則，將在 E 和 F 之間為第 5 個席位組織第二次投票。

特殊情況：治理委員會成員與 PEP

委員會成員可以擔任 PEP 委派者。

委員會成員可以提出 PEP，但不能擔任自己所提 PEP 的 PEP 委派者。

當委員會決定對某個 PEP 必須進行投票時，委員會成員可以投票，因為他們也是核心開發者，但他們的權力不會大於其他核心開發者。

章程

該工作小組的宗旨是透過執行 PSF 行為準則，並向 Python 社群提供行為準則相關的指導和建議，來促進一個多元和包容的 Python 社群，以支持 PSF「持續開發與 Python 相關的技術和教育資源」的使命。

我們透過三種方式朝著這個共同目標努力

• 審查、修訂並就與 PSF 行為準則以及 PSF 支持的其他社群相關的政策提供建議。這包括 PSF 管轄下的任何 #python 聊天社群和 python.org 電子郵件列表。
• 建立一套標準的行為準則和支援文件，適用於多種互動管道，例如但不限於會議、郵件列表、Slack/IRC、程式碼儲存庫等。
• 開發培訓材料和其他流程，以支持 Python 社群組織者實施和執行行為準則。

本工作小組的組織由 行為準則工作小組章程 定義。

特殊情況：禁止核心開發者

作為 Python 社群的任何其他成員，PSF 行為準則工作小組可以在有限時間內禁止核心開發者。在這種情況下，該核心開發者立即失去其核心開發者身分。核心開發者在行為準則方面應當是模範。

一般而言，當所有其他選項都已用盡時，禁止才是最終手段。

禁令結束後，該開發者被允許再次以普通貢獻者的身分貢獻。

如果該開發者改變其行為，另一位核心開發者可以組織一次新的投票，提議將該開發者晉升為核心開發者。投票遵循與任何其他 Python 貢獻者相同的流程。

PEP 投票

當 Python 治理委員會決定某個 PEP 需要更廣泛的批准時，將組織一次投票。

投票限於核心開發者，公開進行，提前 1 週宣布，並開放 1 週。PEP 在 1 週的通知期間仍可更新，但在投票期間不得修改。此類投票發生在討論該 PEP 的郵件列表上。委員會決定何時組織投票。PEP 必須經過合理時間的討論後才能付諸投票。

只有在三分之二（>= 2/3）的投票批准（「+1」）該 PEP 時，該 PEP 才會被批准。僅計算「+1」和「-1」票；其他票（例如：無效、 「-0」、「+0.5」）將被忽略。

PEP 只能透過投票批准或拒絕，不能延期。

套件管理團隊

套件管理團隊營運自己的 PEP 類別，並且可以批准（或拒絕）自己的 PEP。

• 網站：packaging.python.org
• 郵件列表：distutils-sig
• 錯誤追蹤器組件：Distutils
• 成員範例：Paul Moore、Alyssa Coghlan、Donald Stuff
• 標準函式庫模組：distutils
• 現任 PEP 委派者：Paul Moore

IDLE 團隊

IDLE 在 Python 標準函式庫中是一個特殊案例：它是一個完整的應用程式，而不僅僅是一個模組。基於這個原因，已決定程式碼在所有 Python 穩定分支中都相同（而標準函式庫在較新的穩定分支中會有所不同）。

• 錯誤追蹤器組件：IDLE
• 成員範例：Terry Reedy、Cheryl Sabella、Serhiy Storchaka
• 標準函式庫模組：idlelib

導師團隊

成為核心開發者是一個漫長而緩慢的過程。指導是培養貢獻者成為未來核心開發者並建立信任關係的有效方式。

• 網站
  • https://python.club.tw/dev/core-mentorship/
  • https://devguide.python.org/
• 儲存庫：https://github.com/python/devguide
• 郵件列表：core-mentorship（私密存檔）
• 成員範例：Guido van Rossum、Carol Willing、Victor Stinner

注意：此群組不負責晉升核心開發者。

文件團隊

• 郵件列表：doc-sig
• 錯誤追蹤器組件：Documentation
• GitHub 標籤：type-doc
• 成員範例：Julien Palard、INADA Naoki、Raymond Hettinger。

該團隊也負責管理文件翻譯。

另請參閱維護「開發者指南」(Devguide) 的導師團隊。

資安團隊

• 網站：https://python.club.tw/news/security/
• 郵件列表
  • security@python.org（用於報告漏洞）
  • security-sig（公開列表）
• 標準函式庫模組：hashlib、secrets 和 ssl
• 成員範例：Christian Heimes、Benjamin Peterson

security@python.org 郵件列表僅限邀請：只有「Python 安全應變團隊」(PSRT) 的成員才能閱讀電子郵件和回覆；而 security-sig 則是公開的。

注意：此團隊很少提出 PEP。

效能團隊

• 網站：https://speed.python.org/
• 郵件列表：speed
• 儲存庫
  • https://github.com/python/performance
  • https://github.com/tobami/codespeed
• 錯誤追蹤器類型：Performance
• GitHub 標籤：type-performance
• 標準函式庫模組：cProfile、profile、pstats 和 timeit
• 成員範例：Victor Stinner、INADA Naoki、Serhiy Storchaka

通常涉及效能的 PEP 會影響所有人，因此在 python-dev 郵件列表上討論，而不是在 speed 郵件列表上。

非同步程式設計團隊

• 網站：https://docs.python.club.tw/dev/library/asyncio.html
• 郵件列表：async-sig
• 錯誤追蹤器組件：asyncio
• GitHub 標籤：expert-asyncio
• 標準函式庫模組：asyncio 和 contextvars
• 成員範例：Andrew Sveltov、Yury Selivanov

僅修改 asyncio 和 contextvars 的 PEP 可以在 async-sig 郵件列表上討論，而影響 Python 語言的變更則必須在 python-dev 上討論。

型別提示團隊

• 網站：http://mypy-lang.org/
• 儲存庫：https://github.com/python/typing
• mypy 專案的 GitHub 標籤：topic-pep-484
• 標準函式庫模組：typing
• 成員範例：Guido van Rossum、Ivan Levkivskyi、Jukka Lehtosalo、Łukasz Langa、Mark Shannon。

注意：有一個針對 Python 3.6 及更舊版本的向後移植 (backport)，請參閱 PyPI 上的 typing。