Following system colour scheme Selected dark colour scheme Selected light colour scheme

Python 개선 제안 한국어 번역

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

Author:
Steve Dower <steve.dower at python.org>
Status:
Rejected
Type:
Informational
Topic:
Governance
Created:
14-Sep-2018
Table of Contents

번역·라이선스 안내

이 비공식 한국어 번역은 원문 Copyright 절의 Public Domain 조건에 따라 제공합니다. 원저자와 공식 원문은 그대로 표시합니다. 수정되지 않은 기준 원문 · 공식 최신판

초록

이 PEP는 언어에 대한 최종 결정을 내리는 역할을 맡은 감사 위원회(CoA)를 기반으로 하는 새로운 파이썬 거버넌스 모델을 제안합니다. 이는 중앙의 단일 리더를 구체적으로 제안하지 않는다는 점에서 PEP 8010과 다르며, 핵심 커미터가 위원회 구성원이 되는 것을 허용하지 않는다는 점에서 PEP 8011과 다릅니다. 이 문서는 위원회의 규모와 역할, 최초 위원회 구성원을 선정하는 방법, 위원회 구성원의 임기 제한 여부, 후임자를 선출하는 방법을 설명합니다.

또한 이 모델의 의도된 동작을 논의하는 데 상당한 분량을 할애합니다. 설계상 많은 절차는 여기에서 명시하지 않고 관련된 사람들에게 맡깁니다. 최선의 결정을 내릴 사람들을 선정하려면 관련된 사람들이 CoA의 기대 사항을 이해하는 것이 중요하지만, 다양한 상황에 맞게 절차 요구 사항을 조정할 자유를 CoA에 허용하는 것 또한 그에 못지않게 중요합니다. 이는 절차를 명시하지 않으면서 모든 참여자가 비슷한 기대를 가질 때에만 작동합니다.

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

PEP 거부

PEP 8013은 2018년 12월 17일 월요일에 PEP 8001에 설명된 핵심 개발자 투표에 의해 거부되었습니다.

대신 PEP 8016 및 해당 PEP가 설명하는 거버넌스 모델이 선택되었습니다.

모호한 영역의 중요성

실제 의사 결정 과정에는 어떤 경우든 모호한 영역이 존재합니다. 여기에는 예상하지 못한 상황과 “올바른” 답이 없는 경우가 포함됩니다.

많은 절차 계획은 유연성이 필요하지 않을 정도로 절차를 명확하게 정의하여 모호한 영역을 최소화하려고 합니다.

이 제안은 의도적으로 반대 방향으로 나아갑니다. 그 목적은 예상하지 못한 상황을 처리할 최선의 사람들을 선정하기 위한 견고한 틀을 제공하되, 그러한 사람들이 그 상황을 어떻게 처리해야 하는지는 정의하지 않는 것입니다.

일부 상황에 대한 “좋은” 대응을 예시로 보여 주기 위해 사례를 제시합니다. “최선의” 사람들이 최선인 이유는 그러한 사례에 부응할 것이기 때문이라는 것이 기대됩니다. 제안된 절차는 그러한 사람들이 최선의 사람들이 아닌 것으로 드러났을 때 발생할 수 있는 피해를 최소화하도록 설계되었습니다.

모호한 영역은 반드시 존재합니다. 이 제안은 이를 방지하려고 하기보다는 의도적으로 받아들이고 그 안에서 작동합니다.

모델 개요

주요 인물과 그 기능

감사 위원회(CoA)는 규모가 달라질 수 있는 위원회로, 일반적으로 두 명에서 네 명으로 구성되며 파이썬 릴리스 기간 동안 선출됩니다. CoA의 한 구성원은 의장으로 간주되며, 다른 구성원에 대해 일부 사소한 권한을 가집니다.

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

CoA는 python-committers에 제출된 PEP에 대해서만 판정을 내립니다. CoA가 다른 메일링 리스트를 구독하거나 참여할 것이라는 기대는 없습니다. (이는 PEP를 제출할 수 있는 사람이 핵심 개발자뿐임을 의미한다는 점에 유의하십시오. 비핵심 개발자는 다른 메일링 리스트에서 제안서를 작성하고 논의할 수 있지만, 판정을 요청하여 제안서를 기꺼이 지원할 핵심 개발자가 없으면 해당 제안서는 수락 절차로 진행될 수 없습니다. 이는 본질적으로 현재 시스템과 동일하지만, CoA 구성원이 적어도 한 명의 핵심 개발자의 지원을 받지 못한 제안서를 처리할 것으로 기대되지 않음을 명확히 하기 위해 여기에서 명시적으로 밝힙니다.)

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

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

핵심 개발자는 CoA 구성원을 선출할 책임이 있으며, CoA 구성원에 대해 “신임 투표”를 요구할 수 있습니다. 이러한 투표의 세부 사항은 뒷부분에서 논의합니다.

핵심 개발자와 CoA 구성원 간의 논의가 계속되고 있지만 성과가 없는 것으로 보이는 경우, President가 개입하여 어느 한쪽의 결정을 번복할 수 있습니다. 논의에 President가 관련된 경우에는 신임 투표를 통해 처리해야 합니다.

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

의도한 권력의 균형은 핵심 개발자가 개발 팀의 방향을 반영하고 팀의 신뢰를 받는 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에 남고, 나머지는 제거됩니다.

