PEP 8012 – 커뮤니티 거버넌스 모델

Author:

Łukasz Langa <lukasz at python.org>

Status:

Rejected

Type:

Informational

Topic:

Governance

Created:

03-Oct-2018

---

Table of Contents

• PEP 거부
• 초록
• 기각된 모델
  • 또 다른 BDFL을 둡시다
    • 과제: 또 다른 Guido는 없습니다
    • 위험: 종신 악덕 독재자
    • 관찰: 사실 우리에게 독재자는 필요하지 않습니다
    • 위험: 모호한 제안이 주는 막연하고 포근한 느낌
  • 위원회를 둡시다
    • 위험: 희석과 혼란
    • 위험: 내부 갈등
• 동기
• 근거
• 명세
  • 주요 인물과 그 역할
    • 코어 팀
    • 전문가
    • 중재자
  • 일반적인 의사 결정 절차
  • 논쟁적인 사안의 의사 결정 절차
    • 개선된 PEP
    • 논란이 매우 큰 PEP
    • 보류 및 거부된 PEP 재검토
  • 기타 투표 상황
    • 새 코어 개발자 추천
    • 불신임 투표
  • 투표 절차
• 생략한 사항
• 감사의 글
• Copyright

번역·라이선스 안내

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

PEP 거부

PEP 8012는 2018년 12월 17일 월요일에 PEP 8001에 기술된 핵심 개발자 투표로 기각되었습니다.

대신 PEP 8016과 그 PEP가 기술하는 거버넌스 모델이 선택되었습니다.

초록

이 PEP는 Python 커뮤니티의 합의와 투표에 기반한 새로운 Python 거버넌스 모델을 제안합니다. 이 모델은 Python 언어의 거버넌스를 수행하기 위해 워크그룹에 의존합니다. 이 거버넌스 모델은 중앙 집중화된 단일 지도자나 운영 위원회의 역할 없이 작동합니다.

이 PEP는 Python 언어에 영향을 미치는 결정에 대해 투표를 어떻게, 언제, 그리고 왜 진행하는지 기술합니다. 또한 투표 자격의 기준도 기술합니다.

이 모델이 채택된다면 PEP 13에 성문화될 것입니다.

이 모델은 이상과는 거리가 멀지만 다른 모델들과 비교하면 여전히 가장 견고하다는 특성 덕분에 “최악은 면한 거버넌스 모델”이라는 애정 어린 이름으로 불릴 수 있습니다. 다른 모델들에 내재된 문제를 피하는 것이 커뮤니티 거버넌스 모델의 가장 중요한 특징이므로, 우리는 다소 이례적인 방식으로, 즉 다른 모델들을 기각하는 것으로 논의를 시작합니다.

기각된 모델

또 다른 BDFL을 둡시다

이는 우리가 이미 알고 있는 모델이기 때문에 매우 매력적인 아이디어로 보입니다. 우리 모두를 다스릴 단 한 명의 독재자입니다.

과제: 또 다른 Guido는 없습니다

Guido van Rossum과 같은 독보적인 역량을 갖춘 사람은 달리 없습니다. 그러한 사람은 프로젝트를 성공적으로 이끌 수 있는 기술적, 의사소통적, 조직적 경험을 갖추어야 합니다. 구체적으로 그 사람은 다음을 할 수 있어야 합니다:

• 프로젝트를 위한 일관된 장기 비전을 세우고 명확히 제시해야 합니다;
• 런타임, 표준 라이브러리, 그리고 더 넓은 서드파티 라이브러리 생태계에 대한 깊은 기술적 이해를 갖추어야 합니다;
• 논쟁적인 사안을 관련된 모든 당사자가 받아들일 수 있는 방식으로 협상하고 해결해야 합니다;
• 수년에 걸쳐 지속적으로 참여할 수 있는 여유 시간과 에너지를 갖추어야 합니다.

위험: 종신 악덕 독재자

만약 첫 번째 독재자만큼 그 자리에 적합하지 않은 사람을 얻게 된다면 어떻게 되겠습니까? 이것이 심각한 결과로 이어질 수 있는 시나리오도 있을 수 있습니다.

