[Rejected] PEP 8013 - The External Council Governance Model

원문 링크: PEP 8013 - The External Council Governance Model

상태: Rejected 유형: Informational 작성일: 14-Sep-2018

PEP 8013 – 외부 위원회 거버넌스 모델

  • 작성자: Steve Dower
  • 상태: Rejected (거부됨)
  • 유형: Informational (정보성)
  • 주제: Governance (거버넌스)
  • 작성일: 2018년 9월 14일

개요 (Abstract)

이 PEP는 Python 언어의 최종 의사결정을 담당하는 감사 위원회(Council of Auditors, CoA)를 기반으로 하는 새로운 Python 거버넌스 모델을 제안합니다. 이는 중앙 집중적인 단일 리더를 제안하지 않는다는 점에서 PEP 8010과 다르며, 핵심 커미터(core committers)가 위원회 구성원이 되는 것을 허용하지 않는다는 점에서 PEP 8011과 다릅니다. 이 문서는 위원회의 규모와 역할, 초기 위원회 구성원 선정 방식, 위원회 구성원의 임기 제한, 그리고 후임자 선출 방식에 대해 설명합니다.

또한, 이 모델의 의도된 행동 방식에 대해 상당한 시간을 할애하여 논의합니다. 많은 프로세스는 명시적으로 지정되지 않고 관련된 사람들에게 맡겨집니다. 최선의 결정을 내릴 사람들을 선택하기 위해서는 관련자들이 CoA의 기대를 이해하는 것이 중요하며, 동시에 CoA가 다양한 상황에 따라 프로세스 요구 사항을 조정할 자유를 허용하는 것도 중요합니다. 이는 프로세스가 명시되지 않았지만 모든 참여자가 유사한 기대를 가질 때만 작동합니다.

이 PEP는 CoA의 구성원 이름을 명시하지 않습니다. 이 모델이 채택된다면, 이 PEP에 설명된 모든 직책 보유자의 이름과 함께 PEP 13에 명문화될 것입니다.

PEP 거부 (PEP Rejection)

PEP 8013은 2018년 12월 17일 월요일에 PEP 8001에 설명된 핵심 개발자 투표를 통해 거부되었습니다. 대신 PEP 8016과 그에 설명된 거버넌스 모델이 선택되었습니다.

회색 영역의 중요성 (The Importance of the Grey Area)

실제 의사결정 과정에서는 항상 회색 영역(grey area)이 존재하기 마련입니다. 여기에는 예상치 못한 시나리오와 “정답”이 없는 경우가 포함됩니다.

많은 프로세스 계획은 유연성이 필요하지 않을 정도로 프로세스를 명확하게 정의하여 회색 영역을 최소화하려고 시도합니다.

이 제안은 의도적으로 그 반대의 길을 택합니다. 목표는 예상치 못한 상황을 처리할 최적의 인력을 선택하기 위한 강력한 프레임워크를 제공하는 것이며, 그 사람들이 그러한 상황을 어떻게 처리해야 하는지는 정의하지 않는 것입니다.

몇몇 상황에 대한 “좋은” 반응의 예시가 설명을 위해 제공됩니다. “최적의” 사람들이 이러한 예시에 부합하는 행동을 할 것이라는 희망이 있습니다. 제안된 프로세스는 그러한 사람들이 최적의 인력이 아닐 경우 발생할 수 있는 피해를 최소화하도록 설계되었습니다.

회색 영역은 항상 존재할 수밖에 없습니다. 이 제안은 이를 방지하려고 하기보다는 의도적으로 수용하고 그 안에서 작동합니다.

모델 개요 (Model Overview)

주요 인물과 그들의 기능 (Key people and their functions)

감사 위원회 (Council of Auditors, CoA)는 Python 릴리스 기간 동안 선출되는 두 명에서 네 명의 가변적인 인원으로 구성된 위원회입니다. CoA의 한 구성원은 회장(President)으로 간주되며, 다른 구성원에 비해 약간의 권한을 가집니다.

