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
번역·라이선스 안내
이 비공식 한국어 번역은 원문 Copyright 절의 Public Domain 조건에 따라 제공합니다. 원저자와 공식 원문은 그대로 표시합니다. 수정되지 않은 기준 원문 · 공식 최신판
초록
이 PEP는 기존의 유사한 오픈 소스 및 자유 소프트웨어 프로젝트의 거버넌스 모델을 조사하여 요약합니다. 이 요약은 귀도의 은퇴 이후 파이썬이 새로운 거버넌스 모델을 선택할 때 유용한 참고 자료가 될 것입니다.
각 커뮤니티 조사마다 별도의 PEP를 작성하는 대신, 모든 조사를 이 PEP에 모읍니다.
근거
거버넌스 위기를 겪는 오픈 소스 프로젝트는 CPython이 처음이 아닙니다. 다른 프로젝트들도 다양한 거버넌스 방식을 시도해 왔으며, 존속 기간 동안 여러 차례 시도한 경우도 있습니다. 이들의 경험에서 얻을 수 있는 유용한 교훈이 있으며, 이는 우리가 결정을 내리는 데 도움이 될 것입니다.
프로젝트 선정
세상에는 많은 오픈 소스 프로젝트가 있지만, 몇 가지 핵심 지표에서 CPython과 충분히 비슷한 프로젝트를 조사하는 것이 가장 유익할 것입니다:
- 기여자 수와 그 활동 수준(규모 문제 때문에 아주 작은 프로젝트의 거버넌스 모델은 우리 목적에 그다지 참고가 되지 않습니다);
- 대부분 또는 부분적으로 커뮤니티 주도일 것(기업 주도 프로젝트는 기업의 위계가 주요 참여자에 대해 권한을 가지므로 다른 거버넌스 방식을 택할 수 있습니다);
- 어느 정도 공식적인 의사 결정 절차가 필요한 중요한 설계 결정에 직면해 있을 것.
Rust
거버넌스 구조는 Rust RFC #1068에 문서화되어 있습니다.
실제 거버넌스 절차는 RFC로 전부 성문화되지 않은 채 시간이 지나면서 자연스럽게 발전하며, 일상적인 운영 세부 사항의 경우 특히 그렇습니다. 한 가지 예로 2018년 2월의 도메인 워킹 그룹 결성을 들 수 있습니다.
주요 인물과 그 역할
Rust 프로젝트에는 특정 영역을 책임지는 팀들이 있습니다. 언어 기능은 “lang team”이, 도구는 “dev tools”와 “Cargo”가 담당하는 식입니다. 논쟁적인 사안에는 논의를 이끄는 진행자가 있으며, 이들이 결정권자가 아닌 경우가 많습니다. 일반적으로 진행자는 제안된 변경 사항의 작성자입니다(아래 “논쟁적인 사안의 의사 결정 절차”를 참조하십시오). 진행자는 관심 있는 커뮤니티 구성원과 함께 모든 주요 결정권자가 논의에 참여하도록 합니다. 진행자는 반복적인 논의를 통해 모두가 동의할 수 있는 결론을 향해 나아갑니다.
실제로 이는 결정이 코어 팀까지 올라가는 일이 드물다는 뜻입니다.
기여자의 가장 일반적인 역할은 팀 구성원입니다. 팀 구성원이 아니면서 이슈 분류나 코드 리뷰 권한을 가진 경우는 드뭅니다. 기여자는 전체 커밋 권한을 가지며, 코드 소유권 구분은 신뢰에 기반합니다. 컴파일러 저장소에 직접 쓰는 것은 좋지 않게 여겨지며, 모든 변경 사항은 풀 리퀘스트를 거쳐 리뷰와 승인을 받은 뒤 통합 봇이 병합합니다.
새 팀 구성원은 기존 팀 구성원의 추천으로 추가됩니다.
일반적인 의사 결정 절차
주된 작업은 GitHub 이슈와 풀 리퀘스트를 통해 이루어집니다. 팀 구성원 누구든 풀 리퀘스트를 승인하면 추가 절차 없이 병합할 수 있습니다. 병합된 모든 풀 리퀘스트는 Rust의 다음 안정 버전에 포함됩니다.
멘션으로 관련자에게 알리는 것이 중요합니다. 모든 GitHub 활동에 대해 쏟아지는 이메일을 전부 지켜보는 방식은 선호되지 않습니다.
IRC와 Discord에서 누구나 참여할 수 있는 계획 회의와 분류(triage) 회의가 열립니다. 대부분의 작업이 GitHub를 통해 이루어지므로 이러한 회의는 그다지 인기가 없습니다. 공식 Rust 포럼(https://users.rust-lang.org/ 및 https://internals.rust-lang.org/)에서도 논의가 이루어집니다. 기록을 남기고 행동 강령을 시행하는 일을 맡은 전담 중재 팀이 있습니다.
논쟁적인 사안의 의사 결정 절차
규모가 크거나 논란이 있는 작업은 RFC 프로세스를 거칩니다. 이 프로세스를 통해 모든 사람이 자기 생각을 표현할 수 있으며, 결론에 이를 때까지 논의를 거듭합니다. 관련 팀 구성원이 제기한 차단 우려가 모두 해소되는 시점에 이들이 RFC를 승인하며, RFC는 “최종 의견 기간(final comment period)”에 들어갑니다. 모든 참여자 사이의 합의가 필요한 것은 아니며, 다만 제안에 반대하는 강한 합의가 없어야 합니다.
팀 구성원이 새로운 차단 우려를 제기하지 않으면 RFC는 10일 후에 병합됩니다. “병합”은 이제 기능을 구현하고 통합하는 작업을 중단 없이 진행할 수 있다는 의미입니다. RFC가 채택되기 위해 반드시 참조 구현이 있어야 하는 것은 아닙니다.
“최종 의견 기간”의 다른 가능한 결과는 다음과 같습니다:
- RFC를 연기하는 것(PEP의 Deferred 상태와 유사합니다),
- 차단 우려를 해소할 수 있다면 다시 논의로 되돌리는 것, 또는
- 차단 우려를 해결할 수 없다면 종료하는 것입니다. 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 채널이나 LTS 릴리스는 없지만, 재배포자가 개발을 더 잘 따라갈 수 있도록 이 개념을 도입할 계획입니다.
몇 년마다 이른바 “에디션”이 출시됩니다. 에디션은 갱신된 문서와 도구 일체를 갖춘 이정표 릴리스입니다. 에디션은 이전 에디션과 하위 호환되지 않을 수 있습니다. 외부 패키지는 크레이트 메타데이터에서 호환성을 깨는 변경을 선택적으로 적용합니다. Rust 컴파일러는 자신의 릴리스 이전에 존재했던 모든 에디션을 지원합니다. 지원되는 에디션이라면 어떤 에디션의 크레이트끼리도 서로 링크할 수 있습니다.
시간에 따른 절차의 변화
Rust 프로그래밍 언어는 Graydon Hoare가 시작했으며, 그는 몇 년 동안 이를 개인 프로젝트로 개발했습니다. Mozilla가 프로젝트를 후원하기 시작하면서 팀은 Graydon을 BDFL과 같은 인물로 두고 서서히 성장했습니다. 그는 2013년에 프로젝트를 떠났습니다. 그 이후로 Rust는 BDFL 없이 운영되고 있습니다. RFC 프로세스는 나중에 도입되었습니다. 초기에는 일부 설계 논의가 비공개 주간 화상 회의에서 이루어졌는데, 이 회의는 2015년 5월(Rust 1.0 릴리스 이전)에 폐지되었으며, 자연스럽게 공개 토론과 팀의 직접적인 영향력으로 대체되었습니다.
팀의 수는 시간이 지남에 따라 늘어나고 있습니다. 코어 팀이 내리는 기술적 결정의 수는 줄어들고 있으며, 대신 그러한 결정은 각 해당 팀에 위임됩니다.
이미 내려진 성급한 결정을 되돌려야 하는 대신, 더 많은 공개 토론을 장려하고 곧 이루어지려는 변경에 대응할 수 있도록 “최종 의견 기간(final comment period)”이라는 개념이 도입되었습니다.
OpenStack
OpenStack 재단 정관은 프로젝트 거버넌스의 기본 구조를 규정하며, 제4조는 오픈 소스 프로젝트의 일상적인 관리를 OpenStack 기술 위원회(TC)에 위임하고, TC 위원 정책은 기술 위원회를 어떻게 선출할지를 개괄적으로 정의합니다. TC는 팀 구조, 출마 자격을 확정하는 정확한 규칙, 여러 선거인단을 확정하는 기준을 설명하는 TC 헌장을 포함하여, 더 상세한 거버넌스 문서 일체를 게시합니다.
주요 인물과 그 역할
OpenStack 커뮤니티는 소프트웨어의 여러 구성 요소(블록 스토리지 관리, 컴퓨트 관리 등)를 만들거나 커뮤니티가 따르는 프로세스의 여러 부분(릴리스 일정 추적 등)을 관리하는 책임을 맡은, 서로 다른 여러 프로젝트 팀으로 구성됩니다. 각 팀은 해당 프로젝트의 활성 프로젝트 기여자가 선출한 프로젝트 팀 리더 (PTL)가 이끕니다.
활성 프로젝트 기여자(APC)는 특정 프로젝트 팀에 최근 기여한 사람입니다. APC 자격을 얻으려면 공식적으로 두 가지가 필요합니다. 하나는 OpenStack 재단의 개인 회원이 되는 것(회원 가입은 무료입니다)이고, 다른 하나는 지난 1년(개발 주기 두 번) 이내에 프로젝트 팀이 관리하는 저장소에 변경 사항이 병합된 것입니다.
선출된 PTL의 임기는 개발 주기 한 번(약 6개월)과 같습니다. 한 사람이 PTL을 연임할 수 있는 횟수에는 제한이 없으며, 여러 임기를 연속으로 맡는 경우가 흔합니다. 또한 특정 주기에 PTL로 자원한 후보가 한 명뿐인 팀도 드물지 않으며, 이 경우에는 선거를 치를 필요가 없습니다.
PTL은 일부 책임을 명시적으로 위임한 경우를 제외한 모든 경우에 팀을 대표합니다. 예를 들어 많은 팀은 개발 주기의 릴리스 프로세스를 관리하도록 별도의 릴리스 연락 담당자를 지정합니다. PTL은 또한 팀원 간에 합의에 이르지 못하는 경우 최종 결정권자 역할을 합니다.
APC들이 모두 팀의 PTL 선출에 투표하지만, 그 밖의 많은 경우에는 팀의 정책 결정에 코어 리뷰어 팀의 의견만 구합니다. 누구나 어떤 OpenStack 프로젝트의 어떤 패치든 리뷰할 수 있습니다. 어떤 사람이 프로젝트의 기술적 문제를 잘 파악하고 있고, 리뷰에서 유용한 피드백을 제공하며, 프로젝트가 나아가는 방향을 이해하고 있음을 보여 주면, 코어 리뷰 팀의 구성원이 되도록 초대받을 수 있습니다. 다른 많은 커뮤니티와 달리, 이 지위는 리뷰를 받지 않고 코드를 제출할 권리를 부여하지 않습니다. 오히려 이 지위는 다른 기여자가 작성한 코드를 리뷰하는 데 커밋하고, 팀의 의사 결정 논의에 참여할 것을 요구합니다. 누군가에게 코어 리뷰 팀의 구성원이 되어 달라고 요청하는 것은 강한 신뢰의 표시입니다.
기술 위원회(TC)는 OpenStack 전체의 개발을 관리할 책임이 있습니다. 기술 위원회의 위원 13명은 모든 프로젝트 팀의 APC들이 직접 선출합니다. 각 위원의 임기는 두 개발 주기(약 1년)이며, 연속성을 보장하기 위해 선거를 나누어 실시하므로 어느 시점에든 위원의 약 절반만 임기가 만료됩니다. TC는 새 프로젝트 팀을 추가하는 기준, Python 2에 대한 폐지 정책, 테스트 요구 사항 등 전반적인 정책을 수립합니다.
일반적인 의사 결정 절차
PTL 또는 TC 위원 선거는 모두 https://civs.cs.cornell.edu 를 사용하여 콩도르세 방식으로 진행됩니다. 이 방식은 단순한 인기보다 합의를 이끌어 낼 수 있는 후보를 중시하기 때문에 선택되었습니다.
OpenStack 기여자 커뮤니티는 논의를 위해 세 가지 주요 도구에 의존합니다. openstack-dev 메일링 리스트, https://review.openstack.org 에 있는 gerrit 코드 리뷰 인스턴스, 그리고 Freenode에 있는 OpenStack 전용 IRC 채널 모음입니다. 기여자가 주로 중국에 있는 팀이 몇몇 있는데, 이 팀들은 IRC에 접속하는 데 어려움을 겪습니다. 그래서 이 팀들은 대신 WeChat과 같은 대체 플랫폼을 사용하는 경향이 있습니다.
특정 결정을 논의하는 데 사용하는 도구는 그 결정의 무게와 영향에 따라 달라집니다. 더 다양한 시간대와 방화벽 환경에 걸친 비동기 논의를 지원하기 위해, 모든 사람에게 메일링 리스트나 gerrit을 사용하도록 권장하며, 특히 최종 결정을 커뮤니티의 나머지 구성원에게 알릴 때 그러합니다.
한 팀에 국한된 정책 결정은 보통 프로젝트의 코어 리뷰 팀이 내리며, 정책과 의사 결정 절차는 팀마다 다를 수 있습니다. 어떤 그룹은 팀 정책을 문서 저장소에 기록하고, 코드 리뷰 도구(gerrit)를 사용하여 그 정책에 투표합니다. 어떤 팀은 즉석에서 또는 정기적으로 예정된 회의 중에 IRC에서 정책을 논의하고 그곳에서 결정을 내립니다. 어떤 팀은 그러한 논의에 메일링 리스트를 사용합니다. 팀의 PTL은 논의가 잘 관리되고 그 결과가 전달되도록 할 책임이 있습니다(직접 하거나 그 작업이 다른 사람에게 위임되도록 합니다).
모든 팀 정책 결정은 기술 위원회가 정한 전반적인 정책과 양립해야 합니다. TC는 전체 기여자 커뮤니티에 적용되는 더 폭넓은 거버넌스 결정을 내리는 경향이 있으므로, 그러한 결정을 논의하고 투표하는 절차는 통과에 필요한 득표수와 논의에 필요한 최소 기간을 명시하는 것을 포함하여 더 공식적으로 기술되어 있습니다. 예를 들어, 대부분의 안건은 통과하려면 위원의 1/3(5명)의 찬성이 필요하며, 통과에 충분한 표를 얻은 후에도 최소 3일 동안 열어 두어 반대 의견을 표명할 시간을 보장해야 합니다. 자세한 내용은 기술 위원회 헌장과 내부 규칙을 참조하십시오.
중요한 설계 결정은 보통 요구 사항, 대안, 구현 세부 사항을 다루는, PEP와 다소 비슷한 명세 문서를 리뷰하는 방식으로 논의됩니다. 모든 기여자로부터 피드백을 구한 다음, 최종적으로 프로젝트의 코어 리뷰 팀 구성원이 명세를 승인하거나 거부합니다. 어떤 팀은 설계를 승인하는 데 리뷰어 2명만 요구하지만, 다른 팀은 설계를 승인하기 전에 더 강한 합의의 표시를 요구합니다. 각 팀은 기여자들이 중요한 새 기능의 설계를 일찍 마무리하고 주기 후반의 변경으로 인한 위험을 피하도록 장려하기 위해 각 개발 주기 안에서 명세를 승인하는 기한을 정합니다.
비교적 작은 기술적 결정은 보통 변경 사항을 구현하는 데 필요한 패치를 리뷰하면서 이루어집니다. 누구나 어떤 패치든 리뷰하고 기술적 피드백을 줄 수 있지만, 대부분의 변경 사항을 승인하려면 결국 해당 팀의 코어 리뷰어 두 명이 필요합니다(오타 같은 사소한 변경이나 CI 게이팅 시스템이 막힌 것을 푸는 수정에는 예외를 두는 경우가 많습니다).
논쟁적인 사안의 의사 결정 절차
논쟁적이거나 단지 복잡하기만 한 결정은 명세 리뷰를 벗어나 메일링 리스트 토론으로 확대되는 경우가 많습니다. 이러한 결정은 정기적으로 열리는 대면 커뮤니티 모임에서의 토론으로 이어지는 경우도 많습니다. 커뮤니티 구성원 중 상당수가 이러한 행사에 참석할 수 없으므로, 토론 내용을 요약하고 최종 결정은 가능한 한 온라인 도구를 사용하여 내립니다.
PTL은 단일 팀에 영향을 주는 결정에 대해 합의가 이루어졌는지 판단하고, 합의가 이루어지지 않았지만 반드시 결정을 내려야 하는 드문 경우에는 최종 판단을 내릴 책임이 있습니다. TC는 팀 사이의 문제를 다른 방법으로 해결할 수 없는 경우를 위해 이와 비슷한 최후의 의사 결정 그룹 역할을 합니다. 직접 관련된 기여자들은 대체로 결정을 다른 사람에게 넘기기보다 합의에 이르는 편을 선호하므로, 이렇게 의사 결정을 상위로 넘겨야 하는 일은 결과적으로 거의 없습니다.
새 릴리스 계획
OpenStack은 약 6개월마다 메이저 릴리스를 냅니다. 이는 날짜를 기준으로 조율되는 릴리스로, 그 시점까지 모든 소속 프로젝트에서 완료된 작업을 포함합니다. 일부 프로젝트 팀은 6개월보다 더 자주 릴리스합니다(다른 팀이 사용하는 라이브러리를 만드는 팀이 특히 그렇습니다). 이러한 소규모 릴리스는 릴리스할 만한 내용(새 기능이나 버그 수정)이 있을 때 만들어지는 경향이 있습니다.
마감일과 최종 릴리스 날짜를 포함한 각 개발 주기의 일정은 릴리스 관리 팀이 재단 직원과 협력하여 제안하며(릴리스는 대체로 대면 행사 일정에 맞춰집니다), 그런 다음 최종 날짜가 확정되기 전에 커뮤니티가 피드백을 줄 기회를 가집니다.
각 개발 주기의 우선순위에 대한 결정은 팀 수준과 TC 수준에서 이루어집니다. 코어 리뷰 팀은 버그 수정이나 새 기능 구현 같은 내부 작업의 우선순위를 정합니다. TC는 커뮤니티 목표를 선정하며, 이는 보통 모든 팀에 어느 정도의 작업을 요구합니다. 각 주기를 시작할 때 이러한 우선순위에 합의해 두면 팀들이 작업을 조율하는 데 도움이 되며, 구현에는 여러 팀 구성원의 리뷰가 필요하므로 이는 특히 중요합니다.
시간에 따른 절차의 변화
지난 8년 동안 OpenStack 프로젝트 팀의 수는 2개에서 63개로 늘어났습니다. 기술 위원회(Technical Committee)의 구성도 이러한 성장에 맞춰 바뀌었습니다. 원래 TC는 PTL들로 구성되었지만, 구성원이 늘어나면서 그룹이 효과적으로 기능하기가 어려워졌습니다.
커뮤니티는 한때 프로젝트 팀이 아니라 “프로그램 영역”을 중심으로 조직되기도 했습니다. 프로그램 영역은 텔레메트리 수집이나 블록 스토리지 관리 같은 기능 집합을 담당했습니다. 이 조직 방식은 여러 팀이 같은 기능 집합을 서로 다른 해법으로 작업하려 할 때 제대로 작동하지 않았습니다. 팀이 내놓는 코드를 중심으로 팀을 조직하면, 서로 다른 팀이 같은 요구 사항을 서로 다르게 해석할 수 있습니다. 예를 들어, 현재는 여러 팀이 각기 다른 배포 도구를 작업하고 있습니다.
Jupyter
거버넌스 구조는 Jupyter Governance repo 안의 Main Governance Document에 문서화되어 있습니다.
실질적인 거버넌스 절차는 프로젝트의 요구가 변화함에 따라 시간이 지나면서 자연스럽게 발전합니다. 거버넌스 문서에 대한 공식적인 변경은 풀 리퀘스트를 통해 제출되며, 의견을 받는 공개 기간이 주어집니다. 공개 기간이 끝나면 운영 위원회(Steering Council)는 PR 변경 사항을 비준하기 위한 투표를 요청할 수 있습니다. 승인되려면 운영 위원회의 최소 80%가 투표에 참여해야 하며, 투표의 2/3 이상이 찬성이어야 합니다. BDFL은 단독으로 변경 사항을 수락 또는 거부하거나 운영 위원회의 결정을 뒤집을 수 있습니다. 다만 이는 극히 드문 일일 것입니다.
주요 인물과 그 역할
Jupyter 거버넌스의 핵심 인물은 BDFL인 Fernando Perez와 운영 위원회입니다. 기여자에게는 핵심 기여자(core contributor)라는 특별한 지위가 부여될 수 있습니다. 일부는 기관 기여자(Institutional Contributor)일 수도 있는데, 이들은 기관 파트너(Institutional Partner)에서 맡은 공식 업무의 일환으로 프로젝트에 기여하는 개인입니다.
프로젝트 창립자인 Fernando Perez가 현재이자 최초의 BDFL입니다. BDFL은 원하는 기간 동안 직을 수행할 수 있습니다. BDFL 승계 계획은 주 거버넌스 문서에 기술되어 있습니다. 요약하면, BDFL은 다음 BDFL을 임명할 수 있습니다. 예의상 BDFL은 운영 위원회와 협의할 것으로 기대됩니다. BDFL이 후임자를 임명할 수 없는 경우에는 운영 위원회가 후임자를 추천합니다.
핵심 기여자는 자신의 전문 분야 또는 하위 프로젝트 내에서 프로젝트에 가장 이익이 되도록 행동할 수 있도록 커밋 권한과 같은 권한을 부여받은 개인입니다. 일반적으로 기존 핵심 기여자가 프로젝트 리드들의 합의를 모아 누군가에게 핵심 기여자 권한을 부여하도록 추천하며, 프로젝트 리드는 프로젝트 저장소의 README에 기재된 경험 많은 핵심 기여자들입니다.
운영 위원회 위원으로 추천 및 초대되려면, 질과 양 모두에서 상당하며 최소 1년 이상 지속된 기여를 한 프로젝트 기여자(Project Contributor)여야 합니다. 위원 후보는 기존 위원회 위원이 지명하며, 후보에게 해당 역할을 맡을 관심과 의향이 있는지 확인한 후 기존 위원회가 투표로 결정합니다.
일반적인 의사 결정 절차
Project Jupyter는 여러 GitHub 조직과 그 조직 내의 하위 프로젝트들로 구성되어 있습니다. 주요 작업은 GitHub 이슈와 풀 리퀘스트를 통해 이루어집니다. 팀 구성원 중 누구라도 풀 리퀘스트를 승인하면 추가 절차 없이 병합할 수 있습니다. 병합된 모든 풀 리퀘스트는 하위 프로젝트의 다음 안정 릴리스에 포함됩니다.
매주 프로젝트 전체가 참여하는 공개 회의가 열리며, 이 회의는 녹화되어 YouTube에 게시됩니다. Project Jupyter의 하위 프로젝트인 일부 대규모 GitHub 조직(예: JupyterLab, JupyterHub)은 매주 또는 매월 추가적인 공개 팀 회의를 열 수 있습니다. 논의는 Gitter와 Jupyter 메일링 리스트에서 이루어지며, 가장 빈번하게는 GitHub의 열린 이슈 및/또는 풀 리퀘스트에서 이루어집니다.
논쟁적인 사안의 의사 결정 절차
Project Jupyter 거버넌스의 기반은 다음과 같습니다:
- 개방성과 투명성
- 적극적인 기여
- 기관 중립성
일상적인 프로젝트 활동에서 운영 위원회 위원은 다른 모든 기여자 및 커뮤니티와 동등한 동료로서 모든 논의, 코드 리뷰 및 기타 프로젝트 활동에 참여합니다. 이러한 일상 활동에서 위원회 위원은 위원회 소속이라는 이유로 특별한 권한이나 특권을 갖지 않습니다. 그러나 위원회 위원은 기여의 질과 양, 그리고 프로젝트 소프트웨어 및 서비스에 대한 전문 지식을 갖추고 있으므로, 상대적으로 경험이 적을 수 있는 기여자에게 기술 측면과 프로젝트 방향 측면 모두에서 유용한 조언을 제공할 것으로 기대됩니다.
논란이 되는 사안의 경우, 기여자 커뮤니티는 함께 협력하여 잠재적 해결책을 다듬고, 필요에 따라 반복하며, 정보와 견해를 건설적이고 개방적으로 공유하여 합의를 이루어 갑니다. 일반적인 커뮤니티 논의로 합리적인 기간 내에 어떤 사안에 대한 합의가 이루어지지 않으면 운영 위원회가 결정을 내릴 수 있습니다.
투표
기술적 결정을 위해 투표를 하는 경우는 거의 없습니다.
그 밖의 프로젝트 사안에 대해서는 운영 위원회가 거버넌스 PR이나 이메일 제안을 통해 결정을 위한 투표를 요청할 수 있습니다. 채택되려면 운영 위원회의 최소 80%가 투표해야 하며, 투표의 최소 2/3가 찬성이어야 합니다.
BDFL은 단독으로 변경 사항을 채택하거나 거부할 수 있고 운영 위원회의 결정을 뒤집을 수도 있습니다. 다만 이는 극히 드문 일일 것입니다. 자비로운(Benevolent) 존재로서 BDFL은 실제로는 그 권한을 커뮤니티 토론 채널과 운영 위원회의 합의에 맡기는 쪽을 택합니다.
릴리스 계획
Project Jupyter에는 단일 프로젝트가 아니라 여러 프로젝트가 있으므로, 릴리스 계획은 주로 각 프로젝트의 핵심 기여자가 주도합니다.
시간에 따른 절차의 변화
이 프로세스는 시간이 흘러도 일관되게 유지되어 왔으며, 이러한 접근 방식은 우리에게 잘 맞았습니다. 앞으로 프로젝트 리더십은 BDFL과 운영 위원회로 구성될 것입니다. 이 거버넌스 모델은 방향을 바꾼 것이 아니라, (운영 위원회가 주요 거버넌스 문서를 채택한 2015년 이전부터) 프로젝트가 해 오던 방식을 공식화한 것입니다.
Django
거버넌스 구조는 Organization of the Django Project에 문서화되어 있습니다.
주요 인물과 그 역할
이 프로젝트는 세 종류의 기여자를 인정합니다. 코어 팀 구성원, 기술 이사회(Technical Board), 그리고 펠로(Fellow)입니다. 일반 코어 커미터는 더 이상 “커밋 권한(commit bit)”을 행사하지 않으며, 대신 풀 리퀘스트가 리뷰되고 승인되는 절차에 의존합니다. 기술 이사회는 기술적 선택을 이끕니다. 펠로는 고용된 계약자로서, 새 티켓을 분류하고 커미터와 커뮤니티가 제출한 패치를 사소하지 않은 것까지 포함하여 리뷰하고 병합합니다.
코어 팀 구성원은 코어 팀 내부의 추천과 투표를 통해 추가되며, 기술 이사회가 거부권을 가집니다(지금까지 행사된 적은 없습니다). 기술 이사회는 18개월마다(Django 주요 릴리스마다) 코어 팀 구성원에 의해 코어 팀 구성원 중에서 선출됩니다. 코어 팀 내의 하위 팀은 관심사에 따라 자발적으로 구성됩니다.
일반적인 의사 결정 절차
대부분의 일상적인 결정은 펠로가 내리며, 때로는 다른 활동적인 코어 팀 구성원이 내리기도 합니다.
코어 팀은 신규 멤버를 투표로 결정하며, 투표수의 4/5 이상 찬성이 필요하고 정족수 요건은 없습니다. 기술 위원회(Technical Board)는 거부권을 가집니다. 이 권한은 한 번도 행사된 적이 없습니다
논쟁적인 사안의 의사 결정 절차
기술 위원회는 이따금 Django 개선 제안(DEP)을 승인하지만, 그런 경우는 드뭅니다. DEP 절차는 대략 PEP를 본떠 만들어졌으며 DEP 1에 문서화되어 있습니다. DEP는 주로 주요 신규 기능을 설계하는 데 사용되지만, 일반적인 지침과 절차에 관한 정보를 제공하는 데에도 사용됩니다.
DEP에 대한 아이디어는 먼저 django-developers 메일링 리스트에서 공개적으로 검토받아야 합니다. 대략적으로 검증이 끝나면, 저자는 세 가지 역할로 구성된 팀을 꾸립니다:
- DEP를 작성하고 논의를 이끄는 저자;
- DEP의 구현을 준비하는 구현자;
- 코어 개발자로서 DEP의 주 리뷰어가 될 셰퍼드.
DEP 초안이 제출되면 번호가 부여되고 논의가 진행됩니다. 저자는 피드백을 수집하고 적절하다고 판단하는 방식으로 논의를 이끕니다. 끝없이 이어지는 열린 논의를 피하기 위해 권장되는 방식으로는 별도의 메일링 리스트, 위키 페이지, DEP에 대한 풀 리퀘스트를 기반으로 작업하는 것이 있습니다.
피드백 단계가 끝나면, 셰퍼드는 기술 위원회에 검토와 결정을 요청합니다. 위원회는 팀으로서 DEP에 대해 결정을 내릴 수도 있고, 위원 한 명을 지정하여 검토하고 결정하게 할 수도 있습니다.
합의에 이를 수 없는 모든 경우에는 기술 위원회가 최종 결정권을 가집니다. 이 권한은 한 번도 행사된 적이 없습니다.
DEP와 PEP의 차이점
주요 차이점은 전체 워크플로가 이메일이 아닌 풀 리퀘스트를 기반으로 한다는 점입니다. DEP는 기술 위원회가 결정합니다. 제출 전부터 절차 전반에 걸쳐 핵심 역할이 정해져 있어야 합니다. 셰퍼드 역할은 기술 위원회를 개입시키지 않고 DEP를 완료까지 이끌기 위해 존재합니다.
이러한 절차상의 변화로 인해 절차가 더 분산되고, BDFL이 없는 거버넌스 모델에서도 원활하게 운영될 수 있습니다.
새 릴리스 계획
릴리스는 고정된 시간 기반 일정에 따라 이루어지며, 18개월마다 메이저 버전이 나옵니다. 필요한 작업이 완료되도록 보장하는 유급 펠로(Fellow)가 있기 때문에, 릴리스가 제때 이루어지는 것은 일상적인 일입니다.
시간에 따른 절차의 변화
Django에는 원래 Jacob Kaplan-Moss와 Adrian Holovaty라는 두 명의 BDFL이 있었습니다. 이들은 프로젝트 역사 9년 차에 은퇴했습니다(Adrian의 글, Jacob의 글). 이들이 물러난 뒤 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 개선 제안 (Astropy Proposals for Enhancement, APE) [2] 승인 또는 거부, 그리고 전반적으로 “리더십”과 관련되거나 시급한 모든 사안입니다. 이 글을 쓰는 시점에 위원회의 위원은 네 명이며, 위원회에 대한 요구가 변함에 따라 늘어나거나 줄어들 수 있습니다.
일반적인 의사 결정 절차
코드 수준의 결정
Astropy 프로젝트에는 핵심 Astropy 패키지와 기타 제휴 패키지가 포함됩니다. 논의를 단순하게 하기 위해, 자체 규칙을 가질 수 있는 제휴 패키지에 대한 논의는 피하겠습니다. 따라서 아래의 모든 내용은 핵심 Astropy 패키지에 관한 것입니다.
핵심 Astropy 패키지는 하위 패키지로 구성됩니다. 각 하위 패키지에는 공식 유지 관리자와 한 명 이상의 대리인이 있으며, 이들은 코드가 리뷰되도록 보장하고 하위 패키지의 전반적인 설계를 맡을 책임이 있습니다. 따라서 코드 수준의 결정은 GitHub 이슈나 풀 리퀘스트(PR)에서 이루어지며, 보통 합의를 바탕으로 해당 하위 패키지의 유지 관리자와 대리인이 조율합니다.
구체적인 의견 불일치가 있을 때에는 논의(예: PR)에 참여한 사람들의 다수결로 결론을 정하며, 동수를 가리거나 의견 불일치를 중재해야 할 때에는 CoCo에 요청합니다.
코드 외적인 결정
코드 외적인 결정(스프린트 일정, 버그 수정 릴리스 시기 등)은 대개 astropy-dev 메일링 리스트 [3]에 메시지로 투표하는 형식으로 공지되며, 논란의 여지가 거의 없는 사안이라면 “반대 의견이 없다면”과 같은 형식의 메시지로 공지됩니다. 일반적으로 astropy-dev에서는 다른 구성원들이 자유롭게 의견을 내거나 투표할 수 있는 구체적인 제안이 올라오기를 기대합니다.
투표
투표는 대개 GitHub이나 astropy-dev 메일링 리스트에서 +1/-1 형식을 사용하여 진행합니다. 그곳에서는 관심 있는 사람이라면 누구나 프로젝트 내 공식 역할의 유무와 관계없이 투표할 수 있습니다. 또한 CoCo가 다수의 결정을 뒤집을 수 있는 거부권 제도는 없습니다.
논쟁적인 사안의 의사 결정 절차
비교적 단순한 논란거리는 일반적으로 astropy-dev 메일링 리스트 [3]에서 논의하며, 적절한 시간이 지난 뒤 명확한 합의나 타협에 이르거나(대부분 이렇게 됩니다), 논의가 교착 상태에 빠지지 않도록 CoCo가 결정을 내립니다.
더 복잡한 결정은 PEP 프로세스를 본뜬 APE 프로세스를 따릅니다. 이 경우 누구에게나 열려 있는 논의 기간이 지난 뒤 CoCo가 최종 결정을 내립니다. 일반적으로 CoCo는 합의나 다수의 의사를 따릅니다.
윤리적 문제
프로젝트에는 행동 강령 위반과 같은 민감한 문제에 대해 조정 위원회와 독립된 별도의 연락 창구를 보장하는 옴부즈퍼슨이 있습니다. 실제로는 CoCo, 커뮤니티 참여 코디네이터, 옴부즈퍼슨이 비공개로 협력하여 위반자와 소통하고 상황을 해결하려고 노력합니다.
새 릴리스 계획
메이저 릴리스 시기는 고정된 일정(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에게 보고하는 수석 부사장 (EVP)이 이끕니다.
각 EVP 아래에는 여러 기업 부사장 (CVP)이 있으며, 각자 하나 이상의 제품을 책임집니다. 이 PEP의 목적상 계층 구조가 의미를 갖기 시작하는 것은 바로 이 수준입니다. CEO와 EVP는 대부분의 의사 결정 과정에 거의 관여하지 않지만, CVP가 결정을 내리는 방향을 설정합니다.
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.