[Final] PEP 8002 - Open Source Governance Survey

원문 링크: PEP 8002 - Open Source Governance Survey

상태: Final 유형: Informational 작성일: 24-Aug-2018

PEP 8002 – 오픈 소스 거버넌스 설문조사

이 문서는 Python Enhancement Proposal (PEP) 8002의 내용을 한국어 사용자가 이해하기 쉽게 번역하고 정리한 것입니다. Python 개발자들이 이 PEP의 제안 내용, 도입 배경, 그리고 실제 Python 사용에 미치는 영향을 명확하게 이해할 수 있도록 돕는 것을 목표로 합니다.

초록 (Abstract)

이 PEP는 기존의 유사한 오픈 소스 및 자유 소프트웨어 프로젝트들의 거버넌스 모델을 조사하고 요약하여 제공합니다. 이는 귀도 반 로섬(Guido van Rossum)의 은퇴 이후 Python의 새로운 거버넌스 모델을 선택하는 데 유용한 참고 자료가 될 것입니다. 각 커뮤니티 설문조사를 개별적인 PEP로 작성하는 대신, 이 PEP에 모든 내용을 모아 정리합니다.

배경 (Rationale)

CPython은 거버넌스 위기를 겪는 첫 번째 오픈 소스 프로젝트가 아닙니다. 다른 프로젝트들도 존재 기간 동안 다양한 거버넌스 옵션을 실험했으며, 때로는 여러 번 변경하기도 했습니다. 이들의 경험에서 얻을 수 있는 유용한 교훈들이 Python의 의사 결정에 도움이 될 것입니다.

프로젝트 선택 (Project Choice)

많은 오픈 소스 프로젝트가 있지만, CPython과 몇 가지 핵심 지표에서 충분히 유사한 프로젝트들을 조사하는 것이 가장 유익합니다.

  • 기여자 수와 활동: (매우 작은 프로젝트의 거버넌스 모델은 우리의 목적에 그다지 도움이 되지 않으므로 규모에 따른 문제가 있습니다.)
  • 대부분 또는 부분적으로 커뮤니티 주도: (회사 주도 프로젝트는 회사의 계층 구조가 주요 참여자에게 권한을 가지므로 다른 거버넌스 옵션을 사용할 수 있습니다.)
  • 다소 공식적인 의사 결정 과정이 필요한 중요한 설계 결정에 직면한 프로젝트:

다음은 조사된 프로젝트들의 거버넌스 모델 요약입니다.

Rust

Rust의 거버넌스 구조는 Rust RFC #1068에 문서화되어 있습니다. 효과적인 거버넌스 프로세스는 특히 일상적인 운영 세부 사항의 경우, RFC로 완전히 성문화되지 않고 시간이 지남에 따라 유기적으로 성장합니다.

주요 인물 및 기능:

  • Rust 프로젝트에는 특정 영역을 담당하는 팀이 있습니다. 언어 기능에는 “lang team”이, 툴링에는 “dev tools” 및 “Cargo” 등이 있습니다.
  • 논쟁의 여지가 있는 문제에는 논의를 이끄는 촉진자가 있으며, 이들은 종종 의사 결정자가 아닙니다.
  • 기여자에게 가장 일반적인 역할은 팀 멤버십입니다.
  • 새로운 팀 멤버는 기존 팀 멤버의 지명으로 추가됩니다.

정규 의사 결정 과정:

  • 주요 작업은 GitHub 이슈 및 Pull Request (PR)를 통해 이루어집니다.
  • 모든 병합된 PR은 다음 Rust 안정 버전으로 반영됩니다.
  • IRC 및 Discord에서 공개 계획 및 분류(triage) 회의가 열리지만, 대부분의 작업이 GitHub를 통해 이루어지므로 인기가 많지 않습니다.

