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

Author:: Barry Warsaw <barry at python.org>, Łukasz Langa <lukasz at python.org>, Antoine Pitrou <solipsis at pitrou.net>, Doug Hellmann <doug at doughellmann.com>, Carol Willing <willingc at gmail.com>
Status:: Final
Type:: Informational
Topic:: Governance
Created:: 24-Aug-2018

Table of Contents

초록
근거
- 프로젝트 선정
Rust
OpenStack
Jupyter
Django
TypeScript
Astropy
보너스: Microsoft
감사의 말
부록 1: 질문 템플릿
Copyright

번역·라이선스 안내

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

초록

이 PEP는 기존의, 그리고 이와 유사한 오픈 소스 및 자유 소프트웨어 프로젝트의 거버넌스 모델을 조사하고, Guido’s retirement 이후 Python이 새로운 거버넌스 모델을 선택할 때 유용한 참고 자료로 활용할 수 있는 요약을 제공합니다.

이러한 커뮤니티 조사마다 별도의 PEP를 작성하는 대신, 모두 이 PEP에 수록합니다.

근거

CPython은 거버넌스 위기를 겪은 최초의 오픈 소스 프로젝트가 아닙니다. 다른 프로젝트들도 존속 기간 동안 여러 거버넌스 방안을 실험했으며, 때로는 여러 차례 실험하기도 했습니다. 이러한 경험에서 얻을 수 있는 유용한 교훈이 있으며, 이는 우리가 내릴 결정을 알리는 데 도움이 됩니다.

프로젝트 선정

오픈 소스 프로젝트는 많지만, 다음과 같은 몇 가지 주요 지표에서 CPython과 충분히 유사한 프로젝트를 조사하는 것이 가장 유익합니다.

기여자의 수와 활동(매우 작은 프로젝트의 거버넌스 모델은 우리의 목적에 그다지 유익한 통찰을 제공하지 못하는 규모 확장 문제가 있습니다);
대부분 또는 부분적으로 커뮤니티 주도일 것(기업 주도 프로젝트는 기업 계층 구조가 주요 참여자에게 영향력을 행사하므로 다른 거버넌스 방안을 선택할 수 있습니다);
어느 정도 공식적인 의사 결정 절차가 필요한 중요한 설계 결정에 직면해 있을 것.

Rust

거버넌스 구조는 Rust RFC #1068에 문서화되어 있습니다.

실제 거버넌스 절차는 RFC로 완전히 성문화되지 않은 채 시간이 지나면서 유기적으로 발전하며, 특히 일상적인 운영 세부 사항의 경우 그러합니다. 한 가지 예로 2018년 2월의 formation of Domain Working Groups를 들 수 있습니다.

Rust 프로젝트에는 특정 영역을 담당하는 팀이 있습니다. 언어 기능에는 “lang team”이 있고, 도구에는 “dev tools”와 “Cargo” 등이 있습니다. 논쟁적인 사안에는 토론을 이끄는 퍼실리테이터가 있으며, 이들은 의사 결정자가 아닌 경우가 많습니다. 일반적으로 퍼실리테이터는 제안된 변경 사항의 작성자입니다(아래의 “논쟁적인 의사 결정 절차”를 참조하십시오). 퍼실리테이터는 모든 주요 의사 결정자와 관심 있는 커뮤니티 구성원이 함께 참여하도록 합니다. 퍼실리테이터는 반복적인 조정을 통해 합의할 수 있는 결과를 향해 나아갑니다.

실제로 이는 의사 결정이 코어 팀으로 넘어가는 일이 드물다는 의미입니다.

기여자에게 가장 일반적인 역할은 팀 구성원 자격입니다. 팀 구성원 자격 없이 이슈 분류나 코드 리뷰 권한을 갖는 경우는 드뭅니다. 기여자는 완전한 커밋 접근 권한을 가지며, 코드 소유권의 분리는 신뢰를 기반으로 합니다. 컴파일러 저장소에 직접 작성하는 것은 바람직하지 않게 여겨지며, 모든 변경 사항은 풀 리퀘스트를 거치고 검토와 승인을 받은 후 통합 봇이 병합합니다.

새 팀 구성원은 기존 팀 구성원의 추천을 통해 추가됩니다.

일반적인 의사 결정 절차

주요 작업은 GitHub 이슈와 풀 리퀘스트를 통해 이루어집니다. 팀 구성원 누구든 풀 리퀘스트를 승인하면 추가 절차 없이 병합할 수 있습니다. 병합된 모든 풀 리퀘스트는 Rust의 다음 안정 버전에 포함됩니다.

멘션을 통해 관련자에게 알리는 것이 중요합니다. 모든 GitHub 활동에 대해 쏟아지는 이메일을 지켜보는 일은 선호되지 않습니다.

