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

Python 개선 제안 한국어 번역

PEP 8014 – Commons 거버넌스 모델

Author:
Jack Jansen
Status:
Rejected
Type:
Informational
Topic:
Governance
Created:
16-Sep-2018
Table of Contents

번역·라이선스 안내

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

초록

이 PEP는 절차, 정의된 용어 및 백분율을 가능한 한 적게 사용하는 거버넌스 모델을 제안합니다. 이를 무정부주의자 거버넌스 모델이라고 부를 수도 있지만, 일부 독자에게 무정부주의자라는 용어가 부정적인 연상을 일으킬 수 있으므로 현재는 Commons를 사용합니다.

기본 아이디어는 모든 결정이 원칙적으로 전체 커뮤니티의 투표로 결정되지만, 실제로는 커뮤니티의 일부만 투표한다는 것입니다. 일부라는 것은, 전체 커뮤니티가 투표할 권리를 가지더라도 실제로는 특정 결정에 투표하는 사람이 언제나 소수의 일부에 불과하기 때문입니다. 투표는 결정이 통과되었는지 여부를 판단하는 공정한 평의회가 감독합니다. 이 평의회는 찬성표와 반대표의 비율뿐만 아니라 총 투표 수, 투표 대상 제안의 중요성, 그리고 가능하다면 개별 유권자와 그들의 투표 방식까지 고려하여 결정을 내립니다. 이를 통해 이 평의회는 각각의 결정이 충분한 다수의 지지를 받아 통과되도록 보장할 책임을 지게 됩니다.

PEP 거부

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

대신 PEP 8016과 그것이 설명하는 거버넌스 모델이 선택되었습니다.

서론

Commons 거버넌스 모델은 모든 결정이 Python 커뮤니티의 충분한 다수에게 지지를 받거나, 적어도 받아들여지도록 보장하려고 합니다.

안타깝게도 앞 문단에는 일반적인 경우 정량화하기 매우 어려운 두 용어가 있습니다. 바로 충분한 다수와 Python 커뮤니티입니다. 이는 실제로 두 용어 모두 결정하려는 특정 사례에 따라 달라지기 때문입니다. 이러한 어려움의 예를 들면, 일부 API에 대한 하위 호환성 변경을 제안하는 PEP의 경우 처음부터 해당 PEP의 투표에 관심을 보인 핵심 개발자들의 단순 과반수면 아마 충분할 것입니다. 그러나 Python 3에서 Python 4로의 전환처럼 훨씬 광범위한 결과를 초래하는 변경에는 실제 과반수가 필요할 수 있으며, 사용자층에서 적어도 충분한 지지가 있는 것으로 보인다는 입증도 필요할 수 있습니다. 그리고 포용적이지 않은 언어를 폐지하는 결정처럼 Python이라는 언어 자체를 넘어서는 변경의 경우에는 그 의미가 매우 모호해집니다.

Commons 거버넌스 모델은 일반적인 경우 충분한 다수와 Python 커뮤니티라는 용어가 무엇을 의미하는지 정의하지 않음으로써, 특정 사례에서 이를 결정할 기구를 제안하여 이 문제를 피해 가려고 합니다.

이 모델은 의사 결정 과정을 감독하고 특정 제안에 충분한 지지가 있는지를 사례별로 판단하는 원로 평의회를 만들 것을 제안합니다. 각 PEP마다 투표가 진행되며, 원로 평의회는 투표 결과가 이 특정 사례에서 결정을 통과시키기에 충분한지 선언합니다.

이 모델은 의사 결정 과정에서 전통적으로 BDFL이 맡았던 역할만 다루며, 다른 역할은 다루지 않습니다.

모델 이름에 포함된 Commons_는 모두가 사용하고 모두가 돌보는 공유 자원이라는 역사적 용례에 느슨하게 기반합니다. 이 모델을 통해 떠올려야 할 모습은 따뜻한 여름 저녁, 마을 광장에서 한 무리의 상당수 농민이 미래를 위한 어떤 계획을 논의하고, 그 후 투표를 진행하면 마을의 원로들이 결과를 선언하는 장면입니다. 그런 다음 연회가 시작됩니다.

Commons 거버넌스 모델은 다른 대부분의 거버넌스 제안과 다릅니다(8012는 예외일 수 있습니다). 이는 최고 권한을 명시적으로 전체 커뮤니티에 부여하기 때문입니다.

근거

이 모델의 근거는 모든 것을 구체적으로 규정하는 모델이 의도하지 않은 부정적 부작용을 초래할 수 있다는 것입니다. 예를 들어 Python 커미터에게 투표권을 부여하는 거버넌스 모델은 새 후보자가 근무하는 회사 출신 커미터가 이미 많기 때문에 해당 개인이 커미터로 받아들여지지 않게 만들 수 있습니다.