CoA는 핵심 개발팀(core development team) 구성원이 작성한 PEP 형태로 논란이 되는 결정을 검토할 책임이 있습니다. CoA는 PEP를 제출된 그대로 수락하거나, 설명이나 변경을 요청할 수 있습니다. 이러한 변경 요청은 어떤 형태나 이유로든 가능합니다. 이러한 유연성은 의도된 것이며, CoA에 다른 구성원들이 선출됨에 따라 프로세스가 시간이 지남에 따라 변경될 수 있도록 합니다. 예상되는 요청 유형의 예시는 이 문서의 뒷부분에서 확인할 수 있습니다.

CoA는 python-committers 메일링 리스트에 제출된 PEP에 대해서만 의견을 표명합니다. CoA가 다른 메일링 리스트를 팔로우하거나 참여할 것이라는 기대는 없습니다. (이것은 핵심 개발자(core developers)만이 PEP를 제출할 수 있음을 의미합니다. 비핵심 개발자는 다른 메일링 리스트에서 제안서를 작성하고 논의할 수 있지만, 핵심 개발자가 제안을 지지하고 의견 표명을 요청하지 않는 한 수락 절차를 진행할 수 없습니다. 이는 본질적으로 현재 시스템과 동일하지만, CoA 구성원이 최소 한 명의 핵심 개발자에 의해 지지되지 않는 제안을 처리할 것으로 기대되지 않도록 하기 위해 여기에서 명시적으로 언급됩니다.)

CoA는 핵심 개발자 팀에 의해 선출되지 않은 개인에게 권한을 위임할 수 없습니다. (여기서 관련 사례 중 하나는 기존 BDFL-Delegate 시스템의 구현이 변경되지만, 반드시 해당 시스템의 정신이 변경되는 것은 아닙니다. 이 점에 대한 자세한 논의는 뒷부분, 특히 시나리오 4를 참조하십시오.)

릴리스 관리자 (Release Manager, RM)도 자신이 책임지는 릴리스를 명시하는 모든 PEP에 대해 변경을 요청할 수 있는 동일한 권한을 가집니다. 기능 동결(feature freeze) 이후, RM은 해당 릴리스에 대한 책임을 유지하며, CoA는 교체되어 다음 릴리스에 집중하기 시작합니다. 이는 현재 프로세스와 다르지 않습니다. RM 선정 프로세스는 이 제안에서 변경되지 않습니다.

핵심 개발자 (Core developers)는 CoA 구성원을 선출할 책임이 있으며, CoA 구성원에 대해 “불신임 투표(vote of no confidence)”를 발의할 수 있는 능력을 가집니다. 이러한 투표의 세부 사항은 뒷부분에서 논의됩니다.

핵심 개발자와 CoA 구성원 간의 논의가 계속되고 있지만 성과가 없을 경우, 회장이 개입하여 양측 중 어느 한쪽에 우선권을 부여할 수 있습니다. 논의에 회장이 관여하는 경우, 불신임 투표를 통해 처리해야 합니다.

CoA 구성원은 언제든지 사임할 수 있습니다. CoA에 최소 두 명의 구성원이 남아 있다면, 그룹을 재충원하기 위한 새로운 선거를 요청할 수 있습니다. 한 명만 남을 경우, 선거는 자동으로 시작됩니다. (회장이 사임하는 시나리오는 뒷부분에서 설명됩니다.)

의도된 권력 균형은 핵심 개발자들이 개발팀의 방향을 반영하고 신뢰를 얻으며, 선거 전에 한 약속을 지키지 않는 구성원을 해임할 수 있는 CoA 구성원을 선출하는 것입니다.

일반적인 의사결정 과정 (Regular decision process)

일반적인 결정은 현재와 동일하게 계속해서 이루어집니다. 명확성을 위해, 논란이 되는 결정은 PEP를 필요로 하며, PEP를 필요로 하는 모든 결정은 논란이 되는 것으로 간주됩니다. CoA는 어떤 결정이 논란이 되는 결정 과정을 통해 이루어지는 것이 더 나은지 조언을 요청받을 수 있으며, CoA의 개별 구성원이 그러한 제안을 자원할 수도 있지만, 핵심 개발팀은 이 조언에 구속되지 않습니다.

논란이 되는 의사결정 과정 (Controversial decision process)