독재자는 기술적 깊이의 부족, “근소한 차이”의 선거, 일관성 없는 비전, 갈등이나 번아웃에 대처하는 능력의 부족 등으로 인해 충분한 신뢰를 얻지 못할 수 있습니다. 논란이 되는 결정을 독재자가 특정한 방향으로 내린다면, 충분한 신뢰를 얻지 못한 독재자는 프로젝트 내부의 분열을 초래할 수 있습니다.

독재자 체제는 단 한 사람에게 집중된 로비를 불러옵니다. 그 사람이 재산, 건강, 안정된 생활 여건 덕분에 외부의 압력에 흔들리지 않는 것이 아니라면, 이는 악의적인 행위자가 막후에서 프로젝트를 조종할 위험을 초래합니다.

마지막으로, 커뮤니티의 특정 부분 출신인 독재자는 사용자층 중 그 부분의 필요와 이익에 더 큰 비중을 두어 다른 이들을 소외시킬 수 있습니다.

관찰: 사실 우리에게 독재자는 필요하지 않습니다

독재자 모델의 아이러니는 선거가 필요하다는 점입니다. 더 나아가, 어떤 거버넌스 모델을 사용할지 결정하는 데에도 선거가 필요합니다.

이만큼 중대한 문제 두 가지를 이미 커뮤니티 절차를 통해 해결할 수 있다면, 이후의 모든 결정에도 그 절차를 계속 사용하지 않을 이유가 있겠습니까?

위험: 모호한 제안이 주는 막연하고 포근한 느낌

마지막으로 언급할 만한 점은, BDFL 모델이 제안될 때 누가 BDFL이 되어야 하는지를 언급하지 않음으로써 위의 비판을 쉽게 피해 갈 수 있다는 것입니다. 그렇게 하면 기대에 찬 독자는 추상적인 BDFL에 자신의 가장 좋은 기대와 바람을 투영할 수 있고, 그 결과 이 아이디어가 더 매력적으로 보이게 됩니다. 이것은 잘못입니다.

모델 제안에서 BDFL을 지명하지 않는다면 우리는 구체적인 모델에 대해 이야기하고 있는 것이 아닙니다. 어려운 질문을 던지고 답하는 일을 피할 수 있게 됩니다. 최선의 시나리오, 즉 그 역할을 맡아 주었으면 하는 후보를 상상할 수 있게 됩니다.

BDFL의 이름을 생략하는 것은 또한 커뮤니티 모델을 부당하게 불리한 위치에 놓습니다. 우리는 코어 개발자 그룹의 좋은 면, 나쁜 면, 추한 면을 이미 알고 있습니다. 그것은 플라톤적 이상도 아니고, 마찰 없는 완벽한 구체도 아닙니다. 사실 우리는 상당한 마찰과 불완전함이 있으리라 예상합니다.

따라서 친애하는 독자 여러분, BDFL 모델 제안을 공정하게 평가하려면 우리 팀 안에서 가능한 최악의 인물을 그 BDFL로 상상하셔야 합니다. 구체적인 한 인간 말입니다. 그것이 저라고 상상해 보십시오.

결론 이것이 지금까지의 역사였지만, Guido가 없다면 이 모델은 앞으로 언어에 최선의 이익이 되지 않습니다.

위원회를 둡시다

이 사람들로 이루어진 그룹은 독재자의 책임을 대략 나누어 맡습니다. 이 그룹은 삼두정치(Triumvirate), 정족수(Quorum), 원로(Elders), 운영 위원회(Steering Committee) 등으로 불릴 수도 있습니다.

위험: 희석과 혼란

이 모델은 세 명에서 다섯 명 사이의 작은 그룹을 선호합니다. 그렇기 때문에 이 모델은 독재자 모델에 대한 비판 대부분을 증폭된 형태로 공유합니다. 권력의 자리에 한 명이 아니라 이를테면 세 명을 두면 책임은 희석되면서도 로비, 신뢰 부족, 커뮤니티 일부의 소외라는 높은 위험은 여전히 남습니다.

위험: 내부 갈등

