PEP 8016 – 운영 위원회 모델
- Author:
- Nathaniel J. Smith, Donald Stufft
- Status:
- Accepted
- Type:
- Informational
- Topic:
- Governance
- Created:
- 01-Nov-2018
번역·라이선스 안내
이 비공식 한국어 번역은 원문 Copyright 절의 Public Domain 조건에 따라 제공합니다. 원저자와 공식 원문은 그대로 표시합니다. 수정되지 않은 기준 원문 · 공식 최신판
참고
이 PEP는 역사적 목적으로 보존되지만, 공식 거버넌스 문서는 이제 PEP 13입니다.
초록
이 PEP는 운영 위원회를 중심으로 하는 Python 거버넌스 모델을 제안합니다. 운영 위원회는 광범위한 권한을 가지지만, 이를 가능한 한 드물게 행사하려고 합니다. 대신 이 권한을 사용하여 다른 801x 시리즈 PEP에서 제안한 것과 같은 표준 프로세스를 수립합니다. 이는 대규모 변경 사항을 독립적으로 검토할 수 있는 일련의 작은 변경 사항으로 나누는 편이 낫다는 일반적인 철학을 따릅니다. 하나의 PEP에서 모든 작업을 수행하려 하기보다는, 이후 거버넌스 결정을 위한 최소한이지만 견고한 기반을 제공하는 데 집중합니다.
PEP 승인
PEP 8016은 2018년 12월 17일 월요일, PEP 8001에 설명된 핵심 개발자 투표에 의해 승인되었습니다.
근거
이 제안의 주요 목표는 다음과 같습니다.
- 지루하게 만들기: 우리는 거버넌스 전문가가 아니며, Python은 새롭고 검증되지 않은 거버넌스 모델을 실험하기에 좋은 곳이 아니라고 생각합니다. 따라서 이 제안은 가능한 한 성숙하고 잘 알려졌으며 이전에 검증된 프로세스를 따릅니다. 대부분 직접 관여하지 않는 운영 위원회라는 고수준 접근 방식은 규모가 크고 성공적인 F/OSS 프로젝트에서 가장 일반적인 방식이라고 할 수 있으며, 저수준의 세부 사항은 Django의 거버넌스에서 직접 도출합니다.
- 단순하게 만들기: 우리는 이를 실행 가능하게 만드는 데 필요한 최소한으로 범위를 줄이려고 했습니다. 여기에는 운영 위원회, 운영 위원회를 선출하는 핵심 팀, 그리고 문서를 변경하는 프로세스가 포함됩니다. 목표는 최소 실행 가능 거버넌스(Minimum Viable Governance)입니다.
- 포괄적으로 만들기: 그러나 정의해야 하는 사항에 대해서는 모든 기반을 다루도록 노력했습니다. 이런 종류의 위기를 다시 겪고 싶지 않기 때문입니다. 명확하고 모호하지 않은 규칙 집합을 마련하는 것은 혼란과 불만을 최소화하는 데에도 도움이 됩니다.
- 유연하고 가볍게 만들기: 함께 작업하기 위한 최선의 프로세스를 찾으려면 시간과 실험이 필요하다는 점을 알고 있습니다. 이 문서를 가능한 한 간결하게 유지함으로써, 나중에 조정할 수 있는 최대한의 유연성을 확보하는 동시에 전체 프로젝트 투표처럼 무겁고 불안을 유발하는 프로세스의 필요성을 최소화합니다.
여러 세부 사항이 이 Discourse 스레드에서 논의되었고, 이후 이 스레드 에서 추가 논의가 이루어졌습니다. 이는 여러 사소한 결정의 근거를 이해하려는 사람에게 유용할 수 있습니다.
사양
운영 위원회
구성
운영 위원회는 5명으로 구성된 위원회입니다.
임무
운영 위원회는 다음을 위해 노력합니다.
- Python 언어와 CPython 인터프리터의 품질과 안정성을 유지합니다.
- 기여를 가능한 한 접근하기 쉽고 포괄적이며 지속 가능하게 만듭니다.
- 핵심 팀과 PSF 간의 관계를 공식화하고 유지합니다.
- PEP에 적합한 의사 결정 프로세스를 수립합니다.
- 공식적인 자격으로 활동하기 전에 기여자들과 핵심 팀 사이의 합의를 모색해야 합니다.
- 다른 모든 방법이 실패한 결정에 대해서는 “최종 항소 법정” 역할을 해야 합니다.
권한
평의회는 프로젝트에 관한 결정을 내릴 광범위한 권한을 가집니다. 예를 들어, 다음을 수행할 수 있습니다:
- PEP를 승인하거나 거부합니다.
- 프로젝트의 행동 강령을 시행하거나 갱신합니다.
- PSF와 협력하여 프로젝트 자산을 관리합니다.
- 권한의 일부를 다른 소위원회나 절차에 위임합니다.
그러나 이 PEP에 명시된 메커니즘을 통하는 경우를 제외하고는 이 PEP를 수정하거나 핵심 팀의 구성원 자격에 영향을 줄 수 없습니다.
평의회는 이러한 권한을 가능한 한 적게 사용할 방법을 찾아야 합니다. 투표하는 것보다 합의를 모색하는 것이 더 바람직합니다. 개별 PEP에 대해 판정을 내리는 것보다 PEP 의사 결정의 표준 절차를 정의하는 것이 더 바람직합니다(예를 들어, 다른 801x 시리즈 PEP 중 하나를 승인하는 방식입니다). 개별 사건에 대해 판정을 내리는 것보다 행동 강령 위원회를 설립하는 것이 더 바람직합니다. 그 밖에도 여러 가지가 있습니다.
권한을 행사하기 위해 평의회는 투표합니다. 모든 평의회 구성원은 투표하거나 명시적으로 기권해야 합니다. 특정 투표에 이해 충돌이 있는 구성원은 기권해야 합니다. 가결되려면 기권하지 않은 평의회 구성원 과반수의 지지가 필요합니다.
가능한 경우 언제나 평의회의 심의와 투표는 공개적으로 진행해야 합니다.
평의회 선출
평의회 선거는 두 단계로 구성됩니다.
- 1단계: 후보자들은 역할을 맡고 싶다는 의사를 밝힙니다. 후보자는 핵심 팀 구성원이 지명해야 합니다. 자기 지명이 허용됩니다.
- 2단계: 각 핵심 팀 구성원은 후보자 중 0명에서 5명까지 투표할 수 있습니다. 투표는 익명으로 진행됩니다. 후보자 순위는 받은 총 투표 수에 따라 정해집니다. 동률이 발생하면 후보자 간의 상호 합의로 해결할 수 있으며, 그렇지 않으면 무작위로 당선자를 정합니다.
각 단계는 임기를 마치는 평의회의 재량에 따라 1주에서 2주 동안 진행됩니다. 최초 선거에서는 두 단계 모두 2주 동안 진행됩니다.
선거 절차는 퇴임하는 운영 위원회가 지명한 선거 관리 책임자가 관리합니다. 최초 선거에서는 PSF 사무국장이 선거 관리 책임자를 지명합니다.
위원회는 이상적으로 Python 기여자와 사용자의 다양성을 반영해야 하며, 핵심 팀원은 이에 맞춰 투표하도록 권장됩니다.
임기
각 기능 릴리스 후에 새로운 위원회를 선출합니다. 각 위원회의 임기는 선거 결과가 확정된 시점부터 다음 위원회의 임기가 시작되는 시점까지입니다. 임기 제한은 없습니다.
공석
위원회 구성원은 언제든지 직위를 사임할 수 있습니다.
정규 위원회 임기 중 공석이 발생하면, 위원회는 남은 임기를 수행할 후임자를 임명하기 위해 투표할 수 있습니다.
위원회 구성원이 연락이 끊겨 한 달 이상 연락할 수 없는 경우, 나머지 위원회 구성원은 해당 구성원을 교체하기 위해 투표할 수 있습니다.
이해 상충
위원회 구성원이 자신이나 고용주가 아닌 Python의 최선의 이익을 위해 행동할 것이라고 신뢰하지만, 단 하나의 회사가 Python 개발을 지배하는 것처럼 보이는 것만으로도 해로울 수 있으며 신뢰를 약화할 수 있습니다. 이해 상충의 어떤 모습도 피하기 위해, 하나의 고용주에 소속된 위원회 구성원은 최대 2명으로 제한합니다.
위원회 선거에서 상위 5명의 득표자 중 3명이 같은 고용주에 소속되어 있다면, 그중 순위가 가장 낮은 사람을 자격 박탈하고 6위 후보를 5위로 올립니다. 유효한 위원회가 구성될 때까지 이 과정을 반복합니다.
위원회 임기 중 상황 변화로 이 규칙이 위반되면(예를 들어 위원회 구성원이 이직하는 경우), 문제를 해결하기 위해 한 명 이상의 위원회 구성원이 사임해야 하며, 그 결과 발생한 공석은 일반적인 절차에 따라 채울 수 있습니다.
핵심 팀원 축출
예외적인 상황에서는 당사자의 의사에 반하여 핵심 팀에서 누군가를 제거해야 할 수 있습니다. (예: 심각하고 지속적인 행동 강령 위반입니다.) 이는 운영 위원회의 투표로 수행할 수 있지만, 다른 운영 위원회 투표와 달리 최소 3분의 2 이상의 찬성이 필요합니다. 5명이 투표하는 경우, 이는 3 대 2 투표로는 부족하며, 해당 투표가 가결되기 위해 필요한 최소 조건은 4 대 1의 찬성입니다. 또한 이는 운영 위원회가 위임할 수 없는 유일한 권한이며, 불신임 투표가 진행 중인 동안에는 이 권한을 사용할 수 없습니다.
축출된 핵심 팀원이 운영 위원회에도 속해 있다면, 운영 위원회에서도 함께 제거합니다.
불신임 투표
예외적인 상황에서 핵심 팀은 불신임 투표를 통해 재임 중인 위원회 구성원 한 명 또는 위원회 전체를 제거할 수 있습니다.
핵심 팀원 한 명이 적절한 프로젝트 커뮤니케이션 채널에서 공개적으로 불신임 투표를 요청하고 다른 핵심 팀원이 그 제안에 재청하면 불신임 투표가 시작됩니다.
투표는 2주 동안 진행됩니다. 핵심 팀원은 찬성 또는 반대 투표를 합니다. 투표자의 3분의 2 이상이 불신임을 표명하면 투표가 가결됩니다.
불신임 투표에는 두 가지 형태가 있습니다. 한 명의 구성원을 대상으로 하는 투표와 위원회 전체를 대상으로 하는 투표입니다. 불신임 투표를 처음 요청할 때 의도한 형태를 명시해야 합니다. 단일 구성원 대상 투표가 가결되면 해당 구성원을 위원회에서 제거하며, 그 결과 발생한 공석은 일반적인 절차에 따라 처리할 수 있습니다. 위원회 전체 대상 투표가 가결되면 위원회가 해산되고 새로운 위원회 선거가 즉시 시작됩니다.
핵심 팀
역할
핵심 팀은 Python을 관리하는 신뢰받는 자원봉사자들의 그룹입니다. 이들은 프로젝트의 목표를 달성하는 데 필요한 다양한 역할을 맡으며, 특히 높은 수준의 신뢰가 필요한 역할을 맡습니다. 이들은 프로젝트의 미래를 형성하는 결정을 내립니다.
핵심 팀 구성원은 커뮤니티와 Python에 의존하는 모든 사람을 대신하여, 커뮤니티의 모범이자 프로젝트의 관리자로 행동해야 합니다.
개입이 필요한 상황이 발생하는 드문 경우에는 필요에 따라 온라인 토론이나 공식 Python 행사에 개입합니다.
이들은 Python 프로젝트 웹사이트 자체, Python GitHub 조직과 저장소, 버그 추적기, 메일링 리스트, IRC 채널 등을 포함한 Python 프로젝트 인프라에 대한 권한을 가집니다.
권한
핵심 팀 구성원은 공식 투표에 참여할 수 있으며, 일반적으로 새로운 팀 구성원을 지명하고 운영 위원회를 선출하는 투표에 참여합니다.
구성원 자격
Python 핵심 팀 구성원은 다음을 보여 줍니다:
- Python 프로젝트의 철학에 대한 깊은 이해
- 건설적이고 도움이 되는 태도를 꾸준히 보여 온 탄탄한 실적
- 형태와 관계없이 프로젝트의 목표에 대한 상당한 기여
- Python 개선에 일정 시간을 기꺼이 할애하려는 의지
프로젝트가 성숙해짐에 따라 기여는 코드를 넘어섭니다. 다음은 특별한 순서 없이, 핵심 팀에 합류하기 위한 기여로 고려될 수 있는 영역의 불완전한 목록입니다:
- 커뮤니티 관리 및 대외 활동 수행
- 메일링 리스트와 IRC에서 지원 제공
- 티켓 분류 및 우선순위 지정
- 패치 작성(코드, 문서 또는 테스트)
- 패치 검토(코드, 문서 또는 테스트)
- 설계 결정에 참여
- 특정 분야(보안, i18n 등)의 전문 지식 제공
- 지속적 통합 인프라 관리
- 서버(웹사이트, 추적기, 문서 등) 관리
- 관련 프로젝트 유지 관리(대체 인터프리터, 패키징과 같은 핵심 인프라 등)
- 시각적 디자인 제작
핵심 팀 구성원 자격은 Python 프로젝트의 철학 및 목표와 잘 부합하는 지속적이고 가치 있는 노력을 인정하는 것입니다.
핵심 팀 투표에서 3분의 2 이상 찬성표를 받고 운영 위원회의 거부권 행사가 없으면 부여됩니다.
핵심 팀 구성원은 항상 유망한 기여자를 찾고, 프로젝트가 관리되는 방식을 가르치며, 준비가 되면 해당 기여자의 이름을 핵심 팀 투표에 제출합니다.
핵심 팀 구성원 자격에는 시간 제한이 없습니다. 그러나 일반 대중에게 Python을 유지 관리하는 사람이 몇 명인지 합리적으로 알리기 위해, 기여를 중단한 핵심 팀 구성원은 자신을 “inactive”로 선언하는 것이 권장됩니다. 2년 동안 사소하지 않은 기여를 하지 않은 구성원에게는 이 범주로 이동하도록 요청할 수 있으며, 응답하지 않으면 해당 범주로 이동됩니다. 비활성 팀 구성원은 자신들의 기여를 기록하고 기리기 위해 활성 핵심 팀 구성원과 함께 계속 등재되며, 이후 기여를 재개하면 언제든지 활성 상태로 되돌아갈 수 있습니다. 다만 비활성 상태인 동안에는 운영 위원회에 투표하거나 후보를 추천할 수 있는 권한 및 커밋 접근 권한과 같은 활성 구성원의 권한을 잃습니다.
최초의 활성 핵심 팀 구성원은 현재 GitHub의 “Python core” team on GitHub에 등재된 모든 사람으로 구성되며, 최초의 비활성 구성원은 과거에 커미터였던 나머지 모든 사람으로 구성됩니다.
이 문서 변경
이 문서를 변경하려면 핵심 팀 투표에서 행사된 표의 최소 3분의 2 이상의 찬성이 필요합니다.
TODO
- 많은 사람이 유용한 제안과 피드백을 제공했으므로, 이들을 공동 저자로 추가하는 데 동의하는지 확인해야 합니다.
- Aymeric Augustin이 Django 문서 전체를 작성한 것으로 보이므로 저작권을 보유하고 있을 것입니다. 따라서 아래의 저작권 문구를 더 간단하게 만들 수 있도록 해당 문서를 퍼블릭 도메인으로 공개할 의향이 있는지 그에게 물어보는 것이 좋겠습니다.
감사의 말
상당한 분량의 텍스트를 The Django project’s governance document에서 뻔뻔스럽게 복사했습니다.
Copyright
Text copied from Django used under their license. The rest of this document has been placed in the public domain.