논란이 되는 결정은 항상 기존 프로세스를 따라 PEP로 작성됩니다. 승인자(approver) (이전 “BDFL-Delegate”)는 항상 CoA이며, 더 이상 위임될 수 없습니다. 이는 CoA가 제안을 평가하고 CoA에 권고를 제공할 핵심 개발자를 지명하는 것을 막지 않으며, 이는 본질적으로 현재 위임 프로세스와 동일하다는 점에 유의하십시오.

CoA는 python-committers에 제출되어 의견 표명을 요청한 PEP에 대해 의견을 표명합니다. CoA의 모든 구성원 또는 현재 RM은 자신의 기대를 충족하기 위해 필요한 추가 작업이 무엇인지에 대한 일부 표시를 포함하는 한, 어떤 이유로든 PEP에 대한 변경을 요청할 수 있습니다. 예상되는 이유의 예시는 뒷부분에서 확인할 수 있습니다.

CoA의 모든 구성원과 RM이 PEP에 대한 우려가 없음을 표시하면, PEP는 공식적으로 수락됩니다. 한 명 이상의 CoA 구성원이 합리적인 시간 내에 응답하지 않으면, CoA 회장은 이를 묵시적 승인으로 해석할 수 있습니다. 회장이 응답하지 않는 것은 불신임 투표를 통해 처리되어야 합니다.

선거 임기 (Election terms)

CoA 구성원은 릴리스 기간 동안 선출됩니다. 구성원은 이전 릴리스의 기능 동결(feature freeze) 이전에 선출되며, 해당 릴리스의 기능 동결까지 직책을 유지합니다.

구성원은 원하는 만큼 재선에 출마할 수 있습니다. 임기 제한은 없습니다. 개인이 다시 봉사해서는 안 된다는 합의가 있을 경우, 핵심 개발자들이 CoA 구성원의 재선을 막는 것은 그들의 몫입니다.

선거 투표 과정 (Election voting process)

CoA 각 구성원에 대한 선거 과정은 다음과 같이 진행됩니다.

  • python-committers에 지명 이메일이 발송됩니다.
  • 지지 이메일이 발송됩니다.
  • 후보자는 자신을 소개하고 자신의 입장을 발표하기 위해 일시적으로 python-committers에 추가됩니다.
  • 투표는 이전 릴리스의 예정된 기능 동결 2주 전에 시작됩니다.
  • 투표는 비공개 GitHub 저장소의 문서를 수정하여 이루어집니다.
  • 각 핵심 개발자는 원하는 만큼의 후보자에게 +1 표를 추가할 수 있습니다.
  • 7일 후, 투표가 마감됩니다.
  • 가장 많은 표를 얻은 후보자가 CoA 회장으로 선출됩니다.
  • 그 다음으로 많은 표를 얻고 회장이 받은 표 수의 50% 이상을 받은 세 명의 후보자가 CoA의 다른 구성원으로 선출됩니다.
  • 동점(ties)을 해결해야 하는 경우, RM은 자신이 선호하는 후보자에게 한 표를 더 줄 수 있습니다.
  • 수락된 후보자는 python-committers에 남아 있고, 나머지는 제거됩니다.

불신임 투표 과정 (No-confidence voting process)

불신임 투표는 다음과 같이 진행됩니다.

  • python-committers에 불신임 투표 이메일이 발송됩니다. 이 이메일에는 해당 CoA 구성원의 이름, 지명 사유, 그리고 지명자가 되돌려야 한다고 생각하는 수락된 PEP 목록(선택 사항)이 포함됩니다.
  • 7일 이내에 지지 이메일이 발송됩니다.
  • 지명된 CoA 구성원은 7일 동안 답변할 수 있으며, 그 후 지명자 또는 지지자가 철회할 수 있습니다.
  • 지명자나 지지자가 없는 경우, 추가 조치는 취해지지 않습니다.
  • 투표가 즉시 시작됩니다.
  • 각 핵심 개발자는 비공개 GitHub 저장소의 문서를 수정하여 +1 표(CoA 구성원 해임) 또는 -1 표(CoA 구성원 유지)를 추가할 수 있습니다.
  • 7일 후, 투표가 마감됩니다.
  • +1 표가 -1 표를 초과하는 경우, CoA 구성원은 python-committers에서 제거되며, 지명된 PEP는 남은 CoA 구성원의 요청이 있거나 CoA 구성원이 한 명만 남은 경우 되돌려질 수 있습니다.
  • 제거된 구성원을 대체하기 위한 새로운 선거는 일반적인 절차에 따라 개최될 수 있습니다.
  • CoA 회장이 제거되는 경우, 원래 두 번째로 많은 표를 얻은 후보자가 회장이 됩니다.