게다가 여러 사람이 거버넌스의 책임을 나누어 맡으면 내부 갈등과 일관되지 않은 프로젝트 장기 비전이 생길 여지가 많아지고, 구성원들에게 요구되는 지속적인 시간 투입이 몇 배로 늘어납니다(다른 일정 때문에 “정족수를 채울” 수 없다면 그것은 정족수가 아닙니다).

마찰 없는 구형 BDFL의 경우와 마찬가지로, 그 역할에 부적합하다고 여기는 세 사람으로 위원회가 구성된다면 여러분에게 어떻게 작동할지를 고려하지 않은 위원회 아이디어는 거부하십시오. 제게 친구가 두 명 있다고 상상해 보십시오.

가장 중요한 점은, 독재자의 경우와 마찬가지로 평의회도 필요하지 않다는 것입니다. 평의회가 구성될 무렵이면 이미 두 번의 선거를 성공적으로 치렀을 것입니다. 그렇다면 계속 투표하면 되지 않겠습니까?

결론 이 모델은 독재자 모델과 비슷한 위험을 안고 있으며, 오히려 더 나쁩니다.

동기

다른 거버넌스 모델의 기본 사항들을 기각했으니, 이제 느슨하게 정의된 커미터 집단 위에 거버넌스 모델이 애초에 왜 필요한지 이야기해 봅시다.

안정성과 신뢰성 우리는 개별 커미터가 언어의 미래나 사용성에 영향을 미치는 광범위한 변경을 하지 못하도록 막고자 합니다. 일관된 비전과 하위 호환성은 어떤 프로그래밍 언어에서든 중요하지만, 매우 동적인(예를 들어 하위 호환성 문제가 매우 복잡한) Python에서는 두 배로 중요합니다.

Python의 다양한 용도 또한 Python은 학생부터 과학자, 수백만 줄의 코드베이스를 가진 기업에 이르기까지 다양한 사용자 집단이 사용합니다. 우리는 이처럼 다양한 사용자층을 모두 포용하고자 합니다.

활력 우리는 정체를 피하고자 합니다. Python은 성숙한 프로젝트이지만, 시대에 뒤처지지 않으려면 런타임과 프로그래밍 언어 모두 계속 발전해야 합니다. 그러려면 프로젝트의 특정 부분을 개선하는 데 관심 있는 사람들이 불필요한 마찰 없이 그렇게 할 수 있어야 합니다. 하지만 중대한 변경에 대해서는 그 변경이 현명한지 확인하기 위해 어느 정도의 논의와 숙고를 거치고자 합니다.

근거

포용성 커뮤니티 모델은 가장 포용적인 모델입니다. 어느 한 사람이나 소수의 집단도 다른 사람들보다 특별한 권력을 가진 위치에 있지 않습니다. 이 모델에서 기여자와 모든 작업 그룹은 스스로 참여를 결정합니다.

실용성 이 모델은 어떤 사용자 집단도 한 사람이나 소수 집단의 이해관계 때문에 불리한 처지에 놓이지 않도록 보장합니다.

검증됨 이 모델은 효과가 있습니다. 이런 방식으로 운영되는 대규모 오픈 소스 프로젝트가 여럿 있습니다(그중 Rust와 Django 두 프로젝트는 PEP 8002에 설명되어 있습니다). ECMAScript와 C++도 비슷한 방식으로 개발됩니다.

명세

주요 인물과 그 역할

코어 팀

Python 프로젝트는 코어 개발자 팀이 개발합니다. 구성원 자격은 GitHub의 “python” 조직 내 “Python core” 팀에 속해 있는지로 결정되지만, 기여는 다양한 형태로 이루어집니다:

• 저장소에 변경 사항을 커밋하는 것;
• 다른 사람의 풀 리퀘스트를 리뷰하는 것;
• 이슈 트래커에서 버그 보고를 분류하는 것;
• 공식 Python 커뮤니케이션 채널에서 주제를 논의하는 것.

일부 기여자는 휴면 상태로 간주될 수 있습니다. 즉, CPython의 최근 두 릴리스에 기여하지 않은 기여자입니다. 휴면 상태인 기여자는 누구든 언제든지 기여를 재개할 수 있습니다.

전문가

Python 개발자 가이드에는 여러 관심 분야와 함께 각 분야의 전문가로 인정받는 코어 개발자의 이름이 나열되어 있습니다. 전문가 또는 전문가 하위 팀은 다음과 같은 책임을 집니다:

