[Active] PEP 13 - Python Language Governance

원문 링크: PEP 13 - Python Language Governance

상태: Active 유형: Process 작성일: 16-Dec-2018

PEP 13 – Python 언어 거버넌스

요약

이 PEP는 Python의 공식 거버넌스(governance) 프로세스를 정의하며, 시간이 지남에 따라 어떻게 변경되었는지 기록합니다. 현재 Python의 거버넌스는 스티어링 위원회(steering council)를 중심으로 이루어집니다. 스티어링 위원회는 광범위한 권한을 가지지만, 이 권한을 가능한 한 드물게 행사하고자 노력합니다.

현재 스티어링 위원회

2025년 임기의 스티어링 위원회는 다음으로 구성됩니다:

  • Barry Warsaw
  • Donghee Na
  • Emily Morehouse
  • Gregory P. Smith
  • Pablo Galindo Salgado

이는 PEP 8106에 추적된 투표 결과에 따릅니다.

코어 팀(core team)은 https://github.com/python/voters/ 비공개 저장소에 나열된 사람들로 구성되며, 이 정보는 https://devguide.python.org/developers/를 통해 공개적으로 공유됩니다.

상세 규정 (Specification)

스티어링 위원회 (The Steering Council)

구성 (Composition) 스티어링 위원회는 5인으로 구성된 위원회입니다.

임무 (Mandate) 스티어링 위원회는 다음을 위해 노력해야 합니다:

  • Python 언어 및 CPython 인터프리터의 품질과 안정성 유지.
  • 기여(contributing)를 가능한 한 접근성 있고, 포괄적이며, 지속 가능하게 만들기.
  • 코어 팀과 Python Software Foundation (PSF) 간의 관계를 공식화하고 유지.
  • PEP에 대한 적절한 의사 결정 프로세스 수립.
  • 공식적인 역량으로 행동하기 전에 기여자(contributors) 및 코어 팀 간의 합의(consensus) 모색.
  • 다른 모든 방법이 실패한 결정에 대한 “최종 항소 법원” 역할 수행.

권한 (Powers) 위원회는 프로젝트에 대한 결정을 내릴 수 있는 광범위한 권한을 가집니다. 예를 들어 다음과 같은 일을 할 수 있습니다:

  • PEP를 수락하거나 거부합니다.
  • 프로젝트의 행동 강령(code of conduct)을 시행하거나 업데이트합니다.
  • PSF와 협력하여 프로젝트 자산을 관리합니다.
  • 권한의 일부를 다른 소위원회 또는 프로세스에 위임합니다.

그러나 위원회는 이 PEP를 수정하거나, 이 PEP에 명시된 메커니즘을 통해서가 아니라면 코어 팀의 멤버십에 영향을 미칠 수 없습니다.

위원회는 이러한 권한을 가능한 한 적게 사용하는 방법을 찾아야 합니다. 투표 대신 합의를 추구하는 것이 좋습니다. 개별 PEP에 대한 결정 대신, PEP 의사 결정을 위한 표준 프로세스를 정의하는 것이 좋습니다 (예: 다른 801x 시리즈 PEP 중 하나를 수락하는 방식). 개별 사례에 대해 판단하기보다는 행동 강령 위원회(Code of Conduct committee)를 설립하는 것이 좋습니다.

권한을 사용하기 위해 위원회는 투표를 합니다. 모든 위원회 멤버는 투표하거나 명시적으로 기권해야 합니다. 특정 투표에 이해 상충(conflicts of interest)이 있는 멤버는 기권해야 합니다. 통과하려면 기권하지 않은 위원회 멤버의 엄격한 과반수가 필요합니다.

가능한 한, 위원회의 심의(deliberations)와 투표는 공개적으로 진행되어야 합니다.