또 다른 예로 PEP 승인에 고정된 비율을 설정하면 유권자들 사이에서 정당이 형성되고, 개별 PEP가 각자의 장점에 따라 판단되지 않고 정당 노선에 따라 판단될 수 있습니다(당신이 내 PEP를 지지하면 나도 당신의 PEP를 지지하겠습니다).

Python과 같은 대상에 1인 1표제가 최선의 모델은 아니라는 문제도 있습니다. 다시 예를 들면, 표가 양분되는 경우(또는 양분되기에 충분히 근접한 경우)에는 핵심 개발자 Guido van Rossum의 의견이 핵심 개발자 Jack Jansen의 의견보다 더 큰 비중을 가져야 할 것입니다. 이를 투표 모델로 형식화하려고 하면 매우 복잡한 모델이 만들어지며, 어차피 경계 사례에서는 잘못된 결과를 내게 됩니다. 여기서 제시하는 모델은 이러한 문제에 대한 결정을 (바라건대 합리적인) 원로 평의회에 맡깁니다.

결정 과정

모든 중요한 결정은 PEP 절차를 거칩니다. 각 PEP에는 이를 책임지는 사람이 있으며, 여기서는 author라고 부르지만, 반드시 한 사람일 필요는 없고 실제로 본문을 작성한 사람일 필요도 없습니다. 따라서 author를 champion 또는 shepherd 또는 그와 비슷한 것으로 읽어도 됩니다.

PEP author는 해당 PEP에 대한 투표를 조직할 책임이 있습니다. 이 투표는 공개됩니다. 즉, 투표자가 식별되고 결과가 모든 사람에게 알려집니다. 투표는 단순한 +1/0/-1 방식일 수 있지만, 투표자가 해당 사안에 대해 왜 강한 의견을 갖는지 매우 간략하게 설명하는 +2/-2를 추가할 수도 있습니다. 이러한 주석은 원로 평의회에 대한 설명으로 활용됩니다. 투표자에게는 커뮤니티 내 지위(핵심 개발자 등)가 표시됩니다.

투표는 잘 정의된 Discourse 카테고리나 태그, 특수 메일링 리스트 또는 이와 유사한 기술적 방법(예를 들어 사람들이 로그인해야 하므로 커뮤니티 내 지위를 자동으로 추가하고 신원을 어느 정도 확인할 수 있는 vote.python.org 웹사이트)을 사용하여 토론과 명확히 분리됩니다.

PEP author는 PEP와 투표 결과를 원로 평의회에 제출합니다. 평의회는 두 가지를 숙고합니다.

  • PEP의 중대성과 그 영향,
  • 측정 가능한 투표 결과(몇 명이 투표했는지, 어떤 사람들이 투표했는지, 무엇에 투표했는지).

평의회는 투표가 통과되었는지에 대해 잠정적인 결정을 내리고, 이 결정을 공표합니다.

투표 결과가 해당 결정에 대해 커뮤니티의 충분한 지지를 보여 주지 못한다는 결정이 내려지면, author는 더 많은 지지를 모아 나중에 투표를 다시 제출해야 합니다. 또는 author가 제안을 철회할 수도 있습니다. 더 많은 지지를 모으는 기간에는 제한이 있으며, 한 달이 합리적인 기간으로 보입니다. 그 기간이 지난 후에도 투표가 다시 제출되지 않으면 제안은 거부됩니다.

잠정적인 결정에서 결과가 충분한 지지를 실제로 보여 준다고 판단되면, 상당히 짧은 대기 기간(몇 주 정도)이 시작됩니다. 이 기간에 누구나 원로 위원회에 이의를 제기할 수 있지만, 오직 투표가 커뮤니티의 충분한 다수를 반영하지 않는다는 근거에 한해서만 가능합니다. 대기 기간이 끝나면 평의회는 최종 결정을 내립니다. PEP는 수락되거나, 평의회가 이의 제기에 설득되면 더 많은 지지를 입증해야 하는 상태로 돌아갑니다.

원로 평의회

원로 평의회의 취지는 구성원들이 함께 특정 투표에서 Python 커뮤니티의 의지가 관철되었는지를 판단할 수 있도록 하는 것입니다.

원로 평의회는 BDFL과 동일한 권한을 가진 사람들의 집단으로 BDFL을 대체하는 것이 not 아닙니다. Python의 방향에 대한 지침을 제공하지 않으며, 투표 결과가 커뮤니티의 의지를 나타내도록 보장하려고 할 뿐입니다.