• 해당 관심 분야로 분류된 버그 트래커의 이슈에 적시에 대응합니다.
• 해당 관심 분야에 속하는 것으로 확인된 풀 리퀘스트를 적시에 리뷰합니다.
• 해당 관심 분야가 발전하는 과정에서 설계의 일관성을 감독합니다.

코어 개발자는 특정 관심 분야에 자신을 자유롭게 배정하거나 배정을 해제할 수 있습니다. 해당 관심 분야에 등재된 기존 전문가들에게 이 변경 사항을 알려야 하며, 기존 전문가들은 만장일치로 이에 동의해야 합니다.

특정 관심 분야에 여러 전문가가 등재되어 있으면, 이들은 코어 팀 내에서 하위 팀을 구성합니다. 이들은 해당 관심 분야에 대해 공동으로 책임을 집니다.

코어 개발자는 동시에 너무 많은 관심 분야의 전문가로 등재되는 것을 피해야 합니다. 이 문서는 의도적으로 최대 개수를 지정하지 않으며, 과도한 부담이 번아웃으로 이어지고 특정 기여자 없이도 프로젝트가 제대로 기능(함수)할 수 있는 능력에 위험이 된다는 점을 알릴 뿐입니다.

중재자

공식 소통 채널에서의 논의가 행동 강령을 준수하도록 보장할 책임을 지는 사람들의 그룹이 있으며, 그중 일부는 코어 개발자가 아닙니다. 이들은 위반 사항이 있으면 조치를 취합니다.

일반적인 의사 결정 절차

주요 작업은 버그 트래커 이슈와 풀 리퀘스트를 통해 이루어집니다. 코어 개발자는 변경 사항을 cpython 저장소에 직접 푸시하는 것을 피하고, 대신 풀 리퀘스트를 이용해야 합니다. 코어 개발자가 풀 리퀘스트를 승인하면 추가 절차 없이 병합할 수 있습니다.

버그 트래커 이슈나 풀 리퀘스트에 대해 관련 전문가에게 알리는 것이 중요합니다. 해당 관심 분야 전문가의 리뷰가 강력히 권장되며, 특히 풀 리퀘스트 승인 시에 그렇습니다. 그렇게 하지 않으면 관련 전문가가 해당 변경 사항을 되돌릴 수도 있습니다.

전문가가 GitHub과 버그 트래커에서 쏟아지는 모든 활동을 항상 지켜봐야 하는 것은 아닙니다. 전문가의 주의를 끌려면 분류 작업 중이나 버그/풀 리퀘스트를 생성할 때 해당 전문가에게 명시적으로 알려야 할 수도 있습니다.

논쟁적인 사안의 의사 결정 절차

특정 관심 분야의 중대한 변경에는 PEP가 필요합니다. 여기에는 다음이 포함됩니다:

• 언어에 대한 모든 의미적 또는 문법적 변경.
• 표준 라이브러리나 C API에 대한 하위 호환성을 깨뜨리는 변경.
• 기존 라이브러리 내의 상당한 새 기능을 포함하여, 표준 라이브러리에 대한 추가.
• 언어, 표준 라이브러리 또는 C API 기능 제거.

상당한 변경이 PEP 절차를 통과하지 못하면 해당 변경이 되돌려질 수 있습니다.

버그 수정에 해당하는 변경은 PEP 요건에서 면제될 수 있습니다. 최선의 판단을 내리십시오.

개선된 PEP

PEP 절차는 PEP 1에 이미 있는 정보에 다음과 같은 변경 사항과 설명을 더해 보강됩니다:

• PEP는 최종 결정이 내려질 때까지 병합되지 않으며, 그때까지는 GitHub에 열린 풀 리퀘스트로 남아 있습니다;
  • 검토를 쉽게 하기 위해, 검토 중인 PEP에 대한 모든 변경은 별도의 커밋으로 만들어 세밀하게 비교할 수 있도록 해야 합니다;