불신임 투표 절차

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

  • 영향을 받는 CoA 구성원을 지명하고, 지명의 근거를 제시하며, 지명자가 되돌려야 한다고 생각하는 승인된 PEP를 선택적으로 열거하는 불신임 투표 이메일을 python-committers에 보냅니다.
  • 7일 이내에 추천 지지 이메일을 보냅니다.
  • 지명된 CoA 구성원에게는 응답할 수 있는 7일이 주어지며, 그 후 지명자 또는 추천 지지자는 철회할 수 있습니다.
  • 지명자나 추천 지지자가 없으면 추가 조치를 취하지 않습니다.
  • 투표는 즉시 시작됩니다.
  • 각 핵심 개발자는 비공개 GitHub 저장소의 문서를 수정하여 +1 투표(CoA 구성원 제거) 또는 -1 투표(CoA 구성원 유지)를 추가할 수 있습니다.
  • 7일이 지나면 투표가 종료됩니다.
  • +1 투표가 -1 투표를 초과하면 CoA 구성원이 python-committers에서 제거되고, 추천된 PEP는 모두 되돌려집니다.
  • 남은 CoA 구성원이 요청하거나 CoA 구성원이 한 명만 남은 경우, 일반적인 절차에 따라 제거된 구성원을 대신할 새로운 선거를 실시할 수 있습니다.
  • CoA 의장을 제거하는 경우에는 원래 두 번째로 많은 표를 받은 후보자가 의장이 됩니다.

의도된 동작의 예

이 절에서는 CoA와 핵심 개발자 간에 기대하는 상호 작용의 유형에 관한 몇 가지 예를 설명합니다. 이러한 설명은 어느 것도 구속력을 갖지 않지만, 우리가 기대하는 프로세스 유형에 대해 어느 정도 합의를 이루기 위한 것입니다. CoA 후보자는 자신이 선호하는 어떤 절차를 기반으로든 선거 운동을 할 수 있으며, 핵심 개발자는 이를 바탕으로 투표를 배분해야 합니다.

시나리오 1 - 모호한 PEP의 경우

과거에는 초기 제안에 제안자 이외의 사람이 구현하기에 충분한 세부 사항이 부족한 경우가 많았습니다. 이를 방지하기 위해 CoA는 제안이 제출될 때 이를 “fresh”하게, 즉 어떤 암시된 맥락도 추론하거나 사용하지 않고 읽어야 합니다. 그런 다음 PEP의 어떤 측면이 명확하지 않을 때 CoA는 제안을 거부하고 명확한 설명을 요청할 수 있습니다.

제안이 거부되었으므로 다시 검토받으려면 수정하여 재제출해야 합니다. CoA는 PEP를 거부할 때 제공할 지침의 정도를 결정하며, 이는 PEP가 재제출될 가능성이 있는 횟수와 그에 따른 CoA 자체의 업무량에 영향을 줍니다. 이를 통해 최종 PEP 문서가 필요한 모든 정보를 갖추고 독립적으로 이해될 수 있게 됩니다.

시나리오 2 - 끝없는 논의의 경우

때때로 Python 기여자 간의 논의가 더 이상 가치를 제공하지 않는 것처럼 보일 수 있습니다. 예를 들어 이미 다룬 요점을 반복하는 이메일이 대량으로 오가거나 다른 사람에게 적극적으로 적대적인 경우에는 “논의”를 계속할 이유가 없습니다.

판정 요청의 일환으로 이러한 논의가 python-committers에서 진행 중이라면, CoA 구성원은 제안을 거부하여 해당 스레드가 끝났다고 단순히 선언해야 합니다. 알려진 대부분의 경우, 이러한 논의는 제안에서 모든 우려 사항이 충분히 다뤄지지 않았음을 나타내며, 작성자가 일부 섹션을 보완해야 할 수 있습니다.

또는 CoA의 다른 구성원들이 거부하지 않는 경우, 의장은 제안을 수락하여 해당 스레드가 끝났다고 선언할 수 있습니다. 이상적으로는 CoA의 나머지 구성원 및 RM과 직접 확인하여 그들 사이에 우려 사항이 없음을 확인한 후에 이를 수행해야 합니다.

다른 목록에서 이러한 논의가 진행 중인 경우, CoA 구성원은 다른 핵심 개발자, 특히 해당 주제 영역의 담당 전문가로 명시된 핵심 개발자와 유사한 존중받는 의견을 가진 사람으로 간주되어야 합니다. 누구에게도 스레드를 종료할 특정 권한은 없지만, 제안을 차단할 의사가 있음을 선제적으로 밝히는 것은 잠재적으로 무익한 논의를 완화하는 유용한 방법입니다. python-committers 이외의 곳에서 진행되는 논의를 자발적으로 따르는 CoA 구성원은 제안자에게 철회를 제안할 수 있지만, 공식적으로 판정을 요청하기 위해 제출된 제안만 실제로 승인하거나 거부할 수 있습니다.

시나리오 3 - 고려되지 않은 이용자의 경우

과거에는 특정 이용자 집단에 미칠 영향을 고려하지 않은 채 일부 제안이 작성되어 판정 요청을 위해 제출되었을 수 있습니다. 예를 들어 여러 컴퓨터에서 Python을 사용하는 데 필요한 의존성에 영향을 미치는 제안은, 많은 이용자가 의존성을 일반적으로 기본 제공받아 영향을 받지 않더라도 일부 이용자에게 부정적인 영향을 미칠 수 있습니다.

제안이 모든 이용자를 고려하지 않은 것으로 보이는 경우, CoA는 판단과 과거 경험을 활용하여 변경 사항의 영향을 받는 이용자가 PEP에 설명된 것보다 많다고 판단하고, PEP에서 이러한 이용자도 다루도록 요청할 수 있습니다. 제안자가 이러한 이용자도 식별할 수 있을 정도로 이용자 집단을 명확히 식별하고, 해당 이용자들에게 어떻게 대응했는지 명확히 설명하거나 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의 의견을 고려하여 이를 검토하고 수락합니다.