Following system colour scheme Selected dark colour scheme Selected light colour scheme

Python 개선 제안 한국어 번역

PEP 8015 – Python 커뮤니티의 조직

Author:
Victor Stinner
Status:
Rejected
Type:
Informational
Topic:
Governance
Created:
04-Oct-2018
Table of Contents

번역·라이선스 안내

이 비공식 한국어 번역은 원문 Copyright 절의 Public Domain 조건에 따라 제공합니다. 원저자와 공식 원문은 그대로 표시합니다. 수정되지 않은 기준 원문 · 공식 최신판

초록

이 PEP는 Python 커뮤니티의 현재 조직을 공식화하고 다음 3가지 주요 변경 사항을 제안합니다:

  • 기존의 “Python 팀” 개념을 공식화합니다;
  • Python 팀에 더 많은 자율성을 부여합니다;
  • BDFL(Guido van Rossum)을 제한된 역할만 맡는 5인의 새로운 “Python 운영 위원회”로 대체합니다. 운영 위원회는 기본적으로 결정을 내리는 방식을 정할 뿐, 결정 자체를 내리지는 않습니다.

PEP는 PEP 위임자 또는 투표(코어 개발자에게만 권한이 있으며, >= 2/3의 다수 찬성이 필요합니다)를 통해 승인됩니다.

PEP 거부

PEP 8015는 2018년 12월 17일 월요일에 PEP 8001에 설명된 핵심 개발자 투표로 거부되었습니다.

대신 PEP 8016과 그 PEP가 설명하는 거버넌스 모델이 채택되었습니다.

근거

이 PEP는 Python 사용자부터 Python 운영 위원회에 이르기까지 Python 개발 커뮤니티 전체의 조직을 설명합니다. 모든 그룹과 모든 역할을 같은 문서에서 설명하면 조직의 일관성을 높이는 데 도움이 됩니다.

기존 BDFL 조직에서 새로운 운영 위원회 조직으로 원활하게 전환할 수 있도록 거버넌스 변경을 최소화합니다.

이 조직 설계의 핵심 중 하나는 의사 결정의 병목을 피하는 것입니다. 논의와 결정은 각 주제의 전문가가 있는 Python 팀들로 분산됩니다. 이를 통해 PEP에 관한 논의가 더 원활해질 것으로 기대합니다. 해당 주제를 더 잘 아는 더 적은 수의 사람들이 논의하게 되기 때문입니다.

이전에는 대부분의 결정을 종신 자비로운 독재자(BDFL)인 Guido van Rossum이 내렸습니다. Python의 인기가 높아지면서 한 사람에게 가해지는 부담이 커졌습니다. 제안하는 조직은 결정과 책임을 분산하여 부담을 줄이고 어느 한 개인도 지쳐 버리지 않도록 합니다.

결정 권한의 대부분을 커뮤니티의 손에 남겨 두기 위해 Python 운영 위원회는 매우 제한된 역할만 맡습니다. 이는 어떤 집단이나 기업이 단 몇 명의 개인을 통해 Python 프로젝트를 “장악”할 위험을 줄이기 위한 것입니다. 이 프로젝트는 자율적이어야 하며 모든 사람에게 열려 있어야 합니다.

가장 민감한 PEP는 민주주의, 즉 코어 개발자에게만 권한이 있는 투표로 결정됩니다. 투표 방식은 아래의 PEP process 절을 참고하십시오.

공통 지침

  • Python 커뮤니티는 모든 사람에게 열려 있습니다.
  • 구성원은 논의가 건설적으로 유지되고 모든 사람이 환영받는다고 느끼도록 보장하는 Python 커뮤니티 행동 강령을 준수해야 합니다.
  • Python은 자율적인 프로젝트이며 앞으로도 그러할 것입니다.
  • 결정 권한을 가진 사람들은 Python 사용자와 기여자의 다양성을 반영해야 합니다.

커뮤니티 조직