논쟁의 여지가 있는 의사 결정 과정:

  • 더 크거나 논쟁의 여지가 있는 작업은 RFC 프로세스를 거칩니다.
  • “최종 코멘트 기간(final comment period)”이 끝나면, 팀 멤버가 새로운 반대 의견을 제시하지 않는 한 RFC는 10일 후에 병합됩니다.
  • RFC가 “닫힘(closed)”으로 표시되면, 7일의 유예 기간 동안 닫아야 하는지 여부를 논의할 수 있습니다.

새 릴리스 계획:

  • 6주마다 Rust 컴파일러가 릴리스됩니다.
  • 몇 년에 한 번씩 “Edition”이라는 마일스톤 릴리스가 나옵니다.

시간에 따른 프로세스 변화:

  • Rust는 Graydon Hoare에 의해 시작되었으며, Mozilla의 후원 후 Graydon은 BDFL과 같은 역할을 했지만, 2013년 프로젝트를 떠났습니다. 이후 Rust는 BDFL 없이 운영됩니다.
  • “최종 코멘트 기간” 개념은 더 많은 공개 토론을 장려하기 위해 도입되었습니다.

OpenStack

OpenStack Foundation Bylaws는 프로젝트 거버넌스의 기본 구조를 명시하고 있으며, OpenStack Technical Committee (TC)에 일상적인 관리를 위임합니다.

주요 인물 및 기능:

  • OpenStack 커뮤니티는 여러 개의 고유한 프로젝트 팀으로 구성됩니다.
  • 각 팀은 해당 프로젝트의 Active Project Contributors (APCs)가 선출한 Project Team Lead (PTL)가 이끌고 있습니다.
  • APCs는 OpenStack Foundation의 개별 멤버가 되고 지난 1년 내에 변경 사항을 병합한 기여자입니다.
  • PTL은 팀 내에서 합의에 도달하지 못하는 경우 최종 의사 결정자 역할을 합니다.
  • Technical Committee (TC)는 OpenStack 전체 개발 관리를 담당합니다. 13명의 TC 멤버는 모든 프로젝트 팀의 APC가 직접 선출합니다.

정규 의사 결정 과정:

  • PTL 또는 TC 멤버 선거는 Condorcet 선거를 위해 https://civs.cs.cornell.edu를 사용합니다.
  • OpenStack 기여자 커뮤니티는 openstack-dev 메일링 리스트, gerrit 코드 리뷰 인스턴스, IRC 채널을 주요 논의 도구로 사용합니다.
  • 단일 팀에 국한된 정책 결정은 일반적으로 프로젝트의 핵심 리뷰 팀이 내립니다.
  • 모든 팀 정책 결정은 Technical Committee가 설정한 전체 정책과 호환되어야 합니다.

논쟁의 여지가 있는 의사 결정 과정:

  • 논쟁적이거나 복잡한 결정은 메일링 리스트 토론으로 확장되는 경우가 많습니다.
  • PTL은 단일 팀에 영향을 미치는 결정에 대한 합의 도달 시점을 결정하고, 합의에 도달하지 못했을 때 최종 결정을 내릴 책임이 있습니다.
  • TC는 팀 간의 문제가 다른 방법으로 해결될 수 없는 경우, 최후의 수단으로서 유사한 의사 결정 그룹 역할을 합니다.

새 릴리스 계획:

  • OpenStack은 약 6개월마다 주요 릴리스를 합니다.
  • 각 개발 주기(development cycle)의 일정은 릴리스 관리 팀이 제안합니다.
  • 각 개발 주기의 우선순위 결정은 팀 수준과 TC 수준에서 이루어집니다.

시간에 따른 프로세스 변화:

  • 지난 8년 동안 OpenStack 프로젝트 팀의 수가 2개에서 63개로 증가했으며, TC 구성도 이러한 성장에 맞춰 변경되었습니다.
  • 커뮤니티는 원래 프로젝트 팀이 아닌 “프로그램 영역(program areas)”을 중심으로 조직되었지만, 여러 팀이 다른 솔루션을 사용하여 동일한 기능 세트에서 작업하기를 원했을 때 실패했습니다.