의도된 행동 방식의 예시 (Examples of intended behaviour)

이 섹션에서는 CoA와 핵심 개발자 간에 우리가 기대하는 상호작용의 몇 가지 예를 설명합니다. 이들 중 어느 것도 구속력 있는 설명은 아니지만, 우리가 기대하는 프로세스 유형에 대한 합의를 이루기 위한 것입니다. CoA 후보자들은 자신이 선호하는 프로세스를 기반으로 캠페인을 벌일 수 있으며, 핵심 개발자들은 이를 바탕으로 투표를 할당해야 합니다.

시나리오 1 - 모호한 PEP의 경우 (Scenario 1 - The Case of the Vague PEP)

과거에는 초기 제안서가 제안자 외에는 누구도 구현할 수 없을 정도로 세부 사항이 부족한 경우가 많았습니다. 이를 피하기 위해, CoA는 PEP가 제출될 때 “새로운 시각”으로 읽어야 하며, 암시적인 맥락을 추론하거나 사용해서는 안 됩니다. 그런 다음, PEP의 어떤 측면이 명확하지 않을 때, CoA는 제안을 거부하고 설명을 요청할 수 있습니다.

제안이 거부되었으므로, 다시 검토받기 위해서는 수정하여 재제출되어야 합니다. CoA는 PEP를 거부할 때 얼마나 많은 지침을 제공할지 결정할 것입니다. 이는 재제출될 가능성이 있는 횟수(그리고 CoA의 작업량)에 영향을 미치기 때문입니다. 이는 최종 PEP 텍스트가 필요한 모든 정보와 함께 독립적으로 존재하도록 보장합니다.

시나리오 2 - 끝없는 논의의 경우 (Scenario 2 - The Case of the Endless Discussion)

때때로 Python 기여자들 간의 논의가 더 이상 가치를 제공하지 않는 것처럼 보일 수 있습니다. 예를 들어, 많은 이메일이 이미 다루어진 요점을 반복하거나 다른 사람들에게 적극적으로 적대적일 때, “논의”를 계속하는 것은 무의미합니다.

의견 표명 요청의 일부로 python-committers에서 이러한 논의가 발생할 경우, CoA 구성원은 제안을 거부함으로써 간단히 스레드(thread)가 끝났음을 선언해야 합니다. 알려진 대부분의 경우, 이러한 종류의 논의는 모든 우려가 제안서에서 충분히 다루어지지 않았으며, 저자가 일부 섹션을 보완해야 할 수도 있음을 나타냅니다.

대안으로, 다른 CoA 구성원의 거부가 없는 경우, 회장은 제안을 수락함으로써 스레드가 끝났음을 선언할 수 있습니다. 이상적으로는 이는 나머지 CoA와 RM에게 우려 사항이 없음을 직접 확인한 후에 이루어져야 합니다.

다른 목록에서 이러한 논의가 발생할 경우, CoA 구성원은 다른 핵심 개발자(특히 해당 주제 영역의 전문가로 지명된 핵심 개발자)와 유사하게 존경받는 의견으로 간주되어야 합니다. 스레드를 끝낼 특정 권한은 없지만, 제안을 차단할 의도를 미리 밝히는 것은 잠재적으로 무의미한 논의를 해소하는 유용한 방법입니다. python-committers 외의 논의를 자발적으로 따르는 CoA 구성원은 제안자에게 철회를 제안할 수 있지만, 공식적으로 의견 표명을 위해 제출된 제안만 실제로 승인하거나 거부할 수 있습니다.

시나리오 3 - 고려되지 않은 사용자들의 경우 (Scenario 3 - The Case of the Unconsidered Users)