현재 Python 프로젝트에는 여러 집단의 사람들이 참여하고 있습니다. 더 깊이 참여할수록 더 많은 의사 결정 권한을 얻습니다. 가장 깊은 그룹에 들어가는 사람들이 가장 신뢰받는 사람들이어야 한다는 점이 중요합니다.

이 PEP는 다음 그룹들을 공식화합니다:

  • Python 사용자
  • Python 기여자
  • Python 팀 구성원
  • Python 코어 개발자
  • Python 운영 위원회 위원
  • PSF 행동 강령 워킹 그룹

Python 사용자

이 집단은 가장 큰 집단으로, Python을 사용하는 모든 사람을 포함합니다.

Python 기여자

Python 사용자가 Python 메일링 리스트에 이메일을 보내거나, Python 버그 트래커에 댓글을 달거나, Python 변경 사항을 제안하거나 리뷰하면 Python 기여자가 됩니다.

Python 팀

Python은 더 이상 하나의 팀으로 일하기에는 너무 커졌기 때문에, 사람들은 자연스럽게 특정 주제에 대해 더 긴밀하게 작업하기 위해 팀을 이루었으며, 이러한 팀을 “Special Interest Group”(SIG)이라고 부르기도 합니다.

특정 주제에 관심을 가진 개발자가 충분히 모이면 새로운 팀을 만들 수 있습니다. 일반적으로 주된 절차는 Python 포스트마스터에게 새 “SIG” 메일링 리스트를 만들어 달라고 요청하는 것이지만, 팀은 다른 소통 채널을 사용하기로 선택할 수도 있습니다.

팀 구성원은 Python 기여자와 Python 코어 개발자입니다. 팀은 자율적으로 조직되며, 누가 어떤 방식으로 팀에 합류할 수 있는지를 정할 책임이 있습니다.

팀 구성원은 팀의 버그 트래커 컴포넌트에 대한 버그 분류 권한을 받을 수 있습니다. 팀에 더 깊이 참여할수록 더 많은 의사 결정 권한과 책임을 얻습니다.

팀이 자신의 PEP를 직접 결정하도록 허용될 수도 있지만, 이를 허용할 수 있는 것은 Python 운영 위원회뿐입니다(또한 운영 위원회는 이 권한을 철회할 권한도 가집니다). 이러한 경우는 예외적이며, 현재 이 권한을 가진 팀은 패키징 팀 하나뿐입니다.

Annex: Examples of Python Teams를 참조하십시오.

Python 코어 개발자

코어 개발자를 좁게 정의하면, (코드의 어느 부분이든) 변경 사항을 머지할 수 있고 (모든 버그 트래커 컴포넌트에 대한) 버그 분류 권한을 가진 사람입니다.

코어 개발자는 변경 사항을 승인할지 거부할지 결정하는 데 필요한 역량뿐만 아니라, (이것이 더 중요한데) 어떤 변경을 해서는 안 되는지 판단하는 역량을 갖추었음이 입증된 개발자입니다. Python은 긴 역사, 하위 호환성에 대한 큰 제약, 높은 품질 기준(예: 변경 사항에는 새 테스트가 필요함)을 가지고 있습니다. 이러한 이유로 코어 개발자가 되기까지 몇 달 또는 그 이상이 걸릴 수 있습니다.

코어 개발자가 된다는 것은 더 많은 책임을 진다는 뜻입니다. 예를 들어, 개발자가 변경 사항을 머지하면 그 개발자는 회귀 문제와 수정된 코드의 유지 보수에 책임을 지게 됩니다.

코어 개발자는 행동 강령과 관련하여 모범이 될 것으로 기대됩니다. 핵심 개발자는 기여자를 멘토링하도록 권장됩니다.

기여자를 코어 개발자로 승격하기

기존 코어 개발자가 어떤 기여자가 코어 그룹에 합류하여 코어 개발자가 될 준비가 되었다고 판단하면, 그 코어 개발자는 해당 기여자에게 코어 개발자가 되고 싶은지 묻습니다. 기여자가 이러한 새로운 책임에 관심이 있다면 투표를 진행합니다.