Jupyter

Jupyter의 거버넌스 구조는 Jupyter Governance 저장소의 Main Governance Document에 문서화되어 있습니다.

주요 인물 및 기능:

  • Jupyter 거버넌스의 핵심 인물은 BDFL(Benevolent Dictator For Life), Fernando Perez 및 Steering Council입니다.
  • Fernando Perez는 프로젝트 창립자이자 현재이자 첫 번째 BDFL입니다.
  • Core Contributor는 전문 분야 또는 서브 프로젝트 내에서 프로젝트의 최선의 이익을 위해 행동할 수 있는 커밋 권한과 같은 권한을 부여받은 개인입니다.
  • Steering Council 멤버로 추천 및 초청되려면, 개인이 품질과 양적으로 상당한 기여를 하고 최소 1년 이상 지속적으로 기여한 Project Contributor여야 합니다.

정규 의사 결정 과정:

  • 주요 작업은 GitHub 이슈 및 Pull Request를 통해 이루어집니다.
  • 주간 공개 프로젝트 전반 회의가 YouTube에 녹화되어 게시됩니다.
  • 논의는 Gitter, Jupyter 메일링 리스트, 그리고 가장 자주 GitHub의 열린 이슈 및/또는 Pull Request에서 발생합니다.

논쟁의 여지가 있는 의사 결정 과정:

  • Jupyter 프로젝트 거버넌스의 기반은 개방성(Openness & Transparency), 적극적인 기여(Active Contribution), 기관 중립성(Institutional Neutrality)입니다.
  • Steering Council은 일반적인 커뮤니티 논의가 합리적인 시간 내에 문제에 대한 합의를 생성하지 못할 때 결정을 내릴 수 있습니다.

투표 (Voting):

  • 기술적 결정에 대한 투표는 거의 이루어지지 않습니다.
  • 다른 프로젝트 이슈의 경우, Steering Council은 거버넌스 PR 또는 이메일 제안을 통해 결정에 대한 투표를 요청할 수 있습니다.
  • BDFL은 변경 사항을 수락하거나 거부하거나 Steering Council의 결정을 재정의할 수 있지만, 이는 극히 드문 경우입니다.

릴리스 계획:

  • Jupyter 프로젝트는 단일 프로젝트가 아닌 여러 프로젝트로 구성되어 있으므로, 릴리스 계획은 주로 프로젝트의 핵심 기여자들이 주도합니다.

시간에 따른 프로세스 변화:

  • 프로세스는 시간이 지남에 따라 일관되게 유지되었으며, 이 접근 방식은 잘 작동했습니다.
  • 이 거버넌스 모델은 방향의 변화라기보다는 프로젝트가 이미 수행하고 있던 것을 공식화한 것이었습니다.

Django

거버넌스 구조는 Django Project의 조직 문서에 설명되어 있습니다.

주요 인물 및 기능:

  • 프로젝트는 세 가지 종류의 기여자를 인정합니다: 핵심 팀 멤버, Technical Board, 그리고 Fellow.
  • Technical Board는 기술적 선택을 이끌어갑니다.
  • Fellow는 새로운 티켓을 분류하고, 커미터와 커뮤니티의 패치를 검토하고 병합하는 유급 계약자입니다.
  • Technical Board는 18개월마다 (모든 주요 Django 릴리스마다) 핵심 팀 멤버에 의해 선출됩니다.

정규 의사 결정 과정:

  • 대부분의 일상적인 결정은 Fellows와 때로는 다른 활동적인 핵심 팀 멤버에 의해 이루어집니다.
  • 핵심 팀은 신규 멤버에 대해 투표하며, 이는 투표의 4/5 과반수를 필요로 합니다. Technical Board는 거부권을 가집니다 (지금까지 행사된 적 없음).

