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는 Python 커뮤니티의 합의와 투표에 기반한 새로운 Python 거버넌스 모델을 제안합니다. 이 모델은 Python 언어의 거버넌스를 수행하기 위해 작업 그룹에 의존합니다. 이 거버넌스 모델은 중앙집중식 단일 리더나 통치 위원회의 역할 없이도 작동합니다.

이 모델은 Python 언어에 영향을 미치는 결정을 위해 투표를 어떻게, 언제, 왜 실시하는지 설명합니다. 또한 투표 자격 기준을 설명합니다.

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

이 모델은 이상적인 것과는 거리가 멀지만 다른 모델들과 비교하면 여전히 가장 견고하다는 특성 때문에 애정 어린 의미에서 “가장 덜 나쁜 거버넌스 모델”이라고 부를 수 있습니다. 다른 모델에 내재한 문제를 피하는 것이 커뮤니티 거버넌스 모델의 가장 중요한 특징이므로, 우리는 다소 이례적으로 다른 모델을 거부하는 것부터 논의를 시작합니다.

거부된 모델입니다.

또 다른 BDFL을 둡시다.

이는 우리가 알고 있는 모델이기 때문에 매우 매력적인 생각처럼 보입니다. 우리 모두를 다스릴 독재자 한 명입니다.

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

Guido van Rossum과 같은 고유한 역량을 가진 다른 단 한 사람도 없습니다. 그런 사람은 프로젝트를 성공적으로 이끌기 위해 기술적·의사소통적·조직적 경험을 갖추어야 합니다. 구체적으로 그런 사람은 다음을 수행해야 합니다:

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

위험: 종신 악의적 독재자입니다.

첫 번째 독재자만큼 그 직책에 적합하지 않은 사람을 얻게 된다면 어떻게 되겠습니까? 이로 인해 심각한 결과로 이어질 수 있는 상황이 발생할 수 있습니다.

독재자는 기술적 깊이의 부족, “박빙의” 선거, 일관성 없는 비전, 갈등이나 소진에 대처하는 능력 부족 등으로 인해 충분한 신뢰를 얻지 못할 수 있습니다. 독재자가 논쟁적인 결정을 특정한 방식으로 내렸을 때, 충분한 신뢰를 얻지 못한 독재자는 프로젝트 내부에 분열을 일으킬 수 있습니다.

독재자 체제는 한 사람에게 집중된 로비를 부추깁니다. 그 사람이 부, 건강 및 안정적인 생활 환경으로 인해 영향력 행사에 면역이 되지 않는 한, 이는 악의적인 행위자들이 막후에서 프로젝트를 조종할 위험을 초래합니다.

마지막으로, 공동체의 특정 부분에서 나온 독재자는 사용자 기반의 해당 부분의 필요와 이익에 더 큰 비중을 두어 다른 이들을 소외시킬 수 있습니다.

관찰: 실제로는 독재자가 필요하지 않습니다.

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

이 정도로 중대한 문제 두 가지를 이미 공동체 절차를 통해 해결할 수 있다면, 이후의 모든 결정에도 계속 이를 사용하는 것이 어떻겠습니까?

위험: 모호한 제안이 주는 따뜻하고 막연히 좋은 느낌

마지막으로 언급할 만한 점은 BDFL 모델이 제안되었을 때 BDFL이 누구여야 하는지 언급하지 않음으로써 앞서 제기한 비판을 쉽게 피해 갈 수 있다는 점입니다. 그렇게 하면 희망적인 독자는 추상적인 BDFL에 자신의 최선의 기대와 바람을 투영하여 그 아이디어를 더 매력적으로 보이게 할 수 있습니다. 이는 실수입니다.

모델 제안에서 BDFL의 이름을 밝히지 않으면 우리는 구체적인 모델을 이야기하는 것이 아닙니다. 우리는 어려운 질문을 묻고 답하는 일을 피할 수 있습니다. 우리는 최선의 시나리오, 즉 그 역할을 맡기고 싶은 후보자를 상상할 수 있습니다.

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

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

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

위원회를 구성합시다.

이 사람들로 이루어진 그룹은 대략 독재자의 책임을 나누어 맡습니다. 이 그룹은 삼두정, 정족수, 원로들, 운영 위원회 등으로도 부를 수 있습니다.

위험: 희석과 혼란

이 모델은 세 명에서 다섯 명 사이의 소규모 그룹을 선호합니다. 그렇게 하면 독재자 모델에 대한 비판 대부분을 더 증폭된 형태로 공유하게 됩니다. 권력의 위치에 한 명이 아니라 가령 세 명을 두면 책임은 희석되는 동시에 로비, 불충분한 신뢰 또는 공동체 일부의 소외라는 높은 위험은 여전히 존재합니다.