투표는 코어 개발자에게만 권한이 있고, 공개적으로 진행되며, 1주일 동안 열려 있습니다. 일반적으로 승격을 제안하는 코어 개발자는 투표 설명에 후보자의 작업과 역량을 기술해야 합니다. 기여자는 투표의 3분의 2(>= 2/3)가 승격에 찬성(“+1”)한 경우에만 승격됩니다. “+1”과 “-1” 투표만 집계하며, 그 밖의 투표(예: null, “-0”, “+0.5”)는 무시합니다.

후보자가 승격되면 보통 1개월 동안 멘토가 배정되어 새로운 책임을 수행하도록 돕습니다.

후보자가 승격되지 않으면, 후보자가 부족한 역량을 갖춘 뒤, 예를 들어 6개월 후에 새로운 투표를 진행할 수 있습니다.

Python 운영 위원회

Python 운영 위원회는 가장 큰 결정 권한을 가지므로 가장 신뢰받는 코어 개발자들로 구성됩니다. 이 집단의 역할은 Python이 자율성을 유지하고 개방된 상태로 남도록 엄격하게 제한됩니다.

Python 운영 위원회는 5명의 위원으로 구성됩니다. 위원은 3년 임기로 선출되며 매년 3분의 1이 교체됩니다(첫해: 1명, 둘째 해: 2명, 셋째 해: 2명). 이렇게 하면 위원은 Python 릴리스 하나의 전체 기간 동안 재임하게 되며, 위원회 구성은 자주 갱신됩니다. 위원은 자신이 물러나는 자리에 다시 입후보할 수 있습니다. 임기 제한은 없습니다.

위원회 위원은 Python 코어 개발자여야 합니다. 위원회 위원이 Python 사용자와 기여자의 다양성을 반영하는 것이 중요합니다. 이를 보장하기 위한 작은 조치로, 같은 고용주(같은 회사 또는 같은 회사의 자회사)에서 일하는 위원은 2명(5명 중 50% 미만)까지만 허용합니다.

위원 수를 5명으로 정한 것은 위원의 다양성을 확보하고, 한 위원이 언제까지일지 모르는 기간 동안 활동할 수 없게 되더라도 위원회가 계속 일할 수 있도록 하기 위해서입니다.

Python 운영 위원회의 역할

Python 운영 위원회의 역할:

  • PEP를 어떻게 승인(또는 거부나 보류)할지 결정합니다.
  • Python 팀에 권한을 부여하거나 회수합니다. 예를 들어, 어떤 팀이 기여자에게 (그 팀 컴포넌트에 대한) 버그 분류 권한을 줄 수 있도록 허용합니다.

PEP를 어떻게 승인(또는 거부나 보류)할지 결정하는 방법에는 두 가지가 있습니다.

  • 위원회는 PEP 위임자(이전에는 “BDFL-delegate”로 알려짐)를 선출합니다: 특정 PEP에 대해 최종 결정을 내릴 코어 개발자입니다. 위원회는 PEP가 논의되는 Python 팀이 추천할 수 있는 PEP 위임자를 선정합니다.
  • 위원회는 PEP에 대한 투표를 조직할 수 있으며, 투표 조직에 관해서는 PEP process를 참조하십시오. 위원회는 투표를 언제 조직할지 결정합니다. 언어 변경처럼 모든 Python 사용자에게 영향을 미치는 변경에는 투표가 선호됩니다.

위원회는 Python의 “비전”과 일관성을 유지합니다. 또한 중요한 기능이 완성에 이르도록 보장합니다. PEP 위임자를 선택할 수 있는 권한은 위원회가 이 목표를 달성하도록 돕기 위한 것입니다.

Python 운영 위원회 위원 선거

투표는 운영 위원회가 조직합니다. 투표는 3주 전에 공지되며, 후보자는 이 기간 동안 지원해야 합니다. 투표권은 코어 개발자에게만 주어지며, 투표는 1주일 동안 진행됩니다. 자기 검열을 피하기 위해 투표는 비밀 투표로 진행합니다. 이는 (선출될 경우) 더 많은 권한을 얻을 수 있는 사람으로부터 적대를 받을 위험을 피하기 위함입니다.

