PEP 8015 – Python 커뮤니티의 조직

Author:

Victor Stinner

Status:

Rejected

Type:

Informational

Topic:

Governance

Created:

04-Oct-2018

---

Table of Contents

• 초록
• PEP 거부
• 근거
• 일반 지침
• 커뮤니티 조직
• Python 사용자
• Python 기여자
• Python 팀
• Python 핵심 개발자
  • 기여자를 핵심 개발자로 승격하기
• Python 운영 위원회
  • Python 운영 위원회의 역할
  • Python 운영 위원회 위원 선출
  • Python 운영 위원회 위원 선출
  • 특별 사례: 운영 위원회 구성원 및 PEP
• PSF 행동 강령 작업 그룹
  • 헌장
  • 특별 사례: 핵심 개발자 활동 금지
• PEP 절차
  • PEP에 투표하기
• 결정의 부재
• 이 PEP 변경하기
• 부록: 투표 요약
• 부록: Python 팀의 예
  • 패키징 팀
  • IDLE 팀
  • 멘토링 팀
  • 문서화 팀
  • 보안 팀
  • 성능 팀
  • 비동기 프로그래밍 팀
  • 타입 힌트 팀
• 버전 기록
• Copyright

번역·라이선스 안내

이 비공식 한국어 번역은 원문 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는 Python 사용자부터 Python 운영 위원회에 이르기까지 전체 Python 개발 커뮤니티의 조직을 설명합니다. 모든 그룹과 역할을 동일한 문서에서 설명하면 조직을 더욱 일관되게 만드는 데 도움이 됩니다.

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

이 조직의 핵심 설계 중 하나는 의사 결정 병목 현상을 방지하는 것입니다. 각 주제의 전문가를 찾을 수 있는 Python 팀으로 토론과 의사 결정을 분산합니다. PEP에 관한 토론이 더 원활해질 것으로 기대합니다. 주제에 대한 지식이 더 뛰어난 소수의 사람들이 참여하기 때문입니다.

이전에는 대부분의 결정을 종신 자비로운 독재자(BDFL)인 Guido van Rossum이 내렸습니다. Python의 인기가 높아지면서 한 사람에게 가해지는 압박이 커졌습니다. 제안된 조직은 압박을 줄이고 개인이 소진되는 것을 방지하기 위해 의사 결정과 책임을 분산합니다.

대부분의 의사 결정 권한을 커뮤니티의 손에 유지하기 위해 Python 운영 위원회는 매우 제한적인 역할만 맡습니다. 이는 소수의 개인을 통해 사람이나 기업 집단이 Python 프로젝트를 “장악하는” 위험을 줄이기 위한 것입니다. 프로젝트는 자율적이고 누구에게나 개방된 상태로 유지되어야 합니다.

가장 민감한 PEP는 민주주의로 결정됩니다. 즉, 핵심 개발자에게만 허용된 투표로 결정되며, 투표 방식은 아래의 PEP process 절을 참조하십시오.

일반 지침