원로 평의회는 실제 결정 권한을 가진 미국 연방 대법원과 not 같은 기관이 아닙니다. 평의회는 커뮤니티가 투표에 반영되도록 투표 과정을 감독할 뿐입니다. 또한 원로 평의회는 분명히 스페인 종교재판소와도 같지 않습니다. 공포, 기습, 무자비한 효율성은 없어도 되는 것들이기 때문입니다(다만 귀여운 주홍색 예복을 사용하는 데에는 어느 정도 장점이 있습니다).

평의회는 네덜란드의 Hoge Raad와 어느 정도 비슷합니다. 이 기관은 안타깝게도 영어로 흔히 Supreme Court로 번역되지만, 절차와 진행된 과정을 심사하고 사건을 새롭게 판단하도록 돌려보낼 수만 있다는 점에서 그렇습니다.

또한 많은 국가가 (서로 다른 명칭으로) 두고 있는 선거관리위원회와도 어느 정도 비슷합니다. 선거를 감독한다는 점에서 그렇습니다.

평의회 운영

평의회 구성원은 자원봉사자이며, 파이썬 커뮤니티 내에서 다른 역할도 맡고 있을 가능성이 높습니다(파이썬 외부의 삶은 말할 것도 없습니다). 따라서 구성원에게 부과되는 업무량은 최소한으로 유지해야 합니다. 또한 개별 평의회 구성원이 평의회 구성원으로서 발언하는 경우와 개인 자격으로 발언하는 경우를 명확히 구분할 수 있어야 합니다. 그리고 정서적 부담에도 신경 써야 합니다. 평의회 구성원이 파이썬 메일링 리스트의 무작위 선동자들이 내린 결정에 대해 책임을 져서는 안 됩니다.

이 제안은 두 가지 방법으로 업무량을 최소화하려고 합니다.

  • 실제 업무의 대부분은 PEP 작성자와 커뮤니티가 수행하며, 원로 평의회는 투표를 조직하거나 결과를 집계하지 않습니다.
  • 첫 번째 잠정 결정의 배경에는 원로 평의회의 실수(대개 PEP의 영향 범위를 잘못 판단하는 것)가 치명적이지 않다는 생각이 있습니다. 커뮤니티가 이러한 실수를 지적할 기회가 있기 때문입니다.

    실질적으로 이는 커뮤니티가 이를 바로잡을 것을 전제로 평의회의 일부 구성원이 잠정 결정을 내릴 수 있다는 의미입니다. 2주마다 부지런히 일하는 전문가 7명을 한자리에 모으는 것은 이메일을 통하더라도 다소 무리한 요구일 수 있습니다.

개별 원로가 평의회를 대표하여 발언하는 경우를 명확히 하는 가장 좋은 방법은 특수 이메일 주소나 원로들만 게시할 수 있는 Discourse 주제를 사용하는 것일 것입니다. 여기에는 교황이 Ex Cathedra를 말하는 경우와 자신으로서 말하는 경우(이 경우 교황은 무오류가 아닙니다)의 유사점이 있습니다. 원로들은 대개 커뮤니티에서 존경받는 구성원일 것이며, 평의회에 속해 있다는 이유로 PEP에 대한 개인적인 의견을 밝힐 수 없다고 느끼게 만드는 것은 좋지 않습니다.

커뮤니티 구성원이 원로 평의회와 함께 나누는 논의, 즉 결정에 이의를 제기하는 경우의 논의는 다른 포럼(Discourse 주제, 메일링 리스트)에서 진행해야 합니다.

원로 평의회의 결정은 개별 구성원의 결정이 아니라 평의회 전체의 결정으로 보아야 합니다. 최초 구현에서는 원로들이 자신의 이름으로 게시해야 합니다(평의회 구성원으로 발언한다는 사실은 게시하는 주제에서 드러나게 하거나, 특별한 배지로 표시할 수 있습니다). 원로들이 인신공격의 개별 표적이 되는 것으로 드러나면 이 방식을 재검토하고 익명성을 보장할 방법을 마련해야 합니다.

자유의 제한

특정 투표에서 핵심 팀 구성원의 찬성 또는 반대가 실제 과반수(전체 핵심 팀 구성원의 50% + 1보다 많은 수)를 차지하면 해당 결과가 통과됩니다. 특정 투표에서 PSF 의결권 보유 회원의 찬성 또는 반대가 실제 과반수(50% + 1보다 많은 수)를 차지하면 해당 결과가 통과됩니다. 완전성을 위해 덧붙이면, 앞의 두 진술이 모두 참이지만 결과가 서로 반대인 경우에는 핵심 팀 구성원이 승리합니다.

이러한 제한을 두는 주된 이유는 어느 순간에든 정상적으로 기능하는 원로 평의회가 없더라도 (노력을 들이면) 결정을 내릴 수 있게 하기 때문입니다.

평의회 구성