• 제출된 PEP는 해당 PEP에 대한 최종 결정을 내리는 주체로서 관심 분야와 관련 전문가를 명시해야 합니다;
• PEP 작성자가 관련 관심 분야의 전문가 중 한 명인 경우, 해당 관심 분야 밖의 다른 사람을 지명하여 자신을 대신해 최종 결정에 참여하도록 해야 합니다;
• PEP 작성자는 합의를 이루는 것을 목표로, 공식 소통 채널을 통해 PEP에 대한 피드백을 수집하고 반영할 책임이 있습니다;
• 모든 커뮤니티 구성원이 피드백을 제공할 수 있어야 합니다;
• 어느 시점에 지명된 전문가 중 한 명이 현재 논의 상황, 특히 주요 이견과 트레이드오프를 정리한 “요약 코멘트”를 게시합니다. 이와 동시에 해당 전문가는 “최종 의견 수렴 기간 발의”(FCP)를 제안하면서, 다음 중 하나로 처리할 것을 함께 제안합니다:
  • 수락;
  • 잠정 수락;
  • 거부; 또는
  • PEP 보류.
• FCP에 들어가려면 관련 관심 분야의 모든 전문가가 PEP를 승인해야 합니다;
• FCP는 결정이 내려지기 전에 이해관계자들이 최종 이의를 제기할 수 있도록 역일 기준으로 14일 동안 진행됩니다.

논란이 매우 큰 PEP

코어 기여자가 특정 PEP에 강하게 반대하는 경우, 해당 PEP의 FCP 기간 동안 투표로 거부하자는 발의를 할 수 있습니다. 투표에 관한 자세한 내용은 아래 “투표 방식”에 설명되어 있습니다.

이는 최후의 수단이어야 하며 따라서 드물게 일어나야 합니다. 이는 코어 팀을 분열시키며 관련된 모든 사람에게 스트레스를 주는 일입니다. 그러나 PEP에 대해 FCP를 신청하는 전문가들은 투표로 거부하자는 발의가 나올 가능성이 있는지 잘 파악하고 있어야 합니다. 그러한 경우에는 FCP를 성급하게 신청하지 않도록 주의해야 합니다.

반대 상황, 즉 전문가들은 PEP를 거부하려 하지만 다른 사람들은 수락되기를 원하는 경우에는 이의를 제기할 수단이 없습니다. 이를 통해 무엇이 반영될지에 대해 관련 전문가들이 최종 결정권을 갖도록 보장합니다. 그 변경을 정말로 원한다면 그들을 설득할 방법을 찾으십시오.

공식 소통 채널의 중재자는 모든 이해관계자 간의 건전한 상호작용을 보장하기 위해 무엇보다도 행동 강령을 집행합니다. 행동 강령 집행으로 인해 특정 참여자가 이후 논의에서, 따라서 결정 과정에서도 배제될 수 있습니다.

보류 및 거부된 PEP 재검토

PEP가 연기되거나 거부된 경우, 같은 아이디어를 다시 시도하기 전에 먼저 관련 전문가들에게 연락해야 합니다. 그 아이디어를 재검토할 만한 상당한 근거가 있다는 데 전문가들이 동의하면, 연기되거나 거부된 PEP를 수정하는 풀 리퀘스트를 열 수 있습니다.

사전에 전문가들의 적절한 동의를 얻지 못하면, 연기되거나 거부된 PEP에 대한 풀 리퀘스트는 즉시 거부될 가능성이 높습니다.

기타 투표 상황

새 코어 개발자 추천

챔피언은 공식 커뮤니케이션 채널에 글을 올려 어떤 사람을 새 코어 개발자로 추천합니다. 투표가 개시됩니다.

기존 코어 개발자 중 누구라도 피추천인이 커밋 권한을 받는 것이 불편하다면, 가급적 추천 스레드에서 그 우려를 제기하는 것이 바람직합니다. 만족스러운 해결에 이르지 못하면 반대표를 던질 수 있습니다.

실제로 어떤 사람을 코어 개발자로 추천하면, 다른 사람들이 그 사람이 아직 코어 개발자가 아니었다는 사실에 놀라는 경우가 많아야 합니다. 다시 말해, 추천은 후보자가 이미 다른 사람들에게 충분히 알려져 있고 신뢰받고 있을 때 이루어져야 합니다. 잠재력에 근거한 추천은 피해야 합니다.