과거 일부 제안은 특정 사용자 그룹에 미치는 영향을 고려하지 않고 작성되어 의견 표명을 위해 제출될 수 있습니다. 예를 들어, 다양한 머신에서 Python을 사용하는 데 필요한 의존성(dependencies)에 영향을 미치는 제안은 기본적으로 의존성이 일반적으로 사용 가능하므로 많은 사용자가 영향을 받지 않더라도 일부 사용자에게는 부정적인 영향을 미칠 수 있습니다.

제안이 모든 사용자를 고려하지 않은 것으로 보일 경우, CoA는 판단과 과거 경험을 사용하여 PEP에 설명된 것보다 더 많은 사용자가 변경 사항의 영향을 받는다고 판단하고, PEP가 이러한 사용자도 다룰 것을 요청할 수 있습니다. 그들은 제안자가 이러한 사용자를 식별하고, 어떻게 다루어졌는지 명확히 설명하거나, PEP를 수정하여 명시적으로 다룰 수 있도록 충분히 명확하게 사용자 그룹을 식별해야 합니다. (이것은 다양한 사용자 그룹에 대한 기능의 유용성을 평가하는 것이 아니라, 단순히 PEP가 기능의 유용성이 평가되었음을 나타내는지 여부를 평가하는 것임에 유의하십시오.)

제안이 특정 결론에 도달하기 위해 결함 있는 논리나 부정확한 데이터를 사용한 것으로 보일 경우, CoA는 다른 정보원(예: 이전 논의 또는 다른 핵심 개발자의 제출물)을 사용하여 특정 요점을 재고할 것을 요청할 수 있습니다. 제안자는 CoA가 얻은 정확한 정보를 사용하여 제안을 업데이트할 필요는 없지만, CoA가 만족하는 수정 사항을 제공해야 합니다. 예를 들어, PEP는 사용자 30%가 영향을 받을 것이라고 나타낼 수 있지만, CoA는 사용자 70%가 영향을 받는다고 주장할 수 있습니다. 성공적인 수정에는 다르지만 더 신뢰할 수 있는 백분율이 포함되거나, 영향을 받는 사용자 수에 더 이상 의존하지 않도록 다시 작성될 수 있습니다.

시나리오 4 - 위임된 결정의 경우 (Scenario 4 - The Case of the Delegated Decision)

일부 제안은 해당 분야 전문가의 검토 및 승인을 필요로 할 수 있습니다. 역사적으로, 이러한 제안은 BDFL-Delegate를 임명하여 제안에 대한 최종 결정을 내리도록 처리되었습니다. 그러나 이 모델에서는 CoA가 최종 의사결정 과정을 위임할 수 없습니다. CoA가 주제 전문가가 특정 제안에 대해 결정해야 한다고 생각할 때, CoA는 한 명 이상의 개인을 BDFL-Delegate와 유사한 직책에 지명하거나(또는 자원하는 것을 수락) 할 수 있습니다. 이러한 전문가 역할의 조건은 CoA가 적절하다고 판단하는 대로 설정될 수 있지만, CoA는 항상 최종 승인 권한을 유지합니다.

구체적인 예를 들어, 새로운 언어 기능에 대한 제안이 논의되고 있다고 가정해 봅시다. 제안자들은 이 기능이 새로운 개발자들이 언어를 배우기 더 쉽게 만들 것이라고 주장합니다. 공식적인 제안이 이루어지기 전에도 CoA는 X라는 사람이 Python을 가르친 오랜 역사를 가지고 있고 그의 판단이 신뢰할 수 있으므로, X가 승인하지 않는 한 제안을 수락하지 않을 것이라고 밝힐 수 있습니다. (X라는 사람이 핵심 개발자일 필요는 없다는 점에 유의하십시오.)

이 역할을 부여받은 X는 논의를 주도하고 실현 가능한 대안에 신속하게 집중할 수 있습니다. 결국, X는 자신이 가장 만족하는 대안을 선택하고 CoA에게 승인했음을 알립니다. 제안은 평소와 같이 제출되고, CoA는 X의 의견을 고려하여 검토하고 수락합니다.

이 문서는 퍼블릭 도메인에 공개되었습니다. 원문: https://github.com/python/peps/blob/main/peps/pep-8013.rst 최종 수정일: 2025-02-01 08:55:40 GMT

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

Comments