평의회는 너무 크지도 작지도 않아야 하며, 아마도 5명에서 10명 사이가 적절할 것입니다. 이 수를 고정해야 할 이유는 없습니다. 구성원은 파이썬과 파이썬 커뮤니티에 대해 잘 알고 있어야 하며, 평의회의 일원으로 활동하는 동안 공정성을 유지할 의지가 있어야 합니다. 평의회 구성원은 핵심 개발자일 수 있지만, 그것이 필수 요건은 아닙니다.

커뮤니티의 모든 사람이 평의회가 자신을 대표한다고 느껴야 하므로, 평의회가 다양하게 구성되면 좋을 것입니다.

  • 과학자와 기술 전문가,
  • 파이썬 언어에 관한 진보주의자와 보수주의자,
  • 서로 다른 문화적 배경, 성별, 연령을 가진 사람들,
  • 기타

그러나 이는 평의회 전체에 적용되어야 합니다. 개별 평의회 구성원은 특정 이익 집단을 대표하는 것으로 간주되어서는 안 됩니다.

평의회 구성원

평의회의 권한은 순전히 절차적인 것이므로 구성원이 상당히 오랫동안 임기를 수행하는 것이 좋을 것입니다. 그러나 평의회가 정기적으로 재신임되는 것도 여전히 바람직합니다. 따라서 평의회가 PSF의 산하에서 운영되고 매년 신임 투표의 대상이 되도록 하자는 제안입니다. 이 투표는 평의회 전체를 대상으로 합니다. 평의회에 반대하는 사람들은 기본적으로 “여러분 같은 사람들이 있는 것보다 원로 평의회가 없는 편이 Python에 더 낫다”고 말하는 셈임을 알아야 합니다.

평의회는 보통 새로운 원로를 공동 선임합니다. 아마도 평의회에 부족한 Python 커뮤니티의 특정 부분 또는 언어의 특정 부분에 관한 지식을 개인이 갖고 있다고 여겨지기 때문일 것입니다. 누구나 평의회에 새로운 원로를 제안할 수 있으며(자기 자신을 포함합니다), 평의회는 그 제안을 무시할 수 있습니다. 평의회 구성원은 언제든 자유롭게 은퇴할 수 있어야 합니다. 개별 평의회 구성원은 나머지 평의회의 만장일치 투표로 은퇴시킬 수 있습니다.

기능하지 않는 평의회를 없애기 위한 비상 정지 절차가 있습니다. 원로 한 명 또는 핵심 개발자나 PSF 투표 구성원 10명으로 이루어진 집단은 평의회 전체에 대한 즉각적인 재신임 투표를 요청할 수 있습니다(아마도 이는 평의회의 위임 권한을 박탈하려는 의도일 것입니다). 이 투표를 원로가 요청한 경우, 해당 개인은 투표 결과와 관계없이 즉시 평의회 직위를 잃습니다. 커뮤니티 구성원이 투표를 요청했고 평의회가 재신임된 경우, 이 절차는 1년 동안 다시 발동할 수 없습니다.

기능하는 평의회가 없는 경우(현재의 초기 상황 또는 불신임 투표 후 평의회가 위임 권한을 잃은 경우) 초기 평의회를 선정해야 합니다. 누구나(자기 자신을 포함하여) 일반적인 소통 채널(disourse, 메일링 리스트)을 통해 구성원을 제안할 수 있습니다. 후보자들 간의 논의와 전체 커뮤니티에서의 논의가 끝난 후, 원로 평의회로 임명해 달라는 초기 투표를 요청하는 최소 세 명의 개인으로 이루어진 집단이 나타나야 합니다. 이 절차의 의도는 그러한 개인 집단이 구성되어 신임 투표를 요청할 때쯤에는 압도적인 위임 권한을 기대할 수 있도록 하는 것입니다.

논의

이 PEP는 BDFL의 다른 역할은 다루지 않고 투표 절차만 다룹니다. 무엇보다도 장기적인 Python의 방향은 원로 평의회가 다루지 않을 것으로 예상됩니다. 이는 커뮤니티 전체(또는 아마도 커뮤니티의 개별 구성원)의 몫입니다.

또한 Python과 Python 커뮤니티를 외부 세계에 대표하는 상징적 대표자 또는 대변인의 역할도 있습니다. 다시 말해, 제 생각에는 이는 원로 평의회가 맡아야 할 역할이 not이 아니라 다른 사람이나 조직이 맡아야 할 역할입니다.

이 제안은 진보보다는 보수주의를 선호할 가능성이 가장 높다는 점에 유의하십시오. 또는 적어도 이 제안이 정체로 이어질 위험이 미지의 영역으로 무모하게 질주하게 될 위험보다 큽니다. 그러므로 이 모델이 시행된다면 PEP 572와 같은 PEP가 통과될 가능성은 낮다는 점을 인식해야 합니다.