논쟁의 여지가 있는 의사 결정 과정:

  • Technical Board는 때때로 Django Enhancement Proposals (DEPs)를 승인하지만, 이는 드뭅니다. DEP 프로세스는 PEP를 대략적으로 모델링하며 DEP 1에 문서화되어 있습니다.
  • 합의에 도달할 수 없는 경우, Technical Board가 최종 결정권을 가집니다. 이는 행사된 적이 없습니다.

DEPs와 PEPs의 차이점:

  • 주요 차이점은 전체 워크플로가 이메일이 아닌 Pull Request를 기반으로 한다는 것입니다.
  • 제출 전과 과정 전반에 걸쳐 핵심 역할이 식별되어야 합니다.
  • shepherd 역할은 Technical Board의 개입 없이 DEP를 완료로 이끄는 역할을 합니다.
  • 이러한 프로세스 변경은 BDFL 없는 거버넌스 모델에서 더 분산되고 실행 가능하게 만듭니다.

새 릴리스 계획:

  • 릴리스는 고정된 시간 기반 일정에 따라 이루어지며, 18개월마다 주요 버전이 나옵니다.
  • 유급 Fellow가 필요한 작업을 보장하여 정시 릴리스는 일상적입니다.

시간에 따른 프로세스 변화:

  • Django는 원래 두 명의 BDFL을 가졌습니다: Jacob Kaplan-Moss와 Adrian Holovaty. 그들은 프로젝트 역사 9년 만에 은퇴했습니다. 이들의 은퇴 이후 DEP 프로세스가 정의되었습니다.

TypeScript

거버넌스 구조는 메인 TypeScript 저장소의 CONTRIBUTING.md 문서 외에는 외부적으로 문서화되어 있지 않습니다.

주요 인물 및 기능:

  • Microsoft에서 일하는 공식적인 설계 팀과 릴리스 관리 팀이 있습니다.
  • 프로젝트의 주요 인물은 현재 Anders Hejlsberg입니다.

정규 의사 결정 과정:

  • Microsoft는 강력한 계획 문화를 가지고 있어 개발 로드맵이 미리 발표되고, 설계 논의 노트가 빠르게 게시되며, 회의는 때때로 Skype를 사용하여 방송됩니다.
  • GitHub의 Pull Request를 통해 외부 기여가 장려됩니다.
  • 소셜 미디어(트위터)에서도 논의가 이루어집니다.

논쟁의 여지가 있는 의사 결정 과정:

  • Hejlsberg는 언어 설계 측면에서 프로젝트의 중심 인물이며, 커뮤니티의 요구 사항을 응집력 있는 전체로 통합합니다.
  • 언어 설계에 외부적으로 기여하기 위한 공식적인 프로세스는 없습니다.
  • TypeScript 팀은 커뮤니티 제안을 필터링하고 통합합니다. 이 모델의 단점은 커뮤니티 참여가 Pull Request 및 제안으로 제한된다는 것입니다.

새 릴리스 계획:

  • Microsoft가 릴리스 일정을 결정하고, 날짜와 기능을 미리 전달합니다.
  • 버전별 릴리스는 1~3개월마다 이루어지며, GitHub에서 로드맵을 확인할 수 있습니다.

시간에 따른 프로세스 변화:

  • TypeScript는 Microsoft가 완전히 공개적으로 개발한 최초의 주목할 만한 프로젝트일 것입니다.
  • 프로젝트가 이동된 후 커뮤니티 참여가 크게 증가했습니다.

Astropy

Astropy 프로젝트 팀의 책임은 여러 다른 역할에 걸쳐 분포되어 있습니다.

주요 인물 및 기능:

  • Astropy 프로젝트를 감독하는 주요 기관은 Astropy Coordination Committee (CoCo)입니다.
  • CoCo의 핵심 역할은 재정 문제 처리, Astropy 프로젝트에 참여하려는 새로운 패키지 승인, Astropy Proposals for Enhancement (APEs) 승인 또는 거부 등입니다.
  • 위원회는 현재 4명의 멤버로 구성되어 있으며, 요구 사항에 따라 증가하거나 감소할 수 있습니다.