• 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년 임기로 선출되며 매년 1/3이 교체됩니다(첫해: 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 method의 Schulze/Beatpath/CSSD variant를 사용하며, Condorcet Internet Voting Service (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도 선출됩니다. 그렇지 않으면 5번째 의석을 놓고 E와 F 사이에 2차 투표를 실시합니다.

특별 사례: 운영 위원회 구성원 및 PEP

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

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

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

PSF 행동 강령 작업 그룹

헌장

이 작업 그룹의 목적은 PSF 행동 강령을 시행하여 다양하고 포용적인 Python 커뮤니티를 조성하고, “Python 관련 기술과 교육 자료의 지속적인 개발”이라는 PSF의 사명을 지원하는 행동 강령에 관해 Python 커뮤니티에 지침과 권고를 제공하는 것입니다.

다음 세 가지 방법으로 이 공동의 목표를 향해 노력합니다.

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

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

특별 사례: 핵심 개발자 활동 금지

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

일반적으로 활동 금지는 다른 모든 선택지를 소진했을 때 취하는 최후의 수단일 뿐입니다.

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

개발자가 행동을 바꾸면 다른 핵심 개발자가 해당 개발자를 핵심 개발자로 승격하자는 새로운 투표를 조직할 수 있습니다. 이 투표는 다른 Python 기여자의 경우와 동일한 절차를 따릅니다.

PEP 절차

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

• PEP 작성자
• PEP 위임자

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

PEP 델리게이트는 작성자가 PEP를 개선하도록 돕고, PEP를 수락하거나 거부하거나 연기하는 최종 결정을 내릴 책임이 있습니다. 또한 토론을 진행하도록 안내하는 데 도움을 줄 수 있습니다.

아무런 결정도 내려지지 않은 경우, 가능하다면 변경을 정당화할 새로운 데이터와 함께 작성자가 나중에(예: 1년 후) PEP를 다시 제안할 수 있습니다. PEP 델리게이트는 PEP를 거부하지 않고 나중에 토론을 다시 시작하도록 장려하기 위해 PEP를 “Deferred”로 표시할 수도 있습니다.

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

PEP에 투표하기

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

투표는 핵심 개발자에게만 허용되며 공개로 진행되고 1주일 전에 공지하며 1주일 동안 실시합니다. 1주일의 공지 기간 동안에도 PEP를 업데이트할 수 있지만, 투표 중에는 수정해서는 안 됩니다. 이러한 투표는 PEP가 논의된 메일링 리스트에서 진행합니다. 위원회가 투표 실시 시점을 결정합니다. PEP를 투표에 부치기 전에 합리적인 기간 동안 논의해야 합니다.

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

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

결정의 부재

토론이 합의에 도달하지 못하거나, Python 운영 위원회가 PEP 델리게이트를 선택하지 못하거나, PEP 델리게이트가 결정을 내리지 못하면 Python이 발전하지 못할 위험이 명백히 존재합니다.

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

이 PEP 변경하기

이 PEP의 첫 번째 버전은 Guido van Rossum이 2018년 7월 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

멘토링 팀

핵심 개발자가 되는 것은 길고 느린 과정입니다. 멘토링은 기여자들을 미래의 핵심 개발자로 훈련하고 신뢰 관계를 구축하는 효율적인 방법입니다.

• 웹사이트:
  • https://www.python.org/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://www.python.org/news/security/
• 메일링 리스트:
  • security@python.org (취약점을 보고하기 위한 용도)
  • security-sig (공개 목록)
• 표준 라이브러리 모듈: hashlib, secrets 및 ssl
• 멤버의 예: Christian Heimes, Benjamin Peterson

security@python.org 메일링 리스트는 초대받은 사람만 가입할 수 있습니다. “Python Security Response Team”(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는 모든 사람에게 영향을 미치므로 speed 메일링 리스트가 아니라 python-dev 메일링 리스트에서 논의합니다.

비동기 프로그래밍 팀

• 웹사이트: https://docs.python.org/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 이하를 위한 백포트가 있으므로 typing on PyPI를 참조하십시오.

버전 기록

이 PEP의 기록:

• 버전 7: 운영 위원회 조정
  • 운영 위회는 이제 3명이 아니라 5명으로 구성됩니다.
  • 임기 제한이 없습니다 (2회 임기로 제한하는 대신: 총 6년).
  • 위원회 구성원은 이제 PEP 위임자가 될 수 있습니다.
• 버전 6: 투표를 조정합니다
  • 콘도르세 방법을 명시합니다: Python 운영위원회 구성원을 선출할 때 Schulze/Beatpath/CSSD 변형을 사용합니다. 동률 및 고용주에 대한 제약을 처리하는 방법을 명시합니다.
  • 기여자를 승격하고 PEP에 대해 투표하려면 이제 >= 2/3가 필요하며, 50%+1이 필요하지 않습니다.
  • 이 PEP를 변경하려면 이제 >= 4/5가 필요하며, 50%+1이 필요하지 않습니다.
  • 회사 인수를 처리하는 방법을 설명합니다.
• 버전 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에 처음 게시되었습니다.

Copyright

This document has been placed in the public domain.