위험: 내부 갈등

또한 여러 사람이 거버넌스의 책임을 나누어 맡으면 내부 갈등, 프로젝트의 일관되지 않은 장기적 비전이 발생할 기회가 충분해지고, 구성원에게 요구되는 지속적인 시간 투입도 배가됩니다(다른 시간상의 약속 때문에 “정족수에 도달”할 수 없다면 정족수가 아닙니다).

마찰이 없는 완벽한 구체인 BDFL의 경우와 마찬가지로, 그 위원회가 그 역할에 부적합하다고 생각하는 세 사람으로 구성되었다면 자신에게 어떻게 작용할지 고려하지 않고 위원회라는 발상을 거부하지 마십시오. 제가 친구 두 명을 두었다고 상상해 보십시오.

무엇보다도, 독재자의 경우와 마찬가지로 의회가 필요하지 않습니다. 의회가 생길 때쯤이면 이미 두 번의 성공적인 선거를 치렀을 것입니다. 계속 투표하지 않을 이유가 무엇입니까?

Conclusion 이 모델은 독재자와 비슷한 위험을 지니며, 단지 더 심각합니다.

동기

다른 거버넌스 모델의 기본 사항을 거부했으므로, 느슨하게 정의된 커미터 그룹 위에 거버넌스 모델이 왜 필요한지 이야기해 보겠습니다.

Stability and Reliability 개별 커미터가 언어의 미래나 사용성에 광범위한 영향을 미치는 변경을 수행하지 못하도록 방지하고자 합니다. 일관된 비전과 하위 호환성은 모든 프로그래밍 언어에서 중요하지만, 매우 동적인 Python에서는 특히 더 중요합니다(예를 들어 하위 호환성에 미치는 영향이 매우 복잡합니다).

Diverse Uses of Python 또한 Python은 학교 어린이부터 과학자, 수백만 줄 규모의 코드베이스를 보유한 기업에 이르기까지 다양한 사용자 집단이 사용합니다. 우리는 이처럼 다양한 모든 대상 사용자를 포용하고자 합니다.

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

근거

Inclusive 커뮤니티 모델은 가장 포용적인 모델입니다. 어느 한 사람이나 소수의 집단도 다른 사람들보다 특별한 권력 지위에 있지 않습니다. 이 모델의 기여자와 모든 작업 그룹은 자발적으로 구성됩니다.

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

