PEP 8013 – 외부 위원회 거버넌스 모델
- Author:
- Steve Dower <steve.dower at python.org>
- Status:
- Rejected
- Type:
- Informational
- Topic:
- Governance
- Created:
- 14-Sep-2018
번역·라이선스 안내
이 비공식 한국어 번역은 원문 Copyright 절의 Public Domain 조건에 따라 제공합니다. 원저자와 공식 원문은 그대로 표시합니다. 수정되지 않은 기준 원문 · 공식 최신판
초록
이 PEP는 언어에 대한 최종 결정을 내리는 임무를 맡은 감사 위원회(Council of Auditors, CoA)를 기반으로 하는 새로운 Python 거버넌스 모델을 제안합니다. 이 모델은 중앙의 단일 지도자를 제안하지 않는다는 점에서 PEP 8010과 다르고, 코어 커미터가 위원회 구성원이 되는 것을 허용하지 않는다는 점에서 PEP 8011과 다릅니다. 이 PEP는 위원회의 규모와 역할, 최초 위원회 구성원을 선정하는 방법, 위원회 구성원의 임기 제한, 그리고 후임자를 선출하는 방법을 설명합니다.
또한 이 모델이 의도하는 운영 방식을 논의하는 데에도 상당한 분량을 할애합니다. 많은 절차는 의도적으로 여기에서 규정하지 않고 관련된 사람들에게 맡깁니다. 최선의 결정을 내릴 사람들을 선정하려면 관련된 사람들이 CoA에 대한 기대를 이해하는 것이 중요하지만, 다양한 상황에 맞춰 절차상의 요구 사항을 조정할 수 있는 자유를 CoA에 주는 것도 그에 못지않게 중요합니다. 이는 절차가 규정되어 있지 않더라도 모든 참여자가 비슷한 기대를 공유할 때에만 제대로 작동합니다.
이 PEP는 CoA의 구성원을 지명하지 않습니다. 이 모델이 채택되면, 이 PEP에서 설명하는 모든 직책 보유자의 이름과 함께 PEP 13에 성문화됩니다.
PEP 거부
PEP 8013은 2018년 12월 17일 월요일에 PEP 8001에서 설명하는 코어 개발자 투표로 거부되었습니다.
대신 PEP 8016과 그 PEP가 설명하는 거버넌스 모델이 선택되었습니다.
회색 지대의 중요성
실제 의사 결정 과정에는 어떤 경우든 회색 지대가 존재하기 마련입니다. 여기에는 예상치 못한 상황과 “정답”이 없는 경우가 포함됩니다.
많은 절차 계획은 유연성이 전혀 필요하지 않을 만큼 절차를 명확하게 정의하여 회색 지대를 최소화하려고 합니다.
이 제안은 의도적으로 그 반대 방향을 택합니다. 목표는 예상치 못한 상황을 처리할 최적의 사람들을 선출하기 위한 견고한 프레임워크를 제공하되, 그 사람들이 그러한 상황을 어떻게 처리해야 하는지는 정의하지 않는 것입니다.
몇몇 상황에 대한 “좋은” 대응 사례를 예시로 제시합니다. 바라는 바는 “최적의” 사람들이 그러한 사례에 부응할 것이기 때문에 최적이라는 것입니다. 제안된 절차는 그 사람들이 최적이 아닌 것으로 드러났을 때 발생할 수 있는 피해를 최소화하도록 설계되었습니다.
회색 지대는 반드시 존재합니다. 이 제안은 회색 지대를 막으려 하기보다 의도적으로 이를 받아들이고 그 안에서 작동합니다.
모델 개요
주요 인물과 그 역할
감사 위원회(CoA)는 규모가 유동적인 위원회로, 일반적으로 2명에서 4명으로 구성되며, 한 Python 릴리스 기간 동안 재임하도록 선출됩니다. CoA 구성원 중 한 명은 의장으로 간주되며, 의장은 다른 구성원에 대해 몇 가지 사소한 권한을 가집니다.
CoA는 핵심 개발 팀 구성원이 작성한 PEP 형태의 논쟁적 결정을 검토할 책임을 집니다. CoA는 PEP를 제시된 그대로 수락할 수도 있고, 설명이나 변경을 요청할 수도 있습니다. 이러한 변경은 어떤 형태이든, 어떤 이유에서든 요청할 수 있습니다. 이러한 유연성은 의도된 것이며, 다른 구성원이 CoA에 선출됨에 따라 시간이 지나면서 프로세스가 변화할 수 있게 합니다. 예상되는 요청의 종류에 대한 예시는 이 문서의 뒷부분을 참조하십시오.
CoA는 python-committers에 제출된 PEP에 대해서만 결정을 선언합니다. CoA가 다른 메일링 리스트를 지켜보거나 참여할 것이라고 기대하지 않습니다. (이는 코어 개발자만 PEP를 제출할 수 있다는 의미임에 유의하십시오. 코어 개발자가 아닌 사람도 다른 메일링 리스트에서 제안을 작성하고 논의할 수 있지만, 판정을 요청하여 그 제안을 지지하려는 코어 개발자가 없으면 제안은 수락 단계로 나아갈 수 없습니다. 이는 본질적으로 현재 시스템과 동일하지만, CoA 위원이 최소 한 명의 코어 개발자의 지지도 받지 못한 제안을 다룰 것으로 기대되지 않도록 하기 위해 여기에서 명시적으로 밝힙니다.)
CoA는 코어 개발자 팀이 선출하지 않은 개인에게 권한을 위임할 수 없습니다. (이와 관련된 사례 하나는, 이것이 기존 BDFL-Delegate 시스템의 구현을 바꾼다는 것입니다. 다만 그 시스템의 취지까지 반드시 바꾸는 것은 아닙니다. 이 점에 대한 더 자세한 논의는 뒷부분, 특히 예시 시나리오 4를 참조하십시오.)
릴리스 관리자(RM)에게도 자신이 담당하는 릴리스를 명시한 모든 PEP에 대해 변경을 요청할 수 있는 동일한 권한이 주어집니다. 기능 동결 이후에도 RM은 자신의 릴리스에 대해 이 책임을 계속 지며, CoA는 교체되어 다음 릴리스에 집중하기 시작합니다. 이는 현재 프로세스와 다르지 않습니다. 이 제안은 RM 선정 프로세스를 변경하지 않습니다.
코어 개발자는 CoA 위원을 선출할 책임이 있으며, CoA 위원에 대해 “불신임 투표”를 발의할 수 있는 권한을 가집니다. 이러한 투표의 세부 사항은 뒷부분에서 다룹니다.
코어 개발자와 CoA 위원 간의 논의가 계속되고 있지만 성과가 없어 보이는 경우, 의장이 개입하여 어느 한쪽의 결정을 뒤집을 수 있습니다. 의장이 관련된 논의인 경우에는 불신임 투표로 처리해야 합니다.
CoA 구성원은 언제든지 사임할 수 있습니다. CoA 구성원이 적어도 두 명 남아 있다면, 그들은 그룹을 다시 채우기 위해 새로운 선거를 요청할 수 있습니다. 구성원이 한 명만 남으면 선거가 자동으로 시작됩니다. (의장이 사임하는 경우의 시나리오는 뒷부분에서 설명합니다.)
의도한 권력 균형은, 코어 개발자가 개발 팀의 방향성을 반영하고 팀의 신뢰를 받는 CoA 위원을 선출하며, 또한 선출 전에 한 약속을 지키지 않는 위원을 해임할 수 있는 권한도 가지는 것입니다.
일반적인 의사 결정 절차
일반 결정은 현재와 같은 방식으로 계속 이루어집니다.
명확히 하자면, 논쟁적 결정에는 PEP가 필요하며, PEP가 필요한 모든 결정은 논쟁적 결정으로 간주합니다.
어떤 결정을 논쟁적 결정 프로세스로 내리는 것이 더 나은지에 대해 CoA에 조언을 요청할 수 있고, CoA의 개별 구성원이 자발적으로 그러한 제안을 할 수도 있지만, 핵심 개발 팀은 이 조언에 구속되지 않습니다.
논쟁적인 사안의 의사 결정 절차
논쟁적 결정은 기존 프로세스에 따라 항상 PEP로 작성됩니다. 승인자(이전의 “BDFL-Delegate”)는 항상 CoA이며, 더 이상 위임할 수 없습니다. 이것이 CoA가 코어 개발자를 지명하여 제안을 평가하고 CoA에 권고안을 제출하도록 결정하는 것을 막지는 않는다는 점에 유의하십시오. 이는 본질적으로 현재의 위임 절차와 동일합니다.
CoA는 결정 공표 요청과 함께 python-committers에 제출된 PEP에 대해 결정을 공표합니다. CoA의 모든 구성원 또는 현재 RM은 어떠한 이유로든 PEP의 변경을 요청할 수 있습니다. 단, 자신의 기대를 충족하려면 어떤 추가 작업이 필요한지에 대한 설명을 함께 제시해야 합니다. 예상되는 이유의 예시는 뒤의 절들을 참조하십시오.
CoA의 모든 구성원과 RM이 PEP에 대해 우려 사항이 없다고 밝히면, 해당 PEP는 공식적으로 수락됩니다. CoA 구성원 중 한 명 이상이 합리적인 기간 안에 응답하지 않으면, CoA 의장은 이를 묵시적 승인으로 해석할 수 있습니다. 의장이 응답하지 않는 경우에는 불신임 투표로 처리해야 합니다.
선출 임기
CoA 구성원은 한 릴리스 기간 동안 재임하도록 선출됩니다. 구성원은 이전 릴리스의 기능 동결 전에 선출되며, 자신이 맡은 릴리스의 기능 동결 시점까지 그 직위를 유지합니다.
구성원은 원하는 만큼 몇 번이든 재선에 도전할 수 있습니다. 임기 제한은 없습니다. 특정 개인이 다시 재임해서는 안 된다는 합의가 있는 경우, 해당 CoA 구성원의 재선을 막는 것은 코어 개발자들의 몫입니다.
선거 투표 절차
CoA의 각 구성원에 대한 선거 절차는 다음과 같이 진행됩니다:
- python-committers에 추천 이메일을 보냅니다
- 재청 이메일을 보냅니다
- 후보자는 자신을 소개하고 입장을 밝히기 위한 목적으로 python-committers에 임시로 추가됩니다
- 투표는 이전 릴리스의 예정된 기능 동결 2주 전에 시작됩니다
- 투표는 비공개 github 저장소의 문서를 수정하는 방식으로 이루어집니다
- 각 코어 개발자는 원하는 만큼 많은 후보에게 +1 표를 줄 수 있습니다
- 7일이 지나면 투표가 마감됩니다
- 가장 많은 표를 받은 후보가 CoA 의장으로 선출됩니다
- 그다음으로 많은 표를 받았으면서 의장이 받은 표 수의 50% 이상을 받은 후보 세 명이 CoA의 나머지 구성원으로 선출됩니다
- 동점을 해소해야 하는 경우, RM은 자신이 선호하는 후보에게 추가로 한 표를 행사할 수 있습니다
- 선출된 후보는 python-committers에 남고, 나머지는 제거됩니다
불신임 투표 절차
불신임 투표는 다음과 같이 진행됩니다:
- python-committers에 불신임 투표 이메일을 보냅니다. 이 이메일에서는 대상 CoA 구성원을 지목하고 발의 근거를 제시하며, 발의자가 되돌려야 한다고 생각하는 수락된 PEP의 목록을 선택적으로 포함합니다
- 7일 이내에 재청 이메일을 보냅니다
- 지목된 CoA 구성원에게는 응답할 수 있도록 7일이 주어지며, 그 후 발의자나 재청자는 발의를 철회할 수 있습니다
- 발의자나 재청자가 남아 있지 않으면 더 이상의 조치는 취하지 않습니다
- 투표는 즉시 시작됩니다
- 각 코어 개발자는 비공개 GitHub 저장소의 문서를 수정하여 +1 표(CoA 구성원 해임) 또는 -1 표(CoA 구성원 유지)를 추가할 수 있습니다.
- 7일이 지나면 투표가 마감됩니다.
- +1 표가 -1 표보다 많으면 해당 CoA 구성원은 python-committers에서 제외되며, 지명된 PEP는 모두 되돌려집니다.
- CoA의 남은 구성원들이 요청하거나 CoA 구성원이 한 명만 남은 경우, 통상적인 절차에 따라 해임된 구성원을 대체할 새 선거를 치를 수 있습니다.
- CoA 의장을 해임하는 경우에는 원래 선거에서 두 번째로 많은 표를 받은 후보가 의장이 됩니다.
의도된 행동의 예
이 절에서는 CoA와 코어 개발자 사이에서 볼 수 있기를 바라는 상호작용의 몇 가지 예를 설명합니다. 이 중 어느 것도 구속력 있는 설명은 아니며, 우리가 기대하는 절차의 유형에 관해 어느 정도 합의를 이루기 위한 것입니다. CoA 후보는 자신이 선호하는 어떤 절차에 기반해서든 선거 운동을 할 수 있으며, 코어 개발자는 이를 근거로 표를 행사해야 합니다.
시나리오 1 - 모호한 PEP의 경우
과거에는 초기 제안이 제안자 이외의 사람이 구현할 수 있을 만큼 충분히 상세하지 않은 경우가 많았습니다. 이를 피하기 위해 CoA는 제안이 제출되면 암시된 맥락을 추론하거나 사용하지 않고 “처음 보는 것처럼” 읽어야 합니다. 그런 다음 PEP의 어떤 측면이 명확하지 않으면 CoA는 제안을 거부하고 명확히 해 줄 것을 요청할 수 있습니다.
제안이 거부되었으므로, 다시 검토받으려면 제안을 수정하여 재제출해야 합니다. CoA는 PEP를 거부할 때 어느 정도의 지침을 제공할지 결정합니다. 이는 PEP가 몇 번이나 재제출될지에 영향을 미치기(따라서 CoA 자신의 업무량에도 영향을 미치기) 때문입니다. 이렇게 하면 최종 PEP 문서가 필요한 모든 정보를 갖추고 그 자체로 완결성을 가지게 됩니다.
시나리오 2 - 끝없는 논의의 경우
때때로 Python 기여자 사이의 논의가 더 이상 가치를 제공하지 않는 것처럼 보일 수 있습니다. 예를 들어, 많은 이메일이 이미 다루어진 논점을 반복하거나 다른 사람에게 적극적으로 적대적일 때는 “논의”를 계속할 의미가 없습니다.
이러한 논의가 판정 요청의 일환으로 python-committers에서 벌어지고 있다면, CoA 구성원은 제안을 거부함으로써 스레드가 끝났음을 간단히 선언해야 합니다. 알려진 대부분의 경우, 이런 종류의 논의는 제안에서 모든 우려 사항이 충분히 다루어지지 않았음을 나타내며, 작성자가 일부 절을 보강해야 할 수도 있습니다.
또는 CoA의 다른 구성원들로부터 아무런 거부가 없는 경우, 의장은 제안을 수락함으로써 스레드가 끝났음을 선언할 수 있습니다. 이상적으로는 나머지 CoA 구성원 및 RM에게 그들 사이에 우려 사항이 없음을 직접 확인한 후에 이렇게 해야 합니다.
이러한 논의가 다른 메일링 리스트에서 벌어지고 있다면, CoA 구성원은 다른 코어 개발자(특히 해당 주제 영역의 전문가로 지명된 코어 개발자)와 마찬가지로 존중받는 의견을 내는 사람으로 여겨져야 합니다. 누구도 스레드를 끝낼 특별한 권한을 가지고 있지는 않지만, 제안을 막겠다는 의사를 미리 밝히는 것은 무익해질 수 있는 논의를 진정시키는 유용한 방법입니다. python-committers 이외의 곳에서 벌어지는 논의를 자발적으로 지켜보는 CoA 구성원은 제안자에게 철회를 권할 수 있지만, 실제로 승인하거나 거부할 수 있는 것은 판정을 위해 정식으로 제출된 제안뿐입니다.
시나리오 3 - 고려되지 않은 사용자의 경우
과거의 일부 제안은 특정 사용자 그룹에 미치는 영향을 고려하지 않은 채 작성되어 판정을 위해 제출되었을 수 있습니다. 예를 들어, 다양한 기기에서 Python을 사용하는 데 필요한 의존성에 영향을 주는 제안은, 해당 의존성이 보통 기본적으로 제공되어 많은 사용자가 영향을 받지 않더라도 일부 사용자에게는 부정적인 영향을 미칠 수 있습니다.
제안이 모든 사용자를 고려하지 않은 것으로 보이는 경우, CoA는 자신의 판단과 과거 경험을 활용하여 PEP에 기술된 것보다 더 많은 사용자가 변경의 영향을 받는다고 판단하고, PEP가 이러한 사용자도 다루도록 요청할 수 있습니다. CoA는 제안자도 해당 사용자를 식별할 수 있을 만큼 사용자 그룹을 명확하게 지목해야 하며, 제안자는 그 사용자들을 어떻게 다루었는지 명확히 밝히거나 PEP를 수정하여 그들을 명시적으로 다루어야 합니다. (이는 다양한 사용자 그룹에 대한 기능의 유용성을 평가하는 것이 아니라, 단지 기능의 유용성이 평가되었음을 PEP가 보여 주는지를 확인하는 것임에 유의하십시오.)
제안이 결함 있는 논리나 잘못된 데이터를 근거로 특정 결론에 도달한 것으로 보이는 경우, CoA는 다른 정보원(이전 논의나 다른 코어 개발자의 제출 의견 등)을 활용하여 특정 사항의 재검토를 요청할 수 있습니다. 제안자가 제안을 수정할 때 CoA가 확보한 정보를 반드시 그대로 사용할 필요는 없으며, 어떤 수정이든 CoA가 만족하기만 하면 됩니다. 예를 들어, PEP에서는 사용자의 30%가 영향을 받는다고 밝히는 반면, CoA는 사용자의 70%가 영향을 받는다고 주장할 수 있습니다. 성공적인 수정안은 다르지만 더 신뢰할 수 있는 비율을 제시할 수도 있고, 영향을 받는 사용자 수에 더 이상 의존하지 않도록 다시 작성될 수도 있습니다.
시나리오 4 - 위임된 결정의 사례
일부 제안은 해당 분야 전문가의 검토와 승인이 필요할 수 있습니다. 과거에는 이러한 제안에 대해 BDFL-Delegate를 임명하여 최종 결정을 내리게 하는 방식으로 처리했습니다. 그러나 이 모델에서 CoA는 최종 의사 결정 과정을 위임할 수 없습니다. 특정 제안에 대해 해당 주제의 전문가가 결정해야 한다고 CoA가 판단하는 경우, CoA는 한 명 이상의 사람을 BDFL Delegate와 유사한 역할에 지명할 수 있습니다(또는 그들의 자기 추천을 받아들일 수 있습니다). 이러한 전문가의 역할 조건은 CoA가 적절하다고 판단하는 대로 정할 수 있지만, 최종 승인 권한은 항상 CoA에게 있습니다.
구체적인 예로, 새로운 언어 기능에 관한 제안이 논의되고 있다고 가정해 봅시다. 지지자들은 이 기능이 새로운 개발자가 언어를 더 쉽게 배울 수 있게 해 줄 것이라고 주장합니다. 공식 제안이 이루어지기 전이라도, CoA는 X라는 사람이 승인하지 않는 한 제안을 수락하지 않겠다는 뜻을 밝힐 수 있습니다. X는 오랫동안 Python을 가르쳐 왔고 그 판단을 신뢰받고 있기 때문입니다. (X가 코어 개발자일 필요는 없다는 점에 유의하십시오.)
이 역할을 맡은 X는 논의를 주도하며 실현 가능한 대안에 논의의 초점을 빠르게 맞출 수 있습니다. 결국 X는 자신이 가장 만족하는 대안을 선택하고 CoA에 승인 의사를 밝힙니다. 제안은 평소와 같이 제출되며, CoA는 X의 의견을 고려하여 제안을 검토하고 수락합니다.
Copyright
This document has been placed in the public domain.