불신임 투표

• 코어 팀에서 코어 개발자를 제명하는 것;
• 특정 관심 분야의 전문가 팀을 해산하는 것.

이는 코어 개발자가 코어 팀에서 강제로 제명되거나 전문가 팀이 강제로 해산되는 상황을 설명합니다. 이러한 조치가 실제로 행사될 일이 없기를 바라지만, 제 기능을 하지 못하는 관심 분야를 어떻게 바로잡을 수 있는지 보여 주기 위해 명시적으로 언급합니다.

코어 개발자가 투표로 코어 팀에서 제명되면, 그 사람은 프로젝트와 상호 작용할 수 있는 권한을 잃습니다. 버그 트래커와 GitHub에 글을 올릴 수 있는 권한을 박탈할지, 아니면 사안별로 향후 행동을 중재하는 데 그칠지는 모더레이터의 재량에 달려 있습니다.

어떤 관심 분야의 전문가 팀이 해산되면, 다른 코어 개발자들이 자유롭게 나서서 그 공백을 메울 수 있습니다. 해산된 전문가 팀의 구성원은 복귀하기 위해 스스로를 추천할 수 없습니다.

투표 절차

이 문서에서 설명하는 모든 투표는 +1/-1/0(“찬성”/”반대”/”기권”) 기명 투표입니다. 다른 투표 값은 없으며, 특히 범위를 벗어난 값이나 분수(+0.5 등)는 무효입니다.

투표 기간은 역일 기준 14일입니다. 시작일은 투표 발의를 제기한 사람의 시간대를 기준으로 정합니다. 종료일은 AoE(Anywhere-On-Earth) 기준으로 14일 후입니다.

위의 “핵심 인물과 그들의 역할(함수)”에서 정의한 휴면 코어 개발자는 기권하는 경우 총계에 포함되지 않습니다. 그러나 이들도 원한다면 투표할 수 있으며, 그렇게 하면 활동 중인 것으로 간주됩니다. 투표는 기여의 한 형태입니다.

투표는 GitHub의 “python” 조직에 있는 비공개 저장소에 커밋하는 방식으로 진행합니다. 투표 기간이 끝나면 저장소를 보관 처리하고 공개합니다. 저장소 이름은 “vote-“로 시작해야 합니다.

투표 기간 중에는 자신의 투표를 변경할 수 있습니다. 투표 기간 중에 다른 개발자가 던진 표를 엿볼 수 있습니다.

상황마다 필요한 투표 비율이 다릅니다:

• 투표로 PEP를 거부하려면 휴면 상태가 아닌 코어 개발자 전체의 3분의 1을 초과하는 인원이 명시적으로 거부에 투표해야 합니다. 코어 개발자의 3분의 1을 초과하는 인원이 PEP에 반대하기로 결정했다면, 이는 해당 변경에 찬성하는 코어 개발자의 초다수가 존재하지 않는다는 뜻임에 유의하십시오. 이는 해당 변경을 PEP에 기술된 형태로 적용해서는 안 된다는 점을 강하게 시사합니다.
• 새 코어 개발자를 지명하려면 반대표가 하나도 없어야 합니다.
• 불신임 투표가 성립하려면 휴면 상태가 아닌 코어 개발자 전체의 최소 3분의 2에 해당하는 초다수가 해당 안건에 명시적으로 찬성 투표해야 합니다.

생략한 사항

이 문서는 프로젝트 내에서 관심을 가질 만한 영역을 의도적으로 나열하지 않습니다. 또한 중재자(Moderator)의 선출과 관리도 다루지 않습니다. 이는 Python Software Foundation과 그 산하의 행동 강령 워킹 그룹(Code of Conduct Working Group)이 담당하며, 이 그룹에는 conduct-wg@python.org 주소로 메일을 보내 연락할 수 있습니다.

감사의 글

이 문서를 구성하는 데 유용한 자료가 된 PEP 8002의 저자들에게 감사드립니다.

이 문서에 큰 영감을 준 거버넌스 모델을 만든 Alex Crichton과 Rust 팀에 감사드립니다.

Copyright

This document has been placed in the public domain.