투표는 Condorcet Internet Voting Service (CIVS) 같은 온라인 서비스를 이용하여 콩도르세 방식의 슐체/Beatpath/CSSD 변형을 사용합니다. 이 투표 방식은 동점이 나올 위험을 줄여 줍니다. 또한 위원회 구성에 필요한 전체 후보자의 순위를 산출합니다.

동점인 경우, 동점인 후보자들을 대상으로 같은 투표 방식을 사용하여 역시 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도 선출됩니다. 그렇지 않으면 5번째 자리를 놓고 E와 F 사이에 2차 투표를 진행합니다.

특수한 경우: 운영 위원회 위원과 PEP

위원회 위원은 PEP 위임자가 될 수 있습니다.

위원회 위원은 PEP를 제안할 수 있지만, 자신이 제안한 PEP의 PEP 위임자가 될 수는 없습니다.

위원회가 PEP를 투표에 부쳐야 한다고 결정하면, 위원회 위원도 코어 개발자이므로 투표할 수 있지만 다른 코어 개발자보다 더 많은 권한을 갖지는 않습니다.

PSF 행동 강령 작업 그룹

헌장

이 작업 그룹의 목적은 PSF 행동 강령을 시행하고 행동 강령에 관한 지침과 권고를 Python 커뮤니티에 제공함으로써 다양하고 포용적인 Python 커뮤니티를 육성하는 것이며, 이는 “Python 관련 기술 및 교육 자료의 지속적인 개발”이라는 PSF의 사명을 뒷받침합니다.

우리는 다음 세 가지 방법으로 이 공동의 목표를 향해 나아갑니다:

  • PSF 행동 강령 및 PSF가 지원하는 다른 커뮤니티와 관련된 정책을 검토하고 개정하며 이에 대해 조언합니다. 여기에는 PSF 관할에 속하는 모든 #python 채팅 커뮤니티와 python.org 이메일 목록이 포함됩니다.
  • 콘퍼런스, 메일링 리스트, slack/IRC, 코드 저장소 등을 포함하되 이에 국한되지 않는 여러 상호 작용 채널을 위한 표준 행동 강령 모음과 지원 문서를 만듭니다.
  • Python 커뮤니티 주최자가 행동 강령을 도입하고 시행할 수 있도록 교육 자료와 기타 절차를 개발합니다.

이 작업 그룹의 조직은 ConductWG Charter에 정의되어 있습니다.

특수한 경우: 코어 개발자 활동 금지

Python 커뮤니티의 다른 모든 구성원과 마찬가지로, PSF 행동 강령 작업 그룹은 코어 개발자의 활동을 일정 기간 금지할 수 있습니다. 이 경우 해당 코어 개발자는 즉시 코어 개발자 지위를 잃습니다. 코어 개발자는 행동 강령과 관련하여 모범이 되어야 합니다.

일반적으로 활동 금지는 다른 모든 선택지를 다 써 본 뒤에만 취하는 최후의 수단입니다.

활동 금지 기간이 끝나면 해당 개발자는 일반 기여자로서 다시 기여할 수 있습니다.

해당 개발자가 행동을 바꾼다면, 다른 코어 개발자가 새 투표를 열어 그 개발자를 코어 개발자로 승격하도록 제안할 수 있습니다. 이 투표는 다른 Python 기여자의 경우와 동일한 절차를 따릅니다.

PEP 절차

PEP에는 두 가지 주요 역할이 있습니다:

  • PEP 작성자
  • PEP 위임자

PEP 작성자는 고품질의 PEP를 작성하기 위해 최선을 다합니다.

PEP 위임자는 저자들이 PEP을 개선하도록 돕는 책임을 지며, 최종 결정(PEP의 수락, 거부 또는 연기)을 내리는 사람입니다. 위임자는 논의를 이끄는 데 도움을 줄 수도 있습니다.