정규 의사 결정 과정:

  • 코드 수준 결정:
    • 각 서브 패키지에는 공식 유지 관리자(maintainer)와 한 명 이상의 대리인(deputies)이 있습니다.
    • 코드 수준 결정은 GitHub 이슈 또는 Pull Request (PR)에서 일반적으로 합의를 기반으로 이루어집니다.
    • 구체적인 의견 불일치가 있는 경우, 논의에 참여한 사람들의 다수결 투표로 결정되며, 동점 발생 시 CoCo가 개입합니다.
  • 비 코드 결정:
    • 비 코드 결정(스프린트 일정, 버그 수정 릴리스 시기 등)은 일반적으로 astropy-dev 메일링 리스트에 메시지 투표 형식으로 발표됩니다.
  • 투표:
    • 투표는 일반적으로 GitHub 또는 astropy-dev 메일링 리스트에서 +1/-1 형식을 사용합니다.
    • CoCo가 다수결 결정을 재정의할 수 있는 거부 메커니즘은 없습니다.

논쟁의 여지가 있는 의사 결정 과정:

  • 간단한 논쟁적 결정은 일반적으로 astropy-dev 메일링 리스트에서 논의되며, 합리적인 시간 후에 명확한 합의/타협이 이루어지거나, CoCo가 정체를 피하기 위해 결정을 내립니다.
  • 더 복잡한 결정은 PEP 프로세스를 모델링한 APE 프로세스를 따릅니다. 여기서는 모든 사람에게 공개된 토론 기간이 지난 후 CoCo가 최종 결정을 내립니다.

윤리적 문제:

  • 프로젝트에는 Code of Conduct 위반과 같은 민감한 문제에 대한 대체 연락처를 제공하는 옴부즈맨(Ombudsperson)이 있습니다.

새 릴리스 계획:

  • 주요 릴리스 시기는 고정된 일정(6개월마다)에 따르며, 그 시점에 포함된 모든 것이 릴리스됩니다.

시간에 따른 프로세스 변화:

  • CoCo와 “오픈 개발” 정신은 프로젝트 초기에 관심 있는 Python 지향 천문학자와 관련 소프트웨어 엔지니어들의 일련의 투표 후에 형성되었습니다.
  • 공식적인 역할과 대부분의 다른 사항들은 커뮤니티가 성장함에 따라 진화적인 단계로 나타났습니다.

자기 평가 (Self-appreciation):

  • 시간이 있는 사람이라면 누구나 참여하여 제안하거나(보통 PR을 통해) 선호하는 것에 투표할 수 있다는 사실은 “우리는 모두 함께 한다”는 인식을 불러일으키며, 이는 더 잘 조정된 노력으로 이어집니다.
  • 또한, CoCo가 주로 동점 해결 기관으로서 기능한다는 것은 자신의 의지를 강요하는 독재자의 느낌이 없으면서도, 완전한 민주적 거버넌스 모델을 경계하는 외부 조직에게 명확한 연락 지점을 제공합니다.

보너스: Microsoft

위에서 설명한 “관련 프로젝트” 선택 과정에도 불구하고, 재정적으로 의사 결정에 책임이 있는 회사들이 어떻게 결정을 내리는지 고려해 볼 가치가 있습니다. 이는 Python에 즉시 적용 가능한 모델이라기보다는 최종 설계나 선택에 영향을 미칠 수 있는 추가적인 통찰력으로 의도되었습니다.

주요 인물 및 기능:

  • Microsoft는 궁극적으로 CEO에게 보고하는 계층 구조를 가지고 있습니다.
  • CEO 아래에는 여러 조직이 있으며, 일부는 엔지니어링 프로젝트에 중점을 둡니다. 이들은 Executive Vice Presidents (EVPs)가 이끌고 CEO에게 보고합니다.
  • 각 EVP 아래에는 여러 Corporate Vice Presidents (CVPs)가 있으며, 각 CVP는 하나 이상의 제품을 담당합니다.
  • CVP 아래의 각 제품에는 Program Managers (PMs)와 Engineering Managers로 구성된 팀이 있습니다.

