PEP 8010 – 기술 리더 거버넌스 모델
- Author:
- Barry Warsaw <barry at python.org>
- Status:
- Rejected
- Type:
- Informational
- Topic:
- Governance
- Created:
- 24-Aug-2018
번역·라이선스 안내
이 비공식 한국어 번역은 원문 Copyright 절의 Public Domain 조건에 따라 제공합니다. 원저자와 공식 원문은 그대로 표시합니다. 수정되지 않은 기준 원문 · 공식 최신판
초록
이 PEP는 완곡하게 Benevolent Dictator For Life (BDFL) 모델이라고 불리는 단일 기술 프로젝트 리더 모델을 계속 유지할 것을 제안하며, 앞으로 이 PEP에서는 이를 Gracious Umpire Influencing Decisions Officer (GUIDO)라고 부릅니다. 이러한 명칭 변경은 더 폭넓은 개발 커뮤니티와 협의하여 Python 언어 의사 결정 과정의 최종 중재자로서 GUIDO를 바라보는 관점이 확대되었음을 반영하는 동시에, “for life”가 아마도 이상적인 목표일 수는 있지만 언어나 GUIDO 자신의 안녕을 위해 반드시 최선의 이익이 되는 것은 아니라는 점을 인정합니다.
이 PEP는 다음을 설명합니다.
- 단일 기술 리더 모델을 유지하는 근거
- GUIDO를 선발하고, 선출하고, 유임하고, 소환하고, 승계하는 절차
- Python 언어 발전 과정에서 GUIDO의 역할
- 임기 기간
- 기술적 사안에 관해 GUIDO에게 조언하는 Pythonista 협의회(CoP)와 GUIDO의 관계
- CoP의 규모, 선거 및 역할
- 의사 결정 위임 절차
- 새로운 거버넌스 모델에 맞추기 위한 PEP 절차의 변경 사항
이 PEP는 새로운 BDFL을 지명하지 않습니다. 이 모델이 채택되면 이 PEP에서 설명하는 모든 재직자의 이름과 함께 PEP 13에 성문화됩니다.
PEP 거부
PEP 8010은 2018년 12월 17일 월요일에 PEP 8001에 기술된 핵심 개발자 투표로 거부되었습니다.
대신 PEP 8016과 해당 PEP가 설명하는 거버넌스 모델이 선택되었습니다.
공개 논의 사항
거버넌스 논의 과정에서는 CoP의 정확한 규모, 임기 기간 및 투표 절차와 같은 이 PEP의 매개변수에 다양한 조정을 가할 수 있습니다. 이러한 사항은 PEP가 투표에 부쳐질 준비가 될 때까지 성문화됩니다.
이 PEP에 설명된 투표 절차와 사건에는 기본적으로 PEP 8001에 지정된 투표 방식이 적용되지만, 이 글을 작성하는 시점에도 해당 PEP가 아직 논의 중이므로 변경될 수 있습니다.
이 모델에 대한 경험이 쌓임에 따라 향후 GUIDO가 임명될 때 더 원활한 통치 절차를 제공하기 위해 이러한 매개변수를 조정할 수 있으며, 어쩌면 그렇게 될 것으로 예상하기도 합니다.
왜 단일 기술 리더인가?
다른 모델이 아니라 왜 이 모델입니까? 이는 “비전”으로 귀결됩니다. Design by committee 에는 알려진 단점이 많으며, 당시 기여자들의 다양한 이해관계에 기반하여 새로운 기능이 계속 추가되는 언어로 이어집니다. 유명한 격언으로 “낙타는 위원회가 설계한 말이다”라는 말이 있습니다. 위원회가 설계한 언어가 “일관성을 유지할” 수 있습니까? 규칙이 타당하고 쉽게 기억되는, 일관되고 자기 일관적인 언어처럼 느껴집니까?
단일 기술 리더는 위원회보다 그 비전을 더 잘 추진할 수 있으며, 위원회가 소규모(예: 3명 또는 5명)이든 Python 커뮤니티 전체를 아우르든 마찬가지입니다. 모든 참여자는 “Python”이 무엇인지에 대한 각자의 비전을 갖게 되며, 이러한 개별적인 비전이 충돌할 때 우유부단함이나 비논리적인 선택으로 이어질 수 있습니다. CPython을 3배 더 빠르게 해야 합니까, 아니면 C API를 보존해야 합니까? 어느 선택도 옳거나 그르지 않기 때문에, 합의를 이루기가 매우 어려운 질문입니다. 그러나 잘못된 결정을 내리는 것보다 더 나쁜 일은 합의를 찾지 못했다는 이유로 현 상태를 받아들이는 것일 수 있습니다.
유연성
불완전한 명세를 통해 GUIDO와 CoP 모두에 일정 수준의 유연성이 부여됩니다. 이 PEP는 갈등이 해결되는 방식을 설명하지만, 핵심 개발자, 커뮤니티 구성원, 직책 보유자를 포함한 모든 참여자가 항상 Python과 그 사용자의 최선의 이익을 염두에 둘 것을 기대합니다. 이 PEP는 상호 존중과 최선의 의도가 항상 합의로 이어지며, 행동 강령이 모든 상호 작용과 논의를 규율한다고 전제합니다.
GUIDO의 역할
GUIDO의 가장 중요한 역할 중 하나는 여러 릴리스에 걸친 Python 언어의 발전을 위한 포괄적이고 폭넓으며 일관된 비전을 제시하는 것입니다. 결정이 지속적인 영향을 미치고 서로 경쟁하는 이점이 있을 때 이는 특히 중요합니다. 예를 들어 C API에 대한 하위 호환성이 없는 변경으로 Python 성능이 2배 향상된다면, 서로 다른 커뮤니티 구성원들이 논쟁의 양측에서 설득력 있게 주장할 가능성이 높으며, 명확한 합의가 도출되지 않을 수 있습니다. 어느 선택이든 동등하게 타당합니다. CoP와 협의하여 최종 결정을 이끄는 것은 GUIDO의 비전입니다.
GUIDO는 특정 변경 사항이 PEP로 다룰 가치가 있는지 여부를 포함하여 PEP 및 기타 문제에 대한 최종 권한을 가집니다. 오늘날과 마찬가지로 많은 결정, 사실 어쩌면 대부분의 결정은 이슈 트래커, 병합 요청 및 토론 포럼에서 논의와 해결을 통해 처리되며, 일반적으로 해당 분야 전문가의 의견이나 주도로 이루어집니다. 이 운영 절차가 원활하게 작동하는 경우에는 변경 없이 계속 사용할 수 있습니다. 이는 CoP와 GUIDO의 업무량을 줄이는 데도 도움이 되며, 가장 중요한 결정과 상황에 대한 가장 폭넓은 관점만을 중앙 권한에 맡깁니다.
마찬가지로 특정 변경 사항에 PEP가 필요하다고 판단되었지만 GUIDO가 CoP와 협의하여 최종 결정을 내릴 전적인 신뢰를 받는 전문가를 파악한 경우, GUIDO는 해당 PEP의 Delegate를 지명할 수 있습니다. GUIDO가 최종 권한으로 남아 있는 동안에도, GUIDO는 Delegate의 권한을 약화하지 않고 오히려 PEP의 최종 판단자로서 그 권한을 지지할 것으로 기대됩니다.
제안이 Python의 장기적인 비전에 어긋난다는 점이 분명할 때 GUIDO는 생산적이지 않은 논의, 아이디어 및 제안을 중단할 전적인 권한을 가집니다. 이는 변경을 주장하는 사람들에게 연민을 보이면서도 모든 커뮤니티 구성원의 건강과 안녕을 염두에 두고 이루어집니다. 막다른 제안에 대한 유해한 논의는 누구에게도 도움이 되지 않으며, 직권으로 종료할 수 있습니다.
요약하면, 거버넌스 PEP 자체를 변경하는 일은 제외하고 GUIDO는 기술적 주제든 비기술적 주제든 모든 주제에 대해 최종 입장을 밝힐 권한을 가집니다.
권한은 커뮤니티에서 나옵니다
GUIDO의 권한은 궁극적으로 커뮤니티에 있습니다. 커뮤니티 다수의 신뢰를 잃은 독단적인 GUIDO는 소환될 수 있으며 새로운 투표가 실시될 수 있습니다. 이는 극히 드물고 가능성도 낮은 사건입니다. 이는 최악의 상황을 위한 충분한 임시 방편이므로 가볍게 실행해서는 안 됩니다. GUIDO는 하나의 결정 때문에, 설령 그 결정이 Python 개발자 다수의 지지를 받지 못하더라도, 해임되는 것을 두려워해서는 안 됩니다. 소환은 Python 언어나 커뮤니티에 심각한 해를 끼치는 행위에 한정해야 합니다.
Pythonista 위원회(아래 참조)는 불신임 투표를 발의할 책임이 있습니다.
재임 기간 및 임기 제한
GUIDO는 Python 릴리스 3회 동안, 현재 릴리스 주기를 기준으로 약 4.5년간 재임합니다. Python의 릴리스 주기가 변경되면 GUIDO의 임기도 전체 릴리스 횟수로 반올림한 4.5년에 맞춰 변경해야 합니다. 반올림 방식을 어떻게 정할지는 향후 릴리스 주기 PEP에 맡깁니다. 이 기간이 지나면 아래에 설명된 절차에 따라 새 선거를 실시합니다. 임기 제한은 없으므로 GUIDO는 원하는 만큼 재선에 출마할 수 있습니다.
GUIDO가 임기를 모두 수행할 것으로 기대하지만, 물론 살다 보면 어쩔 수 없는 일이 생깁니다. GUIDO가 임기가 끝나기 전에 사임해야 하는 경우, 새 GUIDO를 선출하는 아래의 절차에 따라 공석을 채웁니다. 그러나 새 GUIDO는 원래 GUIDO의 남은 임기 동안만 재임하며, 그 시점에 새 선거를 실시합니다. 사임하는 GUIDO는 후임자가 선출될 때까지 계속 재임할 수 있습니다.
전환 기간에는 CoP(아래 참조)가 GUIDO의 업무를 수행할 수 있지만, 실질적인 결정(기술적 PEP 승인 등)은 차기 GUIDO에게 맡기는 것을 선호할 수도 있습니다.
GUIDO 선출
새 GUIDO의 공석이 발생하거나 통상적인 절차에 따라 GUIDO가 재선에 출마해야 할 때마다 선출 절차가 시작됩니다. GUIDO의 사임으로 선출 절차가 시작되거나 GUIDO의 정규 임기 종료 2개월 전이 되면 새 선거 절차가 시작됩니다.
투표 3주 전부터 후보 추천을 받습니다. 후보자는 현재 Python 핵심 개발자 목록에서 선정해야 합니다. 핵심 개발자가 아닌 개발자는 GUIDO로 재임할 자격이 없습니다. 후보자는 자신을 추천할 수 있지만, 모든 후보 추천에는 제2 추천자가 있어야 합니다. 후보 추천과 제2 추천은 비공개 저장소의 병합 요청으로 진행합니다.
후보자는 추천을 수락한 후 동일한 비공개 저장소를 사용하여 짧은 입장문을 게시할 수 있으며, 커미터 토론 포럼에도 게시할 수 있습니다. 어쩌면 토론까지 하게 될지도 모릅니다! 이 선거 단계는 2주 동안 진행됩니다.
이후 핵심 개발자는 PEP 8001에 설명된 절차를 사용하여 3주 동안 투표합니다.
Pythonista 위원회(CoP)
GUIDO를 지원하는 소규모의 선출된 Python 전문가 팀이 있습니다. 이들은 기술 위원회 구성원으로 이루어진 팀에서 활동합니다. 이들은 GUIDO 앞에 놓인 선택 사항에 대한 통찰을 제공하고 논의를 진행합니다. 어느 한쪽에서든 자문을 요청할 수 있습니다. 예를 들어 GUIDO가 특정 선택 사항에 대해 여전히 결정을 내리지 못한 경우, CoP와의 논의를 통해 남은 문제를 명확히 하고, 적절한 질문을 파악하며, GUIDO가 잘 알지 못할 수 있는 다른 Python 사용자에게 미치는 영향에 대한 통찰을 얻을 수 있습니다. CoP는 GUIDO가 신뢰하는 자문단이며, 긴밀한 업무 관계가 기대됩니다.
CoP는 핵심 개발자 중에서 선출된 3명의 구성원으로 구성됩니다. 임기는 3년이며, 구성원은 원하는 만큼 여러 번 재선에 출마할 수 있습니다. 연속성을 보장하기 위해 CoP 구성원은 순환 방식으로 선출되며, 매년 CoP 구성원 한 명이 재선 대상이 됩니다.
최초 선거에서 임기를 엇갈리게 시작하기 위해 득표수가 가장 많은 CoP 구성원은 3년, 두 번째로 득표수가 많은 사람은 2년, 득표수가 가장 적은 CoP 구성원은 처음에 1년 동안 재임합니다.
투표에서 동률이 발생하면 PEP 8001에서 정하는 절차에 따라 해결합니다.
후보 추천 및 투표 절차는 GUIDO의 경우와 유사합니다. 3주간의 후보 추천 기간이 있으며, 이 기간에는 자기 추천이 허용되지만 재청을 받아야 합니다. 그 후 입장문을 게시하는 기간이 이어지고, 다시 투표가 진행됩니다.
CoP는 만장일치로 GUIDO에 대한 불신임 투표를 시작할 수 있으며, 해당 절의 절차가 발동됩니다.
불신임 투표
위에서 언급했듯이 CoP는 만장일치로 GUIDO에 대한 불신임 투표를 시작할 수 있습니다. 이 절차는 가볍게 시작해서는 안 되지만, 일단 시작되면 최대 두 번의 투표가 진행됩니다. 두 경우 모두 PEP 8001에서와 동일한 절차로 투표하며, 모든 핵심 개발자가 불신임 투표에 참여할 수 있습니다.
첫 번째 투표에서는 현재 GUIDO를 해임할지 여부를 결정합니다. Python 개발자 중 압도적 다수가 “불신임”에 투표하면 GUIDO가 해임됩니다. 그런 다음 이 직책의 최초 선출 절차에 따라 새로운 GUIDO를 선출하는 두 번째 투표를 진행합니다. GUIDO가 없는 동안에는 중요한 결정을 보류하지만, 통상적인 Python 운영은 물론 계속 진행할 수 있습니다.
일상적인 운영
모든 결정, 아니 대부분의 결정에 GUIDO가 필요한 것은 아닙니다. Python 개발자에게는 이미 권한 위임, 책임 및 자기 주도권을 행사할 충분한 기회가 있습니다. 이슈 추적 시스템과 풀 리퀘스트는 이 거버넌스 모델을 선택하기 전과 정확히 동일한 기능을 수행합니다. 버그 수정과 사소한 개선에 관한 대부분의 논의는 예전과 마찬가지로 이러한 포럼에서 바로 진행할 수 있습니다.
PEP 관련 고려 사항
GUIDO, CoP 구성원 및 Python 커뮤니티의 다른 누구든 PEP를 제안할 수 있습니다. 제안된 PEP의 처리는 해당 PEP의 작성자와 관계없이 동일하게 진행됩니다.
그러나 GUIDO가 PEP를 작성하는 경우에는 공정한 PEP 위임자를 선정하고, 해당 위임자에게 PEP를 수락하거나 거부할 권한을 부여해야 합니다. GUIDO는 의사 결정 과정에서 회피해야 합니다. 명확한 합의에 이르지 못하는 논쟁적인 PEP의 경우, GUIDO가 작성한 PEP에 대한 최종 권한은 CoP에 있습니다.
PEP 제안 절차는 핵심 개발자를 PEP 셰퍼드로 항상 선정해야 하도록 더욱 강화됩니다. 이 사람은 적절한 절차가 유지되도록 보장합니다. 셰퍼드는 핵심 개발자 중에서 선정해야 합니다. 이는 누구나 PEP를 작성할 수 있지만, 모든 PEP가 최소 한 명의 핵심 개발자로부터 일정 수준의 후원을 받아야 한다는 의미입니다.
버전 기록
버전 2입니다.
- “기술 리더 거버넌스 모델”로 이름을 변경했습니다.
- “단일 리더” -> “단일 기술 리더”
- 해당 PEP가 승인될 때까지 PEP 8001 투표 절차의 채택은 잠정적입니다.
- GUIDO가 사임할 경우 어떤 일이 발생하는지 설명하십시오.
- 소환 투표가 가결되려면 핵심 개발자의 초다수가 필요합니다.
Copyright
This document has been placed in the public domain.