결정이 내려지지 않으면 저자들은 나중에(예: 1년 뒤) PEP을 다시 제안할 수 있으며, 가능하면 변경의 근거가 될 새로운 데이터를 함께 제시하는 것이 좋습니다. PEP 위임자는 PEP을 거부하지 않고 나중에 논의를 다시 시작하도록 장려하기 위해 PEP을 “Deferred”로 표시하기로 선택할 수도 있습니다.

특정 Python 팀에 한정된 PEP는 해당 팀의 메일링 리스트에서 논의합니다. 모든 파이썬 개발자에게 영향을 미치는 PEP(언어 변경 등)은 python-dev 메일링 리스트에서 논의해야 합니다.

PEP에 대한 투표

Python 운영 위원회가 PEP에 더 폭넓은 승인이 필요하다고 결정하면 투표를 실시합니다.

투표는 코어 개발자만 참여할 수 있고, 공개적으로 진행되며, 1주일 전에 공지되고, 1주일 동안 진행됩니다. PEP은 1주일의 공지 기간 동안에는 여전히 갱신할 수 있지만, 투표 중에는 수정해서는 안 됩니다. 이러한 투표는 해당 PEP을 논의한 메일링 리스트에서 진행됩니다. 투표 실시 시기는 위원회가 결정합니다. PEP은 투표에 부치기 전에 충분한 기간 동안 논의되어야 합니다.

PEP은 투표의 3분의 2 이상(>= 2/3)이 PEP에 찬성(“+1”)할 때만 승인됩니다. “+1”과 “-1” 표만 집계하며, 그 밖의 표(예: null, “-0”, “+0.5”)는 무시합니다.

투표를 통해서는 PEP을 승인하거나 거부할 수만 있으며, 연기할 수는 없습니다.

결정이 내려지지 않는 경우

논의가 합의에 이르지 못하거나, Python 운영 위원회가 PEP 위임자를 선정하지 못하거나, PEP 위임자가 결정을 내리지 못하면, Python이 발전하지 못하게 될 위험이 분명히 있습니다.

그래도 괜찮습니다. 때로는 아무것도 하지 않는 것이 가장 현명한 선택입니다.

이 PEP의 변경

이 PEP의 첫 번째 버전은 2018년 7월 Guido van Rossum이 BDFL 역할에서 물러나기로 결정한 뒤에 작성되었습니다. 이 PEP 이전에는 Python 커뮤니티 구성원의 역할이 공식화된 적이 없었습니다. 처음부터 완벽한 조직을 설계하기는 어렵습니다. 이 PEP은 앞으로 조직을 조정하고, 예외적인 상황을 처리하는 방법을 명시하고, 잘못된 점을 바로잡기 위해 갱신될 수 있습니다.

이 PEP에 대한 모든 변경은 반드시 투표로 승인받아야 합니다. 투표는 3주 전에 공지되고, 코어 개발자만 참여할 수 있으며, python-committers 메일링 리스트에서 공개적으로 진행되고, 1주일 동안 진행됩니다. 제안된 PEP 변경 사항은 3주의 공지 기간 동안에는 여전히 갱신할 수 있지만, 투표 중에는 수정해서는 안 됩니다.

변경 사항은 투표의 5분의 4 이상(>= 4/5)이 변경에 찬성(“+1”)할 때만 승인됩니다. “+1”과 “-1” 표만 집계하며, 그 밖의 표(예: null, “-0”, “+0.5”)는 무시합니다.

부록: 투표 요약

투표 공지 기간 투표 기간 투표 방식 결정 방식
기여자 승격 없음 1주 공개 >= 2/3 다수결
PEP 1주 1주 공개 >= 2/3 다수결
이 PEP 변경 3주 1주 공개 >= 4/5 다수결
운영 위원회 3주 1주 비공개 콩도르세(Schulze/Beatpath/CSSD)

이 모든 투표는 코어 개발자만 참여할 수 있습니다.