정규 의사 결정 과정:

  • 외부 사용자에게 보이지 않는 제품 코드 변경은 전적으로 엔지니어링 팀이 수행합니다.
  • 특정 기능 사용자에게 영향을 미치는 결정은 해당 기능의 PM 팀이 내립니다.
  • CVP가 설정한 방향과 명확하게 일치하지 않는 결정은 논쟁의 여지가 있는 프로세스로 에스컬레이션됩니다.

논쟁의 여지가 있는 의사 결정 과정:

  • 결정이 팀 간 조정을 요구하거나, 이전 CVP 지침과 명확하게 일치하지 않을 때, 팀은 의사 결정을 에스컬레이션합니다.
  • CVPs는 일반적으로 기능 팀 작업의 모든 측면에 대해 자세히 알지 못하므로, 기능 팀은 CVP가 추가 지식 없이 결정할 수 있도록 권장 사항과 충분한 맥락을 모두 제공해야 합니다.
  • CVPs가 내린 결정은 일반적으로 자의적이며 최종적이지만, 일반적으로 그들의 근거를 제공합니다.

새 릴리스 계획:

  • 릴리스는 여러 기능 팀을 조정하는 것을 포함하므로, 모든 팀의 입력을 포함하려고 시도하는 경우는 드뭅니다.
  • 일정은 계획된 이벤트/컨퍼런스 또는 미디어 관심을 활용할 기회와 같은 광범위한 생태계 요구 사항에 따라 결정됩니다.

부록 1: 템플릿 질문 (Annex 1: Template questions)

조사된 프로젝트 평가 및 상호 작용을 안내하는 템플릿으로 다음 질문 세트가 사용되었습니다.

  • 거버넌스 모델이 어떻게 설정되었는지에 대한 공개 문서가 있습니까?
  • 실제로 프로세스는 어떻게 진행됩니까?
    • 주요 인물은 누구입니까?
    • 기여자는 어떤 “특별한 지위”를 가질 수 있습니까? 어떻게 선출/지위가 할당됩니까?
    • 정규 결정은 어떻게 이루어집니까?
    • 논쟁의 여지가 있는 결정은 어떻게 이루어집니까?
    • 투표 메커니즘이 있습니까? 어떻게 작동합니까? 투표는 실제로 얼마나 자주 발생합니까?
    • 거부 메커니즘이 있습니까? 실제로 얼마나 자주 사용되었습니까?
  • 프로세스는 어떻습니까?
    • 어떤 부분이 잘 작동합니까?
    • 어떤 부분이 더 잘 작동할 수 있습니까?
    • 잘 작동하지 않을 때는 어떤 모습입니까?
    • 전적으로 당신에게 달려 있다면 무엇을 바꾸겠습니까?
  • 관련 프로젝트 작업:
    • 언제 릴리스가 이루어지고 무엇이 포함될지 어떻게 결정합니까?
    • 누가 커밋 권한을 얻는지 어떻게 결정합니까?
    • 어디에서 논의를 합니까? (GitHub, 메일링 리스트, 대면 회의 등)
    • RFC/PEP와 유사한 프로세스가 있습니까?
    • 누가 해당 토론 채널에 액세스할 수 있습니까? 이 액세스는 어떻게 부여/취소됩니까?
    • 누가 해당 토론을 중재합니까?
    • 참가자를 검열합니까(어떻게)?
  • 프로세스 진화:
    • 이 프로세스는 역사적으로 어떻게 진화했습니까?
    • 미래에는 어떻게 변경될 수 있습니까?

이 문서는 퍼블릭 도메인에 공개되었습니다.

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

Comments