위원회 선출 (Electing the Council) 위원회 선거는 두 단계로 구성됩니다:

  • 1단계: 후보자가 봉사할 의사를 표명합니다. 후보자는 코어 팀 멤버의 추천을 받아야 하며, 자천도 허용됩니다.
  • 2단계: 각 코어 팀 멤버는 각 후보자에게 0에서 5개의 별을 할당할 수 있습니다. 투표는 익명으로 진행됩니다. 투표 결과는 STAR 투표 시스템을 사용하며, Multi-winner Bloc STAR 방식으로 수정하여 결정됩니다. 동점(tie)이 발생하는 경우, 후보자 간의 상호 합의로 해결하거나, 그렇지 않으면 무작위로 당선자를 선택합니다.

각 단계는 퇴임하는 위원회의 재량에 따라 1~2주 동안 진행됩니다. 초기 선거의 경우, 두 단계 모두 2주 동안 진행됩니다.

선거 과정은 퇴임하는 스티어링 위원회가 지명한 선거 관리관(returns officer)이 관리합니다. 초기 선거의 경우, 선거 관리관은 PSF 사무총장(Executive Director)이 지명합니다.

위원회는 Python 기여자(contributors) 및 사용자들의 다양성을 이상적으로 반영해야 하며, 코어 팀 멤버들은 그에 따라 투표하도록 권장됩니다.

임기 (Term) 새로운 위원회는 각 기능 릴리스(feature release) 후에 선출됩니다. 각 위원회의 임기는 선거 결과가 확정된 시점부터 다음 위원회의 임기가 시작될 때까지입니다. 임기 제한은 없습니다.

결원 (Vacancies) 위원회 멤버는 언제든지 사임할 수 있습니다.

정규 위원회 임기 중 결원이 발생할 경우, 위원회는 남은 임기를 채울 교체 멤버를 임명하는 투표를 할 수 있습니다.

위원회 멤버가 한 달 이상 연락이 두절되면, 나머지 위원회는 해당 멤버를 교체하는 투표를 할 수 있습니다.

이해 상충 (Conflicts of Interest) 위원회 멤버가 자신이나 고용주보다는 Python의 최선의 이익을 위해 행동할 것이라고 믿지만, 특정 회사가 Python 개발을 지배하는 것처럼 보이는 것만으로도 해로울 수 있고 신뢰를 훼손할 수 있습니다. 이해 상충의 외관을 피하기 위해, 위원회 멤버 중 한 회사에 소속된 사람은 최대 2명으로 제한됩니다.

위원회 선거에서 상위 5명 중 3명이 동일한 고용주를 위해 일하는 경우, 가장 낮은 순위의 후보자는 자격이 박탈되고 6위 후보가 5위로 올라갑니다. 유효한 위원회가 구성될 때까지 이 과정이 반복됩니다.

위원회 임기 중, 상황 변화로 인해 이 규칙이 위반될 경우 (예: 위원회 멤버가 직장을 바꾸는 경우), 한 명 이상의 위원회 멤버가 문제를 해결하기 위해 사임해야 하며, 그로 인한 결원은 정상적인 방식으로 채워질 수 있습니다.

코어 팀 멤버 제명 (Ejecting Core Team Members) 예외적인 상황(예: 심각하고 지속적인 행동 강령 위반)에서는 코어 팀 멤버를 본인의 의사에 반하여 제명해야 할 수도 있습니다. 이는 스티어링 위원회의 투표를 통해 이루어질 수 있지만, 다른 스티어링 위원회 투표와 달리 최소 3분의 2의 다수결이 필요합니다. 5명의 멤버가 투표할 때, 이는 3대2 투표로는 불충분하며, 최소 4대1 찬성(4:1 in favor)이 필요합니다. 또한, 이는 스티어링 위원회의 권한 중 위임할 수 없는 유일한 권한이며, 불신임 투표가 진행 중인 동안에는 이 권한을 사용할 수 없습니다.

제명된 코어 팀 멤버가 스티어링 위원회 멤버인 경우, 해당 멤버는 스티어링 위원회에서도 제명됩니다.

불신임 투표 (Vote of No Confidence) 예외적인 상황에서는 코어 팀이 불신임 투표를 통해 현직 위원회 멤버 또는 전체 위원회를 해임할 수 있습니다.

불신임 투표는 코어 팀 멤버가 적절한 프로젝트 통신 채널에 공개적으로 요청하고, 다른 코어 팀 멤버가 1주일 이내에 제안에 동의(second)할 때 시작됩니다.