Proven 이 모델은 효과가 있습니다. 이 방식으로 운영되는 대규모 오픈 소스 프로젝트가 많이 있습니다(그중 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에 대한 피드백을 수집하고 통합할 책임이 있습니다.
• 모든 커뮤니티 구성원이 피드백을 제공할 수 있어야 합니다.
• 어느 시점에 지명된 전문가 중 한 명이 토론의 현재 상태, 특히 주요 의견 불일치 지점과 상충 관계를 설명하는 “요약 댓글”을 게시합니다. 동시에 해당 전문가는 다음 중 하나로 처리하자는 제안과 함께 “최종 의견 수렴 기간 동의”(FCP를) 제안합니다.
  • 수락합니다.
  • 조건부로 수락합니다.
  • 거부합니다.
  • PEP를 보류합니다.
• FCP에 들어가려면 PEP는 관련 관심 영역의 모든 전문가로부터 승인을 받아야 합니다.
• 결정이 내려지기 전에 이해관계자가 최종 이의를 제기할 수 있도록 FCP는 14일간 지속합니다.

논란이 매우 큰 PEP

핵심 기여자가 특정 PEP에 강하게 반대하는 경우, 해당 PEP의 FCP 기간에 투표를 통해 이를 거부하자는 동의를 제기할 수 있습니다. 투표 세부 사항은 아래의 “투표 방식”에서 설명합니다.

이는 최후의 수단이어야 하므로 드물게 발생해야 합니다. 이는 핵심 팀을 분열시키며 관련된 모든 사람에게 큰 부담이 되는 일입니다. 그러나 PEP의 FCP를 신청하는 전문가들은 투표를 통한 거부 동의가 가결될 가능성이 있는지 잘 판단해야 합니다. 그러한 경우에는 FCP를 성급하게 신청하지 않도록 주의해야 합니다.

전문가들은 PEP를 거부하고 싶어 하지만 다른 사람들은 수락되기를 원하는 반대 상황에 대해서는 구제 수단이 없습니다. 이를 통해 관련 전문가들이 무엇을 포함할지에 대해 최종 발언권을 갖게 됩니다. 정말로 해당 변경을 원한다면 전문가들을 설득할 방법을 찾으십시오.

공식 커뮤니케이션 채널의 중재자는 모든 이해관계자 간의 건전한 상호 작용을 보장하기 위해 무엇보다 먼저 행동 강령을 집행합니다. 집행에 따라 특정 참여자가 추가 토론에서 제외되고 그 결과 의사 결정 과정에서도 제외될 수 있습니다.

보류되거나 거부된 PEP 재검토

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

사전에 적절한 전문가의 지지를 얻지 못하면 연기되거나 거부된 PEP에 대한 pull request가 즉시 거부될 가능성이 높습니다.

기타 투표 상황

새로운 핵심 개발자 지명

제안자는 공식 커뮤니케이션 채널에 게시하여 새로운 핵심 개발자가 될 사람을 지명합니다. 투표가 시작됩니다.

기존 핵심 개발자 중 지명자에게 커밋 권한을 부여하는 것이 마음에 들지 않는 사람이 있다면, 지명 스레드에서 이러한 우려를 제기하는 것이 바람직합니다. 만족스러운 해결책이 없으면 반대 투표를 할 수 있습니다.

실제로 핵심 개발자로 누군가를 지명하는 일은 다른 사람들이 그 사람이 아직 핵심 개발자가 아니라는 사실에 놀랄 정도여야 합니다. 다시 말해, 후보자가 이미 다른 사람들에게 충분히 알려져 있고 신뢰받고 있을 때 지명해야 합니다. 잠재력을 근거로 한 지명은 피해야 합니다.

불신임 투표

• 핵심 팀에서 핵심 개발자 제거;
• 특정 관심 영역의 전문가 팀 해산.

이는 핵심 개발자가 핵심 팀에서 강제로 제거되거나 전문가 팀이 강제로 해산되는 상황을 설명합니다. 이러한 절차를 실행할 일이 결코 없기를 바라지만, 기능 장애가 있는 관심 영역을 어떻게 정상화할 수 있는지 보여 주기 위해 명시적으로 언급합니다.

핵심 개발자가 투표를 통해 핵심 팀에서 제거되면 프로젝트와 상호 작용할 수 있는 권한을 잃습니다. 버그 추적기와 GitHub에 게시할 수 있는 권한을 제거할지, 아니면 사안별로 향후 행동을 조정하는 데 그칠지는 Moderators의 재량에 달려 있습니다.

관심 영역의 전문가 팀이 해산되면, 다른 핵심 개발자들이 원할 때 그 공백을 메우기 위해 나설 수 있습니다. 해산된 전문가 팀의 구성원은 복귀를 위해 스스로를 지명할 수 없습니다.

투표 방식

이 문서에서 설명하는 모든 투표는 +1/-1/0 (“Yea”/”Nay”/”Present”)으로 기록되는 투표입니다. 다른 투표 값은 없으며, 특히 범위를 벗어난 값이나 +0.5와 같은 분수 값은 유효하지 않습니다.

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

위의 “핵심 인물과 그 기능”에 정의된 비활성 핵심 개발자는 기권하는 경우 합계에 포함하지 않습니다. 그러나 투표를 원하면 투표할 수 있으며, 그렇게 하면 활동 중인 것으로 집계됩니다. 투표는 기여의 한 형태입니다.

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

투표 기간 중 자신의 투표를 변경할 수 있습니다. 투표 기간 중 다른 개발자가 제출한 투표를 엿볼 수 있습니다.

상황마다 요구되는 투표 비율이 다릅니다:

• PEP를 투표로 거부하려면 활동 중인 핵심 개발자 수의 3분의 1을 초과하는 인원이 명시적으로 거부에 투표해야 합니다. 핵심 개발자의 3분의 1을 초과하는 인원이 PEP에 반대하기로 결정한다면, 이는 해당 변경에 찬성하는 핵심 개발자의 초다수가 존재하지 않는다는 의미임을 유의하십시오. 이는 PEP에서 설명한 형태로 변경해서는 안 된다는 점을 강하게 시사합니다.
• 신규 핵심 개발자를 지명하려면 이에 대한 반대 투표가 없어야 합니다.
• 불신임 투표가 성립하려면 활동 중인 핵심 개발자 수의 최소 3분의 2에 해당하는 초다수가 해당 안건에 명시적으로 찬성해야 합니다.

누락 사항

이 문서는 프로젝트 내에서 관심을 가질 수 있는 영역의 목록을 의도적으로 생략합니다. 또한 Python Software Foundation과 해당 행동 강령 작업 그룹이 수행하는 중재자의 선출 및 관리에 대해서도 다루지 않으며, 해당 그룹에는 conduct-wg@python.org으로 메일을 보내 연락할 수 있습니다.

감사의 말

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

이 문서에 큰 영감을 준 거버넌스 모델을 제공해 주신 Alex Crichton과 Rust 팀에 감사드립니다.

Copyright

This document has been placed in the public domain.