부록: Python 팀의 예

다음은 몇몇 Python 팀의 예입니다(이 목록은 이 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

멘토십 팀

코어 개발자가 되는 것은 길고 느린 과정입니다. 멘토십은 기여자를 미래의 코어 개발자로 양성하고 신뢰 관계를 구축하는 효율적인 방법입니다.

참고: 이 그룹은 코어 개발자 승격을 책임지지 않습니다.

문서화 팀

  • 메일링 리스트: doc-sig
  • 버그 트래커 컴포넌트: Documentation
  • GitHub 태그: type-doc
  • 구성원 예: Julien Palard, INADA Naoki, Raymond Hettinger.

이 팀은 문서 번역도 관리합니다.

“Devguide”를 관리하는 멘토십 팀도 참고하십시오.

보안 팀

  • 웹사이트: https://www.python.org/news/security/
  • 메일링 리스트:
    • security@python.org (취약점 보고용)
    • security-sig (공개 리스트)
  • 표준 라이브러리 모듈: hashlib, secrets, ssl
  • 구성원 예: Christian Heimes, Benjamin Peterson

security@python.org 메일링 리스트는 초대받은 사람만 가입할 수 있습니다. “Python 보안 대응 팀”(PSRT) 구성원만 이메일을 읽고 답장할 수 있습니다. 반면 security-sig는 공개되어 있습니다.

참고: 이 팀은 PEP를 제안한 일이 거의 없습니다.

성능 팀

성능에 관련된 PEP는 대개 모든 사람에게 영향을 미치므로 speed 메일링 리스트보다는 python-dev 메일링 리스트에서 논의합니다.

비동기 프로그래밍 팀

asyncio와 contextvars만 수정하는 PEP는 async-sig 메일링 리스트에서 논의할 수 있습니다. 반면 Python 언어에 영향을 주는 변경 사항은 반드시 python-dev에서 논의해야 합니다.

타입 힌트 팀

참고: Python 3.6 이하 버전용 백포트가 있습니다. PyPI의 typing을 참고하십시오.

버전 이력

이 PEP의 이력:

  • 버전 7: 운영 위원회 조정
    • 운영 위원회는 이제 3명이 아닌 5명으로 구성됩니다.
    • 임기 제한이 없습니다(기존에는 최대 2회 임기, 총 6년으로 제한되었습니다).
    • 이제 위원회 위원도 PEP 위임자가 될 수 있습니다.
  • 버전 6: 투표 조정
    • 콩도르세 방식을 명시합니다: Python 운영 위원회 위원을 선출하는 데 Schulze/Beatpath/CSSD 변형을 사용합니다. 동점 처리 방법과 고용주에 관한 제약을 명시합니다.
    • 기여자 승격 및 PEP에 대한 투표는 이제 50%+1이 아닌 >= 2/3의 찬성을 요구합니다.
    • 이 PEP 변경에 대한 투표는 이제 50%+1이 아닌 >= 4/5의 찬성을 요구합니다.
    • 회사 인수 시 처리 방법을 설명합니다.
  • 버전 5: Python 운영 위원회 위원 선거에 비밀 투표를 사용합니다
  • 버전 4:
    • 투표 조정: 투표는 1개월이 아닌 1주일 동안 진행하며, 사전에 공지합니다.
    • “Python Core Board”의 이름을 “Python Steering Committee”로 변경합니다;
    • 이 위원회는 PEP를 승인하지 않으며, 위원회 위원은 2회를 초과하여 임기를 누적할 수 없음을 명확히 합니다;
    • 부록에 “Type Hints” 팀을 추가합니다.
  • 버전 3: “특수한 경우: 코어 개발자 추방”과 “이 PEP를 갱신하는 방법” 절을 추가합니다.
  • 버전 2: PSF 이사회와의 혼동을 피하기 위해 “Python board”의 이름을 “Python Core Board”로 변경합니다.
  • 버전 1: python-committers 및 discuss.python.org에 게시된 첫 번째 버전입니다.