IRC와 Discord에서는 공개된 계획 수립 및 트리아지 회의가 열립니다. 대부분의 작업이 GitHub를 통해 이루어지기 때문에 이러한 회의는 그다지 인기가 없습니다. 공식 Rust 포럼(https://users.rust-lang.org/ 및 https://internals.rust-lang.org/)에서도 논의가 이루어집니다. 회의록을 작성하고 code of conduct을 시행하는 전담 조정 팀이 있습니다.

논쟁적인 의사 결정 과정

규모가 크거나 논쟁적인 작업은 RFC process를 거칩니다. 이를 통해 모두가 자신의 생각을 표현할 수 있으며, 합의에 이를 때까지 반복적으로 다듬어 갑니다. 관련 팀 구성원의 모든 차단 우려 사항이 해결되면 어느 시점에 그들은 RFC를 승인하고, RFC는 “최종 의견 수렴 기간”에 들어갑니다. 이를 위해 모든 참여자의 합의가 필요한 것은 아니며, 제안에 반대하는 강한 합의가 존재해서는 안 됩니다.

팀 구성원이 새로운 차단 우려 사항을 제기하지 않는 한, RFC는 10일 후 병합됩니다. “병합”은 기능을 구현하고 통합하기 위한 작업을 이제 중단 없이 진행할 수 있음을 의미합니다. RFC가 승인되기 위해 참조 구현을 갖출 필요는 없습니다.

“최종 의견 수렴 기간”의 다른 가능한 결과는 다음과 같습니다:

RFC를 연기합니다(PEP의 Deferred 상태와 유사합니다),
차단 우려 사항을 해결할 수 있다면 RFC를 다시 논의에 부칩니다, 또는
차단 우려 사항을 해결할 수 없다면 RFC를 종료합니다. RFC가 종료로 표시되면, 종료해야 하는지 논의할 수 있는 7일의 유예 기간이 있습니다.

실제로 RFC에 우려 사항을 제기하는 일은 처음에는 매우 자주 발생하지만, RFC가 완전히 폐기되는 원인이 되는 경우는 드뭅니다.

이 과정은 이해관계가 적은 변경 사항이나 소규모 변경 사항에 잘 확장됩니다. 가장 규모가 큰 논쟁적 변경 사항에서는 논의가 감당하기 어려워집니다. 이는 현재(2018년 8월 기준) Rust 팀이 고민하고 있는 주제입니다(참조: “Listening and Trust, part 1”, “Listening and Trust, part 2”, “Listening and Trust, part 3”, “Proposal for a staged RFC process”).

새 릴리스 계획 수립

Rust 컴파일러는 6주마다 그 시점에 포함하고 있던 내용을 담아 릴리스됩니다. 아직 LTS 채널이나 릴리스는 없지만, 재배포자가 개발을 더 원활하게 따라갈 수 있도록 이 개념을 도입할 계획입니다.

몇 년마다 소위 “Edition”이라고 하는 릴리스가 출시됩니다. 이는 업데이트된 문서와 도구의 전체 세트를 포함하는 마일스톤 릴리스입니다. 이전 에디션과 하위 호환되지 않을 수 있습니다. 외부 패키지는 크레이트 메타데이터에서 호환성을 깨뜨리는 변경 사항을 선택적으로 적용합니다. Rust 컴파일러는 자신의 릴리스보다 이전에 존재했던 모든 에디션을 지원합니다. 지원되는 모든 에디션의 크레이트 간 연결이 가능합니다.

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

Rust 프로그래밍 언어는 Graydon Hoare가 몇 년 동안 개인 프로젝트로 개발하면서 시작되었습니다. Mozilla가 프로젝트 후원을 시작하자 Graydon이 BDFL 스타일의 인물로서 팀은 서서히 성장했습니다. 그는 2013년에 프로젝트를 떠났습니다. 그 이후 Rust는 BDFL 없이 운영되고 있습니다. 이후 RFC 프로세스가 마련되었습니다. 처음에는 비공개 주간 화상 회의에서 일부 설계 논의가 이루어졌지만, 이 회의는 2015년 5월(Rust 1.0 릴리스 이전)에 폐지되었으며, 이후 공개 토론과 팀의 직접적인 영향력 행사로 자연스럽게 대체되었습니다.

시간이 지나면서 팀의 수가 증가하고 있습니다. 코어 팀이 내리는 기술적 결정의 수는 감소하고 있으며, 대신 해당 결정은 각 팀에 위임됩니다.

이미 내려진 성급한 결정을 되돌려야 하는 상황을 피하고, 곧 이루어질 변경 사항에 대응할 수 있도록 더 많은 공개 토론을 장려하기 위해 “최종 의견 수렴 기간”이라는 개념이 도입되었습니다.

OpenStack

OpenStack Foundation 정관은 프로젝트 거버넌스의 기본 구조를 규정하며, 제 IV조가 오픈 소스 프로젝트의 일상적인 관리를 OpenStack 기술 위원회(TC)에 위임하고, TC 회원 정책은 기술 위원회의 선출 방식을 대략적으로 정의합니다. TC는 보다 상세한 거버넌스 문서 모음을 발행하며, 여기에는 팀 구조, 직책 출마 자격을 설정하기 위한 정확한 규칙, 다양한 선거인단을 설정하기 위한 기준을 설명하는 TC 헌장이 포함됩니다.

주요 인물과 그 기능

OpenStack 커뮤니티는 여러 개의 서로 다른 프로젝트 팀으로 구성되며, 각 팀은 소프트웨어의 서로 다른 구성 요소(블록 스토리지 관리, 컴퓨팅 관리 등)를 제작하거나 커뮤니티가 따르는 프로세스의 서로 다른 부분(예: 릴리스 일정 추적)을 관리합니다. 각 팀은 해당 프로젝트의 프로젝트 팀 리드 (PTL)가 이끌며, PTL은 해당 프로젝트의 활성 프로젝트 기여자가 선출합니다.

활성 프로젝트 기여자(APC)는 특정 프로젝트 팀에 최근 기여한 사람입니다. APC 자격에는 공식적으로 두 가지 요건이 필요합니다. OpenStack Foundation의 개인 회원이 되는 것(회원 가입은 무료)과 프로젝트 팀이 관리하는 저장소에서 지난 1년(두 번의 개발 주기) 이내에 변경 사항을 병합하는 것입니다.

선출된 PTL의 임기는 한 번의 개발 주기(대략 6개월)와 같습니다. 한 사람이 PTL로 연속해서 재임할 수 있는 횟수에는 제한이 없으며, 여러 임기를 연속으로 수행하는 경우도 흔합니다. 특정 주기에 PTL로 활동하겠다고 자원하는 후보자가 한 명뿐인 팀도 드물지 않으며, 이 경우 선거가 필요하지 않습니다.

PTL은 일부 책임을 명시적으로 위임한 경우를 제외하고 모든 상황에서 팀을 대표합니다. 예를 들어 많은 팀은 개발 주기의 릴리스 프로세스를 관리하도록 별도의 릴리스 연락 담당자를 지정합니다. 또한 팀 구성원 간에 합의에 도달할 수 없는 경우 PTL은 최종 의사 결정자 역할을 합니다.

APC는 모두 팀의 PTL에 투표하지만, 그 밖의 많은 경우에는 팀의 정책 결정에 대해 core reviewer 팀만 자문을 받습니다. 누구나 모든 OpenStack 프로젝트의 모든 패치를 검토할 수 있습니다. 누군가 프로젝트의 기술적 문제를 잘 이해하고 있으며, 리뷰에 유용한 피드백을 제공하고, 프로젝트가 나아가는 방향을 이해한다는 점을 입증하면, core review team의 구성원이 되도록 초대받을 수 있습니다. 다른 많은 커뮤니티와 달리, 이 지위가 검토 없이 코드를 제출할 권한을 부여하지는 않습니다. 오히려 다른 기여자가 작성한 코드를 검토하고 팀의 의사 결정 논의에 참여할 것을 약속하도록 요구합니다. 누군가에게 core review team의 구성원이 되어 달라고 요청하는 것은 강한 신뢰의 표시입니다.

Technical Committee(TC)는 OpenStack 전체의 개발을 관리할 책임이 있습니다. Technical Committee의 13명 구성원은 모든 프로젝트 팀의 APC가 직접 선출합니다. 각 구성원의 임기는 두 번의 개발 주기(대략 1년)이며, 연속성을 보장하기 위해 언제든지 구성원 임기의 절반 정도만 만료되도록 선거를 나누어 실시합니다. TC는 새 프로젝트 팀을 추가하는 기준, Python 2의 지원 중단 정책, 테스트 요구 사항 등의 전반적인 정책을 수립합니다.

정기 의사 결정 프로세스

모든 PTL 또는 TC 구성원 선거는 https://civs.cs.cornell.edu 를 사용하여 Condorcet 선거를 실시합니다. 이 시스템은 엄격한 인기도보다 합의된 후보를 중시하기 때문에 선택되었습니다.

OpenStack 기여자 커뮤니티는 논의를 위해 다음 3가지 주요 도구에 의존합니다: openstack-dev 메일링 리스트, https://review.openstack.org 에 있는 Gerrit 코드 리뷰 인스턴스, 그리고 Freenode의 OpenStack 전용 IRC 채널 모음입니다. 기여자들이 주로 중국에 기반을 둔 팀이 몇 개 있으며, 이들은 IRC에 접속하는 데 어려움을 겪습니다. 이러한 팀은 대신 WeChat과 같은 대체 플랫폼을 사용하는 경향이 있습니다.

특정 결정에 대해 논의하는 데 사용하는 도구는 그 결정의 중요도와 영향에 따라 달라집니다. 더 다양한 시간대와 방화벽 환경에서 비동기 논의를 지원하기 위해 누구나 메일링 리스트나 gerrit 중 하나를 사용하도록 권장하며, 특히 커뮤니티의 나머지 구성원에게 최종 결정을 알릴 때 그러합니다.

단일 팀으로 제한된 정책 결정은 일반적으로 프로젝트의 core review team이 내리며, 정책과 의사 결정 프로세스는 팀마다 다를 수 있습니다. 일부 그룹은 문서 저장소에 팀 정책을 기록하고 코드 리뷰 도구(gerrit)를 사용하여 해당 정책에 투표합니다. 일부 팀은 IRC에서 임시로 또는 정기적으로 예정된 회의 중에 정책을 논의하고 그곳에서 결정을 내립니다. 일부 팀은 그러한 논의에 메일링 리스트를 사용합니다. 팀의 PTL은 논의가 관리되고 결과가 전달되도록 할 책임이 있으며, 직접 수행하거나 해당 작업을 다른 사람에게 위임하도록 보장합니다.

모든 팀 정책 결정은 Technical Committee가 수립한 전반적인 정책과 호환되어야 합니다. TC는 전체 기여자 커뮤니티에 적용되는 더 광범위한 거버넌스 결정을 내리는 경향이 있으므로, 해당 결정을 논의하고 투표하는 프로세스는 통과에 필요한 표 수와 논의에 필요한 최소 기간을 명시하는 등 더 공식적으로 설명되어 있습니다. 예를 들어 대부분의 동의안은 통과하려면 구성원의 3분의 1(5명)이 필요하며, 통과에 필요한 충분한 표를 받은 후에도 최소 3일 동안 논의를 열어 두어 반대 의견을 등록할 시간이 있도록 합니다. 자세한 내용은 Technical Committee 헌장 및 하우스 룰을 참조하십시오.

중요한 설계 결정은 일반적으로 PEP와 어느 정도 유사하며 요구 사항, 대안 및 구현 세부 사항을 다루는 사양 문서를 검토하여 논의합니다. 모든 기여자로부터 피드백을 요청한 다음, 프로젝트의 core review team 구성원이 최종적으로 사양을 승인하거나 거부합니다. 일부 팀은 설계를 승인하는 데 검토자 2명만 필요로 하는 반면, 다른 팀은 설계가 승인되기 전에 더 강력한 합의의 표시를 요구합니다. 각 팀은 기여자가 중요한 새 기능의 설계를 일찍 구체화하고 주기 후반의 변경으로 인한 위험을 피하도록 장려하기 위해 각 개발 주기 내 사양을 승인하기 위한 마감일을 정합니다.

더 작은 기술적 결정은 일반적으로 변경을 구현하는 데 필요한 패치를 검토하여 이루어집니다. 누구나 어떤 패치든 검토하고 기술적 피드백을 제공할 수 있지만, 궁극적으로 대부분의 변경 사항을 승인하려면 팀의 핵심 리뷰어 두 명이 필요합니다(오타와 같은 사소한 변경이나 CI 게이팅 시스템을 차단 해제하는 수정 사항에는 예외가 적용되는 경우가 많습니다).

논쟁적인 의사 결정 절차

논쟁의 여지가 있거나 단순히 복잡한 결정은 사양 검토를 넘어 메일링 리스트 논의로 확대되는 경우가 많습니다. 또한 정기적으로 예정된 대면 커뮤니티 모임에서 논의로 이어지는 경우가 많습니다. 커뮤니티의 많은 구성원이 이러한 행사에 참석할 수 없기 때문에 논의를 요약하고, 가능한 한 온라인 도구를 사용하여 최종 결정을 내립니다.

PTL은 단일 팀에 영향을 미치는 결정에 대해 합의가 이루어졌는지 판단하고, 합의에 도달하지 못했지만 반드시 결정을 내려야 하는 드문 경우에 최종 결정을 내릴 책임이 있습니다. TC는 팀 간의 문제를 다른 방법으로 해결할 수 없는 경우를 위한 유사한 최후의 의사 결정 기관으로 기능합니다. 이러한 의사 결정의 상향 이관은 실제로 거의 필요하지 않습니다. 직접 관여한 기여자들은 일반적으로 결정을 다른 사람에게 이관하기보다 합의에 도달하는 것을 선호하기 때문입니다.

새 릴리스 계획

OpenStack은 약 6개월마다 주요 릴리스를 제공합니다. 이는 날짜를 기준으로 조정되는 릴리스로, 모든 참여 프로젝트에서 해당 시점까지 완료된 작업을 포함합니다. 일부 프로젝트 팀은 6개월마다보다 더 자주 릴리스합니다(이는 다른 팀이 사용하는 라이브러리를 구축하는 팀에서 특히 그렇습니다). 이러한 소규모 릴리스는 정당화할 만한 콘텐츠(새 기능 또는 버그 수정)가 있을 때 만들어지는 경향이 있습니다.

각 개발 주기의 일정과 마감일 및 최종 릴리스 날짜는 릴리스 관리 팀이 재단 직원과 협력하여 제안합니다(릴리스는 일반적으로 대면 행사의 일정에 맞춰 조정됩니다). 그런 다음 최종 날짜가 확정되기 전에 커뮤니티가 피드백을 제공할 기회를 갖습니다.

각 개발 주기의 우선순위에 관한 결정은 팀 수준과 TC 수준에서 이루어집니다. 핵심 리뷰 팀은 버그 수정 및 새 기능 구현과 같은 내부 작업의 우선순위를 정합니다. TC는 커뮤니티 목표를 선정하며, 일반적으로 모든 팀의 일정량의 작업이 필요합니다. 각 주기 초에 이러한 우선순위에 동의하면 팀이 작업을 조율하는 데 도움이 됩니다. 구현에 여러 팀 구성원의 검토가 필요하므로 이는 특히 중요합니다.

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

지난 8년 동안 OpenStack 프로젝트 팀의 수는 2개에서 63개로 증가했습니다. 이러한 성장에 맞추기 위해 기술 위원회의 구성도 변경되었습니다. 처음에 TC는 PTL로 구성되었지만, 구성원이 늘어나면서 해당 그룹이 효과적으로 기능하기 어려워졌습니다.

커뮤니티는 프로젝트 팀이 아니라 “프로그램 영역”을 중심으로 조직되기도 했습니다. 프로그램 영역은 텔레메트리 수집이나 블록 스토리지 관리와 같은 기능 집합을 다루었습니다. 여러 팀이 서로 다른 해결책을 사용하여 동일한 기능 집합을 작업하려 하면서 이러한 조직 방식은 실패했습니다. 팀이 제공하는 코드를 중심으로 조직하면 서로 다른 팀이 동일한 요구 사항을 서로 다르게 해석할 수 있습니다. 예를 들어 현재 여러 팀이 서로 다른 배포 도구를 작업하고 있습니다.

Jupyter

거버넌스 구조는 주요 거버넌스 문서 내의 Jupyter 거버넌스 저장소에 문서화되어 있습니다.

효과적인 거버넌스 프로세스는 프로젝트의 요구 사항이 변화함에 따라 시간이 지나면서 유기적으로 발전합니다. 거버넌스 문서에 대한 공식적인 변경 사항은 의견을 제시할 수 있는 공개 기간을 두고 Pull Request를 통해 제출합니다. 공개 기간이 지난 후 Steering Council은 PR 변경 사항을 비준하기 위한 투표를 요청할 수 있습니다. 승인되려면 Steering Council의 최소 80%가 투표해야 하며, 투표의 2/3 이상이 찬성이어야 합니다. BDFL은 단독으로 변경 사항을 승인하거나 거부하고 Steering Council의 결정을 번복할 수 있지만, 이는 매우 드문 일이 될 것입니다.

주요 인사와 그 기능

Jupyter 거버넌스의 주요 인사는 BDFL인 Fernando Perez와 Steering Council입니다. 기여자에게 core contributor라는 특별한 지위를 부여할 수 있습니다. 일부는 기관 기여자일 수도 있으며, 이들은 기관 파트너에서 공식 직무의 일환으로 프로젝트에 기여하는 사람들입니다.

프로젝트 창립자인 Fernando Perez는 현재이자 최초의 BDFL입니다. BDFL은 원하는 기간만큼 재임할 수 있습니다. BDFL 승계 계획은 주요 거버넌스 문서에 설명되어 있습니다. 요약하면 BDFL은 다음 BDFL을 임명할 수 있습니다. 예의상 BDFL은 Steering Council과 협의할 것으로 기대됩니다. BDFL이 후임자를 임명할 수 없는 경우 Steering Council이 한 명을 추천합니다.

핵심 기여자는 자신의 전문 분야 또는 subproject 내에서 프로젝트에 최선의 이익이 되도록 활동할 수 있는 권한(예: 커밋 권한)을 부여받은 사람들입니다. 기존 핵심 기여자는 일반적으로 프로젝트 저장소의 README에 나열된 숙련된 핵심 기여자인 프로젝트 리드들의 합의를 모아 누군가에게 핵심 기여자 권한을 부여하도록 추천합니다.

Steering Council 구성원으로 추천받고 초대되려면, 개인은 최소 1년 동안 지속적으로 양과 질 면에서 상당한 기여를 해 온 Project Contributor여야 합니다. 잠재적인 Council 구성원은 기존 Council 구성원이 지명하며, 잠재적인 구성원에게 해당 역할에 관심이 있고 맡을 의향이 있는지 물어본 후 기존 Council이 투표로 결정합니다.

정규 의사 결정 프로세스

Project Jupyter는 여러 GitHub 조직과 해당 조직 내의 서브프로젝트로 구성됩니다. 주요 작업은 GitHub 이슈와 pull request를 통해 이루어집니다. 모든 팀 구성원이 pull request를 승인하면 추가 절차 없이 병합할 수 있습니다. 병합된 모든 pull request는 서브프로젝트의 다음 안정 릴리스에 포함됩니다.

매주 공개되는 Project 전체 회의가 있으며, 이 회의는 녹화되어 YouTube에 게시됩니다. Project Jupyter의 서브프로젝트인 일부 대규모 GitHub 조직(예: JupyterLab 및 JupyterHub)에는 주간 또는 월간 일정으로 추가 공개 팀 회의가 있을 수 있습니다. 토론은 Gitter, Jupyter 메일링 리스트, 그리고 가장 빈번하게는 GitHub의 공개 이슈 및/또는 pull request에서 이루어집니다.

논쟁적인 의사 결정 프로세스

Project Jupyter 거버넌스의 기반은 다음과 같습니다.

개방성과 투명성
적극적인 기여
기관 중립성

일상적인 프로젝트 활동에서 Steering Council 구성원은 다른 모든 기여자 및 커뮤니티와 동등한 동료로서 모든 논의, 코드 검토 및 기타 프로젝트 활동에 참여합니다. 이러한 일상적인 활동에서 Council 구성원은 Council의 구성원이라는 이유로 어떠한 특별한 권한이나 특권도 행사하지 않습니다. 그러나 Council 구성원은 기여의 품질과 양, 그리고 프로젝트 소프트웨어와 서비스에 대한 전문 지식으로 인해, 경험이 상대적으로 부족한 기여자들에게 기술적인 측면과 프로젝트 방향 측면 모두에서 유용한 지침을 제공할 것으로 기대됩니다.

논쟁의 여지가 있는 사안에 대해서는 기여자 커뮤니티가 협력하여 가능한 해결책을 개선하고, 필요한 경우 반복적으로 수정하며, 정보와 견해를 건설적이고 개방적으로 공유하여 합의를 도출합니다. 일반적인 커뮤니티 논의가 합리적인 시간 내에 사안에 대한 합의를 도출하지 못하는 경우 Steering Council은 결정을 내릴 수 있습니다.

투표

기술적 결정에 투표가 이루어지는 경우는 거의 없습니다.

그 밖의 프로젝트 사안에 대해서는 Steering Council이 거버넌스 PR 또는 이메일 제안을 통해 결정을 위한 투표를 요청할 수 있습니다. 가결되려면 Steering Council의 최소 80%가 투표해야 하며, 투표의 최소 2/3가 찬성이어야 합니다.

BDFL은 단독으로 변경 사항을 수락하거나 거부하거나 Steering Council의 결정을 번복할 수 있지만, 이는 매우 드문 일이 될 것입니다. Benevolent인 BDFL은 실제로 그 권한을 커뮤니티 논의 채널과 Steering Council의 합의에 맡기기로 선택합니다.

릴리스 계획

Project Jupyter에는 단일 프로젝트가 아니라 여러 프로젝트가 있으므로, 릴리스 계획은 주로 각 프로젝트의 핵심 기여자들이 주도합니다.

시간에 따른 프로세스의 변경

이 프로세스는 시간이 지나도 일관되게 유지되었으며, 이러한 접근 방식은 지금까지 잘 기능해 왔습니다. 앞으로 프로젝트의 리더십은 BDFL과 Steering Council로 구성됩니다. 이 거버넌스 모델은 방향을 변경한 것이 아니라, 프로젝트가 수행해 오던 일을 공식화한 것입니다(2015년 이전, 즉 Steering Council이 주요 거버넌스 문서를 채택하기 전).

Django

거버넌스 구조는 Organization of the Django Project에 문서화되어 있습니다.

주요 인물과 그 기능

프로젝트는 세 가지 종류의 기여자를 인정합니다. 핵심 팀의 구성원, 기술 위원회, 그리고 Fellows입니다. 일반 핵심 커미터는 더 이상 자신의 “커밋 비트”를 행사하지 않고, 대신 풀 리퀘스트를 검토하고 수락하는 방식에 의존합니다. 기술 위원회는 기술적 선택을 주도합니다. Fellows는 새 티켓을 분류하고, 커미터와 커뮤니티가 제출한 패치를 검토하고 병합하는 고용 계약자이며, 여기에는 사소하지 않은 패치도 포함됩니다.

핵심 팀 구성원은 핵심 팀 내부의 지명과 투표를 통해 추가되며, 기술 위원회에는 거부권이 있습니다(현재까지 행사된 적은 없습니다). 기술 위원회는 핵심 팀 구성원에 의해, 그리고 핵심 팀 구성원 중에서 18개월마다(각 주요 Django 릴리스마다) 선출됩니다. 핵심 팀 내 하위 팀은 관심 분야에 따라 자율적으로 구성됩니다.

일반적인 의사 결정 프로세스

대부분의 일상적인 결정은 Fellows가 내리며, 때로는 활동 중인 다른 핵심 팀 구성원들이 내립니다.

핵심 팀이 신규 구성원에 대해 투표하며, 투표된 표의 5분의 4 찬성이 필요하고 정족수 요건은 없습니다. 기술 위원회에는 거부권이 있습니다. 이 권한은 한 번도 행사되지 않았습니다.

논란이 있는 의사 결정 프로세스

기술 위원회는 때때로 Django 개선 제안(DEP)을 승인하지만, 그런 경우는 드뭅니다. DEP 프로세스는 대략 PEP를 본떠 만들어졌으며 DEP 1에 문서화되어 있습니다. DEP는 주로 주요 새 기능을 설계하는 데 사용되지만, 일반 지침과 프로세스에 관한 정보를 제공하는 데에도 사용됩니다.

DEP에 대한 아이디어는 먼저 django-developers 메일링 리스트에서 공개적으로 검토받아야 합니다. 대략적인 검증이 끝나면 작성자는 세 가지 역할로 구성된 팀을 만듭니다.

DEP를 작성하고 토론을 이끄는 authors는 다음과 같습니다;
DEP의 구현을 준비하는 implementers는 다음과 같습니다;
DEP의 주요 검토자가 될 핵심 개발자인 shepherd입니다.

DEP 초안이 제출되고, 번호가 부여되며, 논의됩니다. 저자들은 적절하다고 판단하는 방식으로 피드백을 수집하고 논의를 이끕니다. 끝없이 열린 논의가 이어지는 것을 피하기 위해 권장되는 장소는 별도의 메일링 리스트, Wiki 페이지, DEP의 pull request를 기반으로 작업하는 방식입니다.

피드백 단계가 끝나면 shepherd가 기술 위원회에 검토와 판정을 요청합니다. 위원회는 팀으로서 DEP에 대해 판정하거나, 한 명의 위원을 지정하여 검토하고 결정하게 할 수 있습니다.

합의에 도달할 수 없는 경우에는 기술 위원회가 최종 결정권을 갖습니다. 이는 한 번도 행사되지 않았습니다.

DEP와 PEP의 차이점

가장 큰 차이점은 전체 작업 흐름이 이메일이 아니라 pull request를 기반으로 한다는 점입니다. DEP는 기술 위원회가 판정합니다. 제출 전에 그리고 프로세스 전반에 걸쳐 핵심 역할을 식별해야 합니다. shepherd 역할은 Technical Board에 관여하지 않고 DEP를 완료까지 이끌기 위해 존재합니다.

이러한 프로세스 변경으로 BDFL이 없는 거버넌스 모델에서도 더 분산되고 실행 가능하게 되었습니다.

새 릴리스 계획

릴리스는 고정된 시간 기반 일정에 따라 진행되며, 18개월마다 메이저 버전이 출시됩니다. 필요한 작업이 완료되도록 유급 Fellow들이 지원하므로, 릴리스가 제때 이루어지는 것이 일상적입니다.

시간에 따른 프로세스 변경

Django에는 원래 두 명의 BDFL이 있었습니다. Jacob Kaplan-Moss와 Adrian Holovaty입니다. 이들은 프로젝트 역사상 9년이 지난 시점에 은퇴했습니다(Adrian’s post, Jacob’s post). 이들이 물러난 뒤 DEP 프로세스가 정의되었습니다.

TypeScript

주 TypeScript 저장소의 CONTRIBUTING.md 문서를 제외하면 거버넌스 구조는 외부에 문서화되어 있지 않습니다.

주요 인물과 그 역할

Microsoft에는 공식적인 설계 팀과 릴리스 관리 팀이 있습니다. 팀의 초기 구성원 중 일부가 회사를 떠났기 때문에, 현재 프로젝트를 이끄는 핵심 인물은 Anders Hejlsberg입니다.

정기적인 의사 결정 과정

프로젝트가 개발되는 Microsoft는 강력한 계획 문화를 갖추고 있으므로 개발 로드맵이 훨씬 앞서 발표되고, Microsoft에서 진행된 설계 논의의 기록이 신속하게 공개되며, 회의가 Skype를 사용해 방송되기도 합니다.

GitHub의 풀 리퀘스트를 통한 외부 기여가 권장됩니다. 새로운 사용 사례나 기능에 대한 제안은 GitHub의 이슈를 통해 제시됩니다. 이는 PEP와 유사한 임시 프로세스처럼 기능합니다. 소셜 미디어(Twitter)에서도 일부 논의가 이루어집니다.

논란이 있는 의사 결정 과정

Hejlsberg는 언어 설계 측면에서 프로젝트의 중심인물로서 커뮤니티의 요구를 하나의 일관된 전체로 종합합니다. 언어 설계에 외부에서 기여할 수 있는 공식적인 절차는 없습니다.

TypeScript 팀은 커뮤니티의 제안을 선별하고 통합합니다. 이 체계의 주요 장점은 강력하고 일관된 설계와 신뢰할 수 있는 일정 관리 및 실행이 가능하다는 점입니다. 의도와 계획은 투명하지만, 이 모델의 단점은 커뮤니티의 참여가 풀 리퀘스트와 제안으로 제한된다는 점입니다.

새 릴리스 계획

Microsoft는 릴리스 일정을 결정하고 날짜와 기능을 훨씬 앞서 전달합니다. 나이틀리 빌드는 대체로 안정적이며(이 릴리스 형태를 사용하는 사용자가 상당수입니다).

버전이 부여된 릴리스는 1~3개월마다 이루어지고, GitHub에서 로드맵을 확인할 수 있습니다.

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

TypeScript는 Microsoft가 소스 제공 방식이 아닌 완전한 공개 방식으로 개발한 최초의 주목할 만한 프로젝트일 가능성이 큽니다.

Microsoft의 TypeScript 오픈 소스화는 프로젝트 시작 때부터 계획된 기능이었습니다. 최초의 공개 릴리스가 이루어지기 전에는 원래 팀과 초기 사내 사용자들이 파악한 요구에 따라 언어가 전적으로 개발되었습니다. 최초의 오픈 소스화는 현재는 폐쇄된 Microsoft CodePlex 플랫폼을 통해 이루어졌습니다. 외부 기여를 수용하는 명확하게 정의된 절차는 없었습니다. 프로젝트가 이전된 후 커뮤니티 참여가 크게 증가했습니다.

Astropy

주요 인물과 그 역할

Astropy 프로젝트 팀의 책임은 여러 다양한 역할 [1]에 분산되어 있지만, 한 사람이 여러 역할을 맡는 경우가 많습니다.

Astropy 프로젝트를 총괄하는 주요 기구는 Astropy Coordination Committee (CoCo)입니다. 주요 역할은 재정 문제를 처리하고, Astropy 프로젝트에 참여하려는 새 패키지를 승인하며, Astropy Proposals for Enhancement (APEs) [2]을 승인하거나 거부하고, 일반적으로 “지도부”와 관련되거나 시급한 모든 사안을 처리하는 것입니다. 이 글을 작성하는 현재, 위원회에는 네 명의 위원이 있으며 위원회의 요구 사항이 변함에 따라 인원이 늘어나거나 줄어들 수 있습니다.

정기 의사 결정 절차

코드 수준의 결정

Astropy 프로젝트에는 core Astropy package와 기타 affiliated packages가 포함됩니다. 단순화를 위해 자체 규칙을 가질 수 있는 affiliated packages에 대해서는 논의하지 않습니다. 따라서 아래의 모든 내용은 핵심 Astropy 패키지를 다룹니다.

core Astropy package는 sub-packages로 구성됩니다. 각 sub-package에는 공식 maintainer와 한 명 이상의 deputies가 있으며, 이들은 코드가 검토되도록 하고 일반적으로 해당 서브패키지의 아키텍처를 설계할 책임이 있습니다. 따라서 코드 수준의 결정은 GitHub 이슈 또는 풀 리퀘스트(PR)에서 이루어지며, 일반적으로 합의를 바탕으로 해당 sub-package의 maintainer와 deputies가 조정합니다.

구체적인 의견 불일치가 있을 경우, 논의에 참여한 사람들(예: PR 참여자)의 다수결로 승자를 결정하며, 동률을 해소하거나 의견 불일치를 중재할 때는 CoCo가 요청됩니다.

코드 외 결정

코드 외 결정(스프린트 일정, 버그 수정 릴리스 시기 등)은 일반적으로 astropy-dev mailing list [3]에서 메시지별 투표 형식으로 공지하거나, 논란의 여지가 거의 없는 항목에 대해서는 “이의가 없다면”이라는 방식의 메시지로 공지합니다. 일반적으로 astropy-dev에서는 다른 구성원들이 의견을 제시하거나 투표할 수 있는 구체적인 제안을 기대합니다.

투표

투표는 일반적으로 GitHub 또는 astropy-dev mailing list에서 +1/-1 형식을 사용하는 방식으로 진행됩니다. 해당 장소에서는 프로젝트에서의 공식 역할이 있든 없든, 관심 있는 사람이라면 누구나 투표할 수 있습니다. 또한 CoCo가 다수의 결정을 무효화할 수 있는 거부권 제도도 없습니다.

논란이 있는 결정 절차

더 간단한 논쟁적 결정은 일반적으로 astropy-dev 메일링 리스트 [3]에서 논의되며, 합리적인 시간이 지난 후에는 명확한 합의/타협이 이루어지거나(대부분의 경우 이렇게 됩니다), 정체를 피하기 위해 CoCo가 결정을 내립니다.

더 복잡한 결정은 PEP 절차를 본뜬 APE 절차를 따릅니다. 이 경우 누구에게나 공개된 논의 기간이 끝난 후 CoCo가 최종 결정을 내립니다. 일반적으로 CoCo는 합의 또는 다수의 의사를 따릅니다.

윤리적 문제

프로젝트에는 행동 강령 위반과 같은 민감한 사안에 대해 조정 위원회와 독립적인 대체 연락 창구를 마련하는 Ombudsperson이 있습니다. 실제로는 CoCo, 커뮤니티 참여 코디네이터 및 Ombudsperson이 비공개로 협력하여 위반자와 소통하고 상황을 해결하려고 합니다.

새 릴리스 계획

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

시간에 따른 절차의 변화

CoCo와 “Open Development” 정신은 Python에 관심이 있는 천문학자들과 협력 소프트웨어 엔지니어들이 여러 차례 투표를 거친 후 프로젝트가 시작될 때 생겨났습니다. 그 최초 논의의 핵심 결과는 Vision for Astropy 문서 [4]에 반영되었습니다.

공식적인 역할과 위에 언급된 나머지 대부분은 커뮤니티가 더 커지면서 진화적으로 형성된 단계이며, 각각 APE 프로세스나 astropy-dev [3]에서 제안이 논의와 표결을 위해 상정되는 일반적인 절차를 따랐습니다. 일반적으로 이러한 것들은 모두 기존에 존재하던 관행이 실제 환경에서 먼저 검증된 후 이를 일종의 비준하는 형태로 발전했습니다.

자기 평가

시간이 있는 사람이라면 누구나 참여하여 무언가를 제안하거나(보통 PR을 통해) 자신이 선호하는 안에 투표할 수 있다는 사실은 “우리 모두가 함께하고 있다”는 인식을 형성하며, 더욱 조율된 노력을 이끌어냅니다.

또한 CoCo가 주로 동률을 깨는 기구로 기능하기 때문에 자신의 의지를 강요하는 독재자가 있다는 느낌이 없으며, 완전한 민주적 거버넌스 모델을 꺼리는 외부 조직에도 명확한 연락 창구를 제공합니다.

참고 자료

보너스: Microsoft

위에서 설명한 “관련 프로젝트”의 선정 과정과는 별개로, 자신의 의사 결정에 대해 재정적으로 책임을 지는 기업들이 어떻게 의사 결정을 내리는지 살펴보는 것은 가치가 있습니다. 이는 Python에 바로 사용할 수 있는 모델을 제시하려는 것이 아니라, 최종 설계나 선정에 영향을 줄 수 있는 추가적인 통찰을 제공하려는 것입니다.

이 절은 공식 문서에서 가져온 것이 아니라, 현재 Microsoft 직원인 Steve Dower가 엔지니어링 부서의 개별 프로젝트에 가장 적용하기 적합한 프로세스를 반영하도록 정리한 것입니다. 특정 개인을 식별하는 대신 역할 명칭을 사용하고 정의했으며, 모든 이름은 예시이므로 역사의 어느 특정 시점에서든 회사에 대한 정확한 설명으로 받아들여서는 안 됩니다.

이 내용 역시 매우 단순화되고 이상화되어 있습니다. 이 설명과 같지 않은 건강하지 못한 팀도 많이 있으며, 그러한 팀은 일반적으로 높은 이직률을 보입니다(사람들이 다른 팀보다 더 자주 팀을 떠납니다). 구성원을 계속 유지하는 팀은 대체로 여기에서 설명한 모델에 더 가깝지만, 궁극적으로 인간과 관련된 모든 일은 불완전하며 Microsoft도 예외가 아닙니다.

핵심 인력과 그 기능

Microsoft에는 궁극적으로 CEO에게 보고하는 계층 구조가 있습니다. CEO 아래에는 여러 조직이 있으며, 그중 일부는 영업, 마케팅 또는 기타 기능과 달리 엔지니어링 프로젝트에 중점을 둡니다. 이러한 엔지니어링 조직은 대략 주요 제품군으로 나뉩니다 - 예를 들어 “Windows 그룹”, “Xbox 그룹”, “서버 및 도구 그룹”이 존재해 왔습니다. 이러한 조직은 일반적으로 CEO에게 보고하는 Executive Vice Presidents (EVPs)가 이끕니다.

각 EVP 아래에는 여러 Corporate Vice Presidents (CVPs)가 있으며, 각각 하나 이상의 제품을 담당합니다. 이 계층은 이 PEP의 목적에 비추어 계층 구조가 중요해지는 지점입니다 - CEO와 EVPs는 대부분의 의사 결정 과정에 거의 관여하지 않지만, CVPs가 의사 결정을 내리는 방향을 설정합니다.

CVP 산하의 각 제품에는 프로그램 관리자 (PM) 및 엔지니어링 관리자로 구성된 팀이 있습니다. 엔지니어링 관리자에게는 의사 결정에 대체로 관여하지 않지만, 경우에 따라 전문가로 활용될 수 있는 엔지니어 팀이 있습니다. 이 절의 나머지 부분에서 엔지니어링은 기술에 초점을 두고 기여하는 엔지니어링 팀의 모든 사람을 의미하며, PM은 고객에 초점을 두고 기여하는 프로그램 관리 팀의 모든 사람을 의미합니다. 의사 결정이 이루어진 후에는 엔지니어링이 구현 및 테스트 작업을 수행하고, PM이 사용자에게 해당 문제가 해결되었는지 확인합니다.

(이는 실제로 매우 크게 단순화한 것으로, 일부 사람들은 이러한 특성화에 불쾌감을 느낄 정도입니다. 실제로 PM 또는 엔지니어링에 속한 대부분의 사람은 두 역할 사이의 경계를 넘나드는 업무를 수행하므로, 이 용어는 개인을 식별하거나 제한하는 명칭이 아니라 그 순간 누군가가 수행하는 업무를 설명하는 용어로 다루어야 합니다.)

일반적으로 팀은 기능을 나타내며, CVP는 제품을 나타냅니다. 예를 들어 Visual Studio Code에는 해당 제품과 전체 방향에 관한 의사 결정에 궁극적인 책임을 지는 CVP가 있습니다(EVP가 설정한 맥락 안에서). 그러나 많은 팀이 Visual Studio Code에 기능을 기여합니다.

명확히 말하면 CEO, EVP 및 CVP는 소스 코드를 직접 수정하지 않습니다. 이들의 전체 역할은 바로 아래에 있는 사람들에게 방향을 제시하고 논란이 되는 의사 결정을 판정하는 것입니다.

일반적인 의사 결정 프로세스입니다.

외부 사용자에게 보이지 않는 제품 코드 변경은 오로지 엔지니어링이 수행합니다. 개별 엔지니어에게는 지정된 엔지니어링 관리자가 작업을 할당하거나, 엔지니어가 직접 작업을 할당할 수 있습니다. 점점 더 높은 직급으로의 승진은 일반적으로 개인의 의사 결정 능력에 대한 신뢰를 반영하며, 더 높은 직급의 엔지니어일수록 팀의 다른 구성원으로부터 확인을 덜 받고 의사 결정을 내릴 수 있다고 신뢰받습니다. 대부분의 버그는 이 프로세스에서 처리됩니다(즉, 의도된 사용자 경험을 변경하지 않고 사용자에게 보이는 문제를 수정하는 것은 엔지니어링의 의사 결정입니다).

특정 기능의 사용자에게 영향을 미치는 의사 결정은 해당 기능의 PM 팀이 내립니다. PM 팀은 이용 가능한 모든 데이터 소스를 사용하여 문제를 식별하고, 대안을 실험하며, 최종적으로 설계 문서를 작성합니다. PM과 엔지니어링의 고위 구성원은 세부 사항을 명확히 하기 위해 설계를 검토하며, 최종적으로 기능 팀이 동의하는 산출물이 만들어집니다. 엔지니어링은 이 산출물을 사용하여 작업을 구현하고, PM은 나중에 이 산출물을 사용하여 원래의 문제가 해결되었는지 확인합니다.

기능을 담당하는 엔지니어링 및 PM 팀의 고위 구성원은 CVP가 설정한 방향의 취지에 따라 의사 결정을 내려야 합니다. 팀은 CVP와 정기적으로 회의하여 최근의 의사 결정을 논의하고 일관성을 확보합니다. CVP의 기대에 명백히 부합하지 않는 의사 결정은 논란이 되는 의사 결정 프로세스로 상향됩니다.

논란이 되는 의사 결정 프로세스입니다.

의사 결정에 팀 간 조정이 필요하거나 이전의 CVP 지침에 명백히 부합하지 않는 경우, 팀은 의사 결정을 상향합니다. 여기에는 방향을 변경하거나, 새롭거나 다른 사용자 그룹에 도달하려고 시도하거나, 중요한 기능을 폐기하고 제거하거나(짧은 기간 내에 수행하는 경우도 포함), 신속한 릴리스가 필요한 변경을 수행하는 의사 결정이 포함되는 경우가 많습니다.

일반적으로 CVP는 기능 팀 업무의 모든 측면을 상세히 알고 있지는 않습니다. 따라서 기능 팀은 CVP가 추가 지식 없이 결정할 수 있도록 권고안과 충분한 맥락을 모두 제공해야 합니다. 대부분의 경우 첫 번째 시도에서는 CVP가 일련의 질문을 제기하며, 팀은 이를 조사하고 답변한 후 나중에 다시 의사 결정을 시도합니다.

CVP가 묻는 일반적인 질문은 다음과 같습니다.

이 의사 결정의 영향을 받는 사용자는 몇 명입니까?
현재 사용자에 대한 영향을 최소화하기 위한 계획은 무엇입니까?
잠재적 사용자에게 이 변경 사항을 어떻게 “판매”하거나 설명할 것입니까?

CVP는 전체 분야를 폭넓게 이해하고 있어야 하므로, 다음과 같은 몇 가지 질문을 스스로 평가할 수 있어야 합니다.

Microsoft 내 다른 프로젝트에서는 어떤 유사한 결정을 내렸습니까?
이 결정에 영향을 미칠 수 있는 계획을 가진 다른 프로젝트는 무엇입니까?
Microsoft 외부의 프로젝트에서는 어떤 유사한 결정을 내렸습니까?
사용자에게 이것이 필요합니까?
해당 EVP가 정한 방향과 일치합니까?

CVP가 내리는 결정은 일반적으로 자의적이며 최종적이지만, 대개 그 근거를 제시합니다.

새 릴리스 계획 수립

릴리스에는 여러 기능 팀의 조정이 필요하므로, 모든 팀의 의견을 포함하려고 하는 경우는 드뭅니다. 예정된 행사나 컨퍼런스 또는 언론의 관심을 활용할 기회와 같은 더 광범위한 생태계의 필요에 따라 일정을 결정합니다.

팀에는 릴리스 날짜와 릴리스의 주제를 알리고, 위의 의사 결정 과정에 따라 그에 맞춘 자체 계획을 수립하도록 합니다. 릴리스 날짜를 변경하는 것은 논란의 여지가 있는 결정으로 간주합니다.

감사의 말

핵심 팀이 프로젝트를 운영하는 방식에 대해 상세히 설명해 주신 Rust 팀의 Alex Crichton에게 감사드립니다.

Jeremy Stanley, Chris Dent, Julia Kreger, Sean McGinnis, Emmet Hikory, 그리고 Thierry Carrez가 OpenStack 섹션에 기여했습니다.

Project Jupyter 운영 위원회가 Project Jupyter를 위한 주요 거버넌스 문서를 작성했으며, Carol Willing이 Jupyter 섹션을 위해 해당 문서의 핵심 사항을 요약했습니다.

Django 팀의 Carl Meyer가 해당 프로젝트의 거버넌스 설정 방식을 설명해 주신 데 감사드립니다.

TypeScript 및 Swift 섹션은 Joe Pamer와 Vlad Matveev와의 대화를 바탕으로 작성되었습니다. 감사합니다!

Astropy 프로젝트에 관한 답변은 Erik Tollerud가 상당히 상세하게 기꺼이 제공했으며, 프로젝트의 다른 구성원들이 검토했습니다.

부록 1: 질문 템플릿

다음 질문 세트는 조사 대상 프로젝트의 평가와 상호 작용을 안내하기 위한 템플릿으로 사용되었습니다.

거버넌스 모델이 어떻게 설정되어 있는지 설명하는 공개 문서가 있습니까?
실제로 그 과정은 어떻게 진행됩니까?
- 핵심 인물은 누구입니까?
- 기여자에게는 어떤 “특별 지위”가 부여될 수 있습니까?
- 이들은 어떻게 선출되며, 지위는 어떻게 부여됩니까?
- 일반적인 결정은 어떻게 내립니까?
- 논란의 여지가 있는 결정은 어떻게 내립니까?
- 투표 메커니즘이 있습니까? 어떻게 작동하며, 실제로 투표는 얼마나 자주 이루어집니까?
- 거부권 메커니즘이 있습니까? 실제로 얼마나 자주 사용되었습니까?
이 프로세스를 어떻게 평가하십니까?
- 어떤 부분이 잘 작동합니까?
- 어떤 부분이 더 잘 작동할 수 있습니까?
- 잘 작동하지 않을 때는 어떤 모습으로 나타납니까?
- 전적으로 본인의 결정에 달려 있다면 무엇을 변경하시겠습니까?
관련 프로젝트 작업:
- 릴리스 시점과 릴리스에 포함할 내용을 어떻게 결정하십니까?
- 커밋 권한을 부여받을 사람을 어떻게 결정하십니까?
- 어디에서 논의를 진행하십니까? (GitHub, 메일링 리스트, 대면 회의 등)
- RFC/PEP와 유사한 프로세스가 있습니까?
- 해당 논의 채널에 누가 접근할 수 있습니까?
- 이 접근 권한은 어떻게 부여하거나 회수합니까?
- 해당 논의를 누가 중재합니까?
- 참가자를 제재합니까? 제재한다면 어떻게 합니까?
프로세스의 발전
- 이 프로세스는 역사적으로 어떻게 발전했습니까?
- 앞으로 이 프로세스를 어떻게 변경할 수 있습니까?

Copyright

This document has been placed in the public domain.