투표는 2주 동안 진행됩니다. 코어 팀 멤버는 찬성 또는 반대표를 던집니다. 투표자의 최소 3분의 2가 불신임을 표명하면 투표가 성공합니다.

불신임 투표에는 두 가지 형태가 있습니다: 단일 멤버를 대상으로 하는 투표와 위원회 전체를 대상으로 하는 투표. 불신임 투표의 초기 요청 시 어떤 유형인지 명시해야 합니다. 단일 멤버 투표가 성공하면 해당 멤버는 위원회에서 해임되고, 그로 인한 결원은 일반적인 방식으로 처리될 수 있습니다. 전체 위원회 투표가 성공하면 위원회는 해산되고 새로운 위원회 선거가 즉시 시작됩니다.

코어 팀 (The Core Team)

역할 (Role) 코어 팀은 Python을 관리하는 신뢰받는 자원봉사자 그룹입니다. 이들은 프로젝트 목표 달성에 필요한 많은 역할을 수행하며, 특히 높은 수준의 신뢰가 필요한 역할을 맡습니다. 이들은 프로젝트의 미래를 결정하는 의사 결정을 내립니다.

코어 팀 멤버는 커뮤니티와 Python에 의존하는 모든 사람들을 대표하여 커뮤니티의 롤모델이자 프로젝트의 관리자로서 행동할 것으로 기대됩니다.

이들은 드물게 개입이 필요한 상황이 발생할 경우, 온라인 토론 또는 공식 Python 행사에서 필요에 따라 개입할 것입니다.

이들은 Python 프로젝트 웹사이트 자체, Python GitHub 조직 및 저장소, 버그 트래커, 메일링 리스트, IRC 채널 등을 포함한 Python 프로젝트 인프라에 대한 권한을 가집니다.

특권 (Prerogatives) 코어 팀 멤버는 일반적으로 새로운 팀 멤버를 지명하고 스티어링 위원회를 선출하는 등 공식적인 투표에 참여할 수 있습니다.

멤버십 (Membership) Python 코어 팀 멤버는 다음을 입증합니다:

  • Python 프로젝트 철학에 대한 깊은 이해.
  • 건설적이고 도움이 되는 탁월한 기여 이력.
  • 어떤 형태든 프로젝트 목표에 대한 상당한 기여.
  • Python 개선을 위해 시간을 할애하려는 의지.

프로젝트가 성숙함에 따라 기여는 코드 그 이상을 의미합니다. 코어 팀에 합류하기 위해 고려될 수 있는 영역의 불완전한 목록은 다음과 같습니다 (순서는 중요하지 않습니다):

  • 커뮤니티 관리 및 아웃리치(outreach) 작업
  • 메일링 리스트 및 IRC에서 지원 제공
  • 티켓 분류(triaging)
  • 패치 작성 (코드, 문서, 또는 테스트)
  • 패치 검토 (코드, 문서, 또는 테스트)
  • 설계 결정 참여
  • 특정 도메인 (보안, i18n 등)에 대한 전문 지식 제공
  • 지속적인 통합(continuous integration) 인프라 관리
  • 서버 관리 (웹사이트, 트래커, 문서 등)
  • 관련 프로젝트 유지 관리 (대체 인터프리터, 패키징과 같은 핵심 인프라 등)
  • 시각적 디자인 제작

코어 팀 멤버십은 Python 프로젝트의 철학과 목표에 잘 부합하는 지속적이고 가치 있는 노력을 인정합니다.

이는 1주일 동안 진행되며 스티어링 위원회에 의해 거부되지 않은 코어 팀 투표에서 최소 3분의 2의 찬성표를 받아야 부여됩니다.

참고: 개발 가이드(devguide)에는 이러한 투표에 사용할 제안된 템플릿이 있습니다.

코어 팀 멤버들은 항상 유망한 기여자들을 찾고, 프로젝트가 어떻게 관리되는지 가르치며, 준비가 되면 코어 팀 투표에 그들의 이름을 제출합니다.

코어 팀 멤버십에는 시간 제한이 없습니다. 그러나 일반 대중에게 Python을 유지 관리하는 사람들의 수를 합리적으로 알리기 위해, 기여를 중단한 코어 팀 멤버는 자신을 “비활성(inactive)”으로 선언하도록 권장됩니다. 2년 동안 의미 있는 기여를 하지 않은 멤버는 이 범주로 이동하도록 요청받을 수 있으며, 응답이 없으면 이동됩니다. 그들의 기여를 기록하고 기리기 위해, 비활성 팀 멤버는 활성 코어 팀 멤버와 함께 계속 나열됩니다. 나중에 다시 기여를 재개하면 언제든지 활성 상태로 전환할 수 있습니다. 그러나 비활성 상태에 있는 동안에는 투표 또는 스티어링 위원회 지명과 같은 활성 권한 및 커밋(commit) 접근 권한을 잃게 됩니다.

초기 활성 코어 팀 멤버는 현재 GitHub의 “Python core” 팀에 나열된 모든 사람으로 구성되며 (코어 멤버에게만 접근 권한 부여), 초기 비활성 멤버는 과거에 커미터(committer)였던 다른 모든 사람으로 구성됩니다.

이 문서 변경 (Changing this document)

이 문서의 변경 사항은 2주 동안 진행되는 코어 팀 투표에서 최소 3분의 2 이상의 찬성표를 필요로 합니다.

참고 블록과 “Current steering council” 및 “History of council elections” 섹션을 최신 정보로 업데이트하는 데는 투표가 필요하지 않습니다.

연혁 (History)

문서 생성 (Creation of this document) Python 프로젝트는 Guido van Rossum에 의해 시작되었으며, 그는 2018년 7월에 물러날 때까지 “자비로운 종신 독재자(Benevolent Dictator for Life, BDFL)” 역할을 수행했습니다.

논의 끝에 새로운 거버넌스 모델에 대한 여러 제안이 제출되었고, 코어 개발자들은 이들 중에서 선택하기 위해 투표했습니다. 전반적인 프로세스는 PEP 8000 및 PEP 8001에 설명되어 있으며, 다른 프로젝트에 대한 검토는 PEP 8002에서 수행되었고, 제안 자체는 801x 시리즈 PEP로 작성되었습니다. 최종적으로 PEP 8016의 제안이 새로운 거버넌스 모델로 선택되었고, 이를 사용하여 이 PEP의 초기 버전이 생성되었습니다. 8000 시리즈 PEP는 역사적 참고 자료로 보존되어 있지만 (특히 PEP 8016은 추가적인 근거와 동시대 논의 링크를 포함), 이 PEP가 이제 공식 참조 문서이며, 여기에 설명된 규칙에 따라 발전할 것입니다.

위원회 선거 연혁 (History of council elections)

  • 2019년 1월: PEP 8100
  • 2019년 12월: PEP 8101
  • 2020년 12월: PEP 8102
  • 2021년 12월: PEP 8103
  • 2022년 12월: PEP 8104
  • 2023년 12월: PEP 8105
  • 2024년 12월: PEP 8106

개정 연혁 (History of amendments)

  • 2019-04-17: 코어 개발자 투표 기간 및 이 문서 변경 사항 추가.
  • 2024-12-10: 위원회 선거에 Multi-winner Bloc STAR 투표 방식 채택.
  • 2024-12-10: 불신임 투표에 대한 동의(seconding)에 1주일 기한 추가.

감사의 글 (Acknowledgements)

이 PEP는 Nathaniel J. Smith와 Donald Stufft가 Django 거버넌스 문서를 기반으로 작성한 PEP 8016으로 시작되었으며, Aymeric Augustin이 작성하고 수많은 다른 사람들의 피드백과 도움을 통합했습니다.

이 문서는 퍼블릭 도메인(public domain)에 있습니다.

⚠️ 알림: 이 문서는 AI를 활용하여 번역되었으며, 기술적 정확성을 보장하지 않습니다. 정확한 내용은 반드시 원문을 확인하시기 바랍니다.

Comments