리더십 위원회
이 문서는 Rust 프로젝트의 성공적인 운영을 보장하기 위해 Rust 리더십 위원회(“위원회”)의 권한1과 정책을 정의합니다.
이 문서는 위원회를 규율하는, 현재 승인된 정책 전체를 정의하는 살아 있는 문서입니다. 이 문서는 위원회를 설립한 RFC 3392의 본문을 토대로 작성되었으며, RFC 절차를 통해 갱신될 수 있습니다.
위원회는 이 권한의 상당 부분을 팀(하위 팀, 워킹 그룹 등2을 포함합니다)에 위임하며, 각 팀은 자신의 관할에 관한 결정을 자율적으로 내립니다. 다만 위원회는 이 문서에서 개괄하고 그 범위를 한정한 일부 의사 결정 권한을 보유합니다.
위원회는 https://github.com/rust-lang/leadership-council에 별도의 홈 사이트를 운영하며, 그곳에서 내부 절차를 문서화하고 업무를 조율합니다.
위원회는 각 최상위 팀에서 위원회로 파견한 대표들로 구성됩니다.
위원회는 Rust 프로젝트 전체의 성공에 대한 책임을 맡습니다. 위원회는 수행해야 하지만 아직 명확한 담당자가 없는 일을 찾아내고, 그 일을 수행할 새 팀을 만들며, 기존 팀이 자신의 관할 업무에 책임을 지도록 하고, 프로젝트 팀의 조직 구조를 조율하고 조정합니다.
개요
동기
Rust 프로젝트는 전 세계에 분포한 수백 명의 사람들로 이루어져 있으며, 이들은 다양한 관할을 가진 팀으로 조직되어 있습니다. 그러나 상당히 많은 작업이 기존 어느 팀의 관할에도 속하지 않으며, 그럼에도 여전히 수행되어야 합니다.
위원회는 팀 관할 밖에 있는 작업을 파악하고 우선순위를 정하는 데 집중합니다. 위원회는 그러한 작업을 직접 수행하기보다는 주로 위임합니다. 위원회는 또한 팀 간 협업, 로드맵, 프로젝트의 장기적 성공 등과 관련하여 팀 사이의 조율, 조직, 책임성을 담당하는 기구 역할을 할 수 있습니다.
위원회의 의무, 기대 사항, 제약
개략적으로 말해, 위원회는 다음 의무만을 담당합니다:
- 명확한 소유자가 없어서(소유자가 명시적으로 우선순위를 낮추었거나 백로그에 넣어 둔 경우 등이 아니라) 수행되지 않고 있는 작업을 파악하고, 우선순위를 정하고, 추적하는 일.
- 이러한 작업을 위임하는 일로, 필요하다면 이 작업을 맡을 새로운(경우에 따라서는 임시) 팀을 설립하는 것도 포함합니다.
- 명확한 소유자가 없는 긴급한 사안에 대해 결정을 내리는 일.
- 이는 결정을 기존 팀이나 새로 만든 팀 어디에도 위임할 수 없는 예외적인 상황에서만 이루어져야 합니다.
- 팀, 구조, 프로세스에 대한 프로젝트 전반의 변경을 조율하는 일.
- 최상위 팀이 자신의 관할, 다른 팀, 그리고 프로젝트에 대해 책임을 지도록 보장하는 일.
- 가능한 한 팀이 작업을 수행하는 데 필요한 인력과 자원을 갖추도록 보장하는 일.
- Rust 프로젝트 전체의 공식 입장, 의견 또는 의지를 정립하는 일.
- 이는 프로젝트 전반의 조율 필요성을 줄이는 데 도움이 되며, 특히 긴 공개 의견 수렴과 합의 형성 과정이 현실적이지 않은 경우 - 예를 들어 Rust 프로젝트 전체가 무엇을 “원하는지” 어느 정도 이해해야 하는 제3자와 소통할 때 - 유용합니다.
이러한 의무 외에도, 위원회가 제대로 기능하고 있는지 판단하는 데 도움이 되도록 위원회에는 추가적인 기대 사항과 제약이 있습니다:
- 작업 위임: 위원회는 이 문서가 명시적으로 부여한 것 이상의 작업을 맡아서는 안 되며, 위원회와 구별되는 기존 팀이나 새 팀에 작업을 위임해야 합니다. 그러한 팀에 위원회 대표가 포함될 수는 있지만, 그러한 팀의 구성원이 되는 것은 위원회 대표의 의무에 포함되지 않습니다.
- 프로젝트가 장기적으로 원활하게 운영되도록 보장: 위원회는 긴급하지 않은 프로젝트 관리 작업의 우선순위가 정해지고, 프로젝트에 조직적 부채가 쌓이지 않을 만큼 충분히 규칙적으로 완료되도록 보장해야 합니다.
- 책임을 지십시오: 위원회는 폭넓은 권한을 행사하므로 위원회와 위원회 대표는 자신의 행동에 책임을 져야 합니다. 이들은 다른 사람의 피드백에 귀 기울여야 하며, 자신이 맡은 직위의 의무와 기대를 계속 충족하고 있는지 적극적으로 성찰해야 합니다.
- 대표성을 갖추십시오: 위원회 대표는 프로젝트의 폭넓은 관심사뿐만 아니라 가능한 한 많은 측면(인구 통계, 기술적 배경 등)에서 Rust 커뮤니티의 다양성도 대표해야 합니다.
- 부담을 나누십시오: 모든 위원회 대표는 위원회 업무의 부담을 함께 나누어야 합니다.
- 다른 팀의 관할을 존중하십시오: 위원회는 각 팀에 위임된 관할을 존중해야 합니다. 위원회는 이슈의 해결책을 두고 팀과 협의하고 함께 일해야 하며, 특정 팀의 뜻에 반하는 결정은 거의 내리지 않아야 합니다.
- 선의로 행동하십시오: 위원회 대표는 설령 그 결정이 자신이 속한 개별 팀, 고용주 또는 기타 외부 이해관계와 충돌하더라도 Rust 프로젝트 전체의 최선의 이익을 위해 결정을 내려야 합니다.
- 투명하게 행동하십시오: 모든 결정(또는 결정의 모든 측면)을 공개할 수는 없지만, 위원회는 자신의 의사 결정에 대해 가능한 한 개방적이고 투명해야 합니다. 또한 위원회는 프로젝트의 조직 구조가 명확하고 투명하도록 보장해야 합니다.
- 프라이버시를 존중하십시오: 위원회는 투명성을 이유로 개인 정보나 기밀 정보를 결코 침해해서는 안 되며, 여기에는 특권 정보를 의도치 않게 드러낼 수 있는 인접 정보도 포함됩니다.
- 건강한 업무 환경을 조성하십시오: 위원회 대표는 모두 자신이 기여하는 양과 성격에 만족감을 느껴야 합니다. 이들은 자신이 위원회에 있는 이유가 단지 의무감 때문이 아니라 의미 있는 방식으로 적극적으로 참여하고 있기 때문이라고 느껴야 합니다.
- 발전하십시오: 위원회는 팀, 프로젝트, 커뮤니티의 변화하는 요구를 충족하기 위해 시간이 지남에 따라 발전해 나갈 것으로 기대됩니다.
위원회 대표, 모더레이션 팀 구성원 및 기타 프로젝트 구성원은 주변 사람들과 더 넓은 커뮤니티에 본보기가 됩니다. 이러한 역할은 모두 책임과 리더십을 지닌 직위입니다. 이들의 행동은 무게를 지니며 커뮤니티 내에서 큰 영향력을 발휘할 수 있으므로 마땅히 신중하게 행사되어야 합니다. 따라서 이러한 역할을 맡기로 한 사람은 주변 사람들이 자신에게 그에 상응하는 높은 기준을 요구할 것임을 인식해야 합니다.
위원회의 구조
위원회는 팀 대표들로 구성되며, 각 대표는 하나의 최상위 팀과 그 하위 팀을 대표합니다.
각 최상위 팀은 스스로 선택한 절차에 따라 정확히 한 명의 대표를 지명합니다.
최상위 팀의 구성원이나 그 하위 팀의 구성원이라면 누구나 대표가 될 자격이 있습니다. 팀은 하위 팀 구성원에게 잠재적 후보에 대한 의견과 피드백을 제시할 기회를 제공해야 합니다.
각 대표는 다른 팀의 구성원이기도 하더라도 최대 하나의 최상위 팀만 대표합니다. 어떤 Rust 팀을 대표하는 주된 책임은 그 팀이 속한 최상위 팀의 대표에게 있습니다.3
Rust 프로젝트의 모든 팀은 궁극적으로 적어도 하나의 최상위 팀에 속해야 합니다. Launching Pad 팀은 현재 상위 팀이 없는 팀들의 임시 소속처 역할을 합니다. 이를 통해 모든 팀이 위원회에서 대표될 수 있습니다.
최상위 팀
위원회는 공개 정책 결정을 통해 최상위 팀을 설립합니다. 일반적으로 최상위 팀은 다음 기준을 충족해야 합니다.
- Rust 프로젝트의 근간이 되는 관할을 가집니다
- 해당 관할의 모든 측면에 대해 최종 의사 결정권자입니다
- 다른 팀 관할의 일부가 아닌 관할을 가집니다(즉, 하위 팀이나 이와 유사한 거버넌스 구조여서는 안 됩니다)
- 무기한 지속될 것으로 예상되는, 범위가 한정되지 않은 관할을 가져야 합니다
- 현재 Rust 프로젝트에서 활발히 활동하는 일부여야 합니다
최상위 팀은 4개 이상 9개 이하여야 하며, 5개 이상 8개 이하인 것이 바람직합니다. 이 숫자는 다양하고 비교적 얕은 구조를 바라는 요구와, 대표들 간의 생산적인 대화와 동의를 위한 실용성 사이의 균형을 맞춥니다.4
위원회가 새로운 최상위 팀을 만들면, 해당 팀은 위원회 대표를 지명합니다.5 새로운 최상위 팀을 만들 때 위원회는 그 팀이 하위 팀이나 다른 거버넌스 구조가 되어서는 안 되는 이유에 대한 근거를 제시해야 합니다.
최상위 팀은 다음과 같습니다:
- 컴파일러
- 개발 도구
- 인프라
- 언어
- Launching Pad
- 라이브러리
- 모더레이션
Launching Pad 최상위 팀
Launching Pad 팀은 달리 소속될 최상위 팀이 없는 하위 팀을 임시로 받아들입니다. 이를 통해 더 영구적인 상위 팀을 찾거나 만드는 동안에도 모든 팀이 위원회에 대표를 둘 수 있습니다.
Launching Pad 팀은 우산형 팀입니다. 직접 소속된 구성원은 없고 하위 팀 대표만 있습니다.
위원회는 Launching Pad의 각 하위 팀에 더 적합한 상위 팀을 찾거나 만들고, 이후 해당 하위 팀을 새 상위 팀으로 옮기도록 노력해야 합니다.
적합한 상위 팀이 존재하더라도 아직 하위 팀을 받아들일 준비가 되지 않은 경우가 있을 수 있으며, 이런 경우 Launching Pad가 임시 소속처 역할을 할 수 있습니다.
또한 어떤 팀이 폐지되거나 재편으로 없어질 때, 그 폐지나 재편에서 해당 팀의 하위 팀을 조직 내 다른 곳에 명시적으로 배치하지 않으면 Launching Pad가 그 하위 팀의 기본 소속처 역할을 합니다.
위원회는 6개월마다 Launching Pad에 속한 하위 팀 구성을 리뷰하여 모든 하위 팀의 새로운 상위 팀을 찾는 일이 적절히 진행되고 있는지 확인해야 합니다. 다른 최상위 팀과 마찬가지로, 위원회가 Launching Pad 팀이 더 이상 필요하지 않다고 판단하면 이 팀을 폐지할 수 있습니다(이 경우 위원회 내 대표도 없어집니다). Launching Pad 팀을 폐지하는 절차는 다른 최상위 팀과 같습니다. 아니면 위원회가 Launching Pad 팀에 고유한 관할을 부여할 수도 있습니다.
최상위 팀 제거
어떤 팀의 최상위 지위를 없애는(또는 다른 방식으로 위원회 참여 자격에 영향을 주는) 결정을 하려면, 제거 대상인 최상위 팀의 대표를 제외한 모든 위원회 대표의 동의가 필요합니다. 이러한 예외가 있더라도 해당 팀의 대표는 팀 제거에 관한 위원회 심의에 반드시 초대되어야 하며, 위원회는 극단적인 경우에만 그 팀의 반대를 무릅쓰고 팀을 제거해야 합니다.
위원회는 모더레이션 팀을 제거할 수 없습니다. 위원회는 모더레이션 팀의 동의 없이 모더레이션 팀의 관할을 변경할 수 없습니다.
대리인 및 대표권 포기
대표자는 참여 가능한 시간이나 사정이 바뀌는 등 필요한 경우 임기를 조기에 종료할 수 있습니다. 이 경우 해당 최상위 팀은 새 대표자 선출을 시작해야 합니다. 대표자 역할은 자원봉사직입니다. 누구도 이 역할을 맡을 의무가 없으며, 어떤 팀도 대표자로 활동하는 것을 팀 구성원 자격의 필수 의무로 삼을 수 없습니다. 다만 대표자는 대표자 직위의 직무를 수행하거나, 그렇지 않으면 그 직위에서 물러날 의무가 있습니다.
최상위 팀은 일시적으로 인원이 부족하여 대표자를 맡으려는 사람이 없는 경우 등에 대표권을 일시적으로 포기하기로 결정할 수 있습니다. 그러나 팀이 위원회 대표자를 지정하지 않으면, 그 팀은 프로젝트 전체 수준의 의사 결정에 적극적으로 참여할 권리를 포기하게 됩니다. 이러한 공백으로 인해 의사 결정을 포함한 위원회의 모든 절차가 가로막혀서는 안 됩니다. 위원회는 여전히 모든 프로젝트 구성원이 제시하는 새로운 정보와 이의를 검토할 의무가 있습니다. 그러나 위원회는 대표자가 없는 팀의 피드백을 특별히 검토하거나 취합하기 위해 결정을 보류할 의무는 없습니다.
위원회에 대표자를 파견하는 것은 최상위 팀의 의무로 간주되며, 이를 정기적으로 하지 못한다는 것은 해당 팀이 의무를 다하지 못하고 있다는 뜻입니다. 다만 위원회 대표자는 일시적인 질병, 휴가 등으로 인한 짧은 부재의 경우에는 그 역할을 포기하는 것이 아닙니다.
최상위 팀은 주 대표자가 참여할 수 없는 경우에 활동할 대리 대표자를 지정할 수 있습니다. 이 대리 대표자는 주 대표자가 복귀할 때까지 위원회 대표자의 역할을 온전히 맡습니다. 대리 대표자는 주 대표자가 참석하는 때에는 (참석자 수가 두 배로 늘어나는 것을 피하기 위해) 회의에 정기적으로 참석하지 않습니다.
팀의 대표자와 모든 대리 대표자가 3주 연속으로 위원회의 어떠한 절차에도 참여하지 않으면, 해당 팀이 참여 가능한 대표자를 세울 때까지 그 팀의 대표자는 위원회의 의사 결정 정족수 요건에 산입되지 않습니다. 위원회는 이 조치가 효력을 발생하기 전에 해당 팀에 이를 통지해야 합니다. 팀의 의견 없이, 또는 팀을 대신하여 이의를 제기할 수 없는 상태에서 위원회가 결정을 내리는 일이 없도록 하려면, 팀은 대리 대표자를 확보해 두어야 합니다.
최상위 팀은 필요한 경우 임기가 끝나기 전에 대표자를 교체할 수 있습니다. 그러나 연속성을 유지하는 데에는 부담이 따르므로, 팀은 필요 이상으로 대표자를 교체하는 일을 피해야 합니다. 팀이 지속적으로 다루고자 하는 팀 고유의 이슈나 입장에 대해 대표자와 대리 대표자에게 설명할 일차적 책임은 팀에 있습니다. 위원회 내에서 진행 중인 이슈의 연속성을 유지하고, 대리 대표자와 그 밖의 신임 대표자에게 맥락을 제공할 책임은 위원회와 팀이 함께 집니다.
비공개 사안의 경우, 위원회는 비공개 정보가 불필요하게 퍼지지 않도록 대리 대표자에게 알릴지를 신중히 판단해야 합니다. 대리 대표자가 대신 나서야 하는 경우에는 위원회가 그들에게 상황을 설명할 수 있습니다.
임기 제한
위원회 대표자의 임기는 1년입니다. 각 대표자는 특정 대표단(특정 최상위 팀에서 파견하는 대표단)에 대해 연속 세 번의 온전한 임기라는 비강제 한도를 적용받습니다. 대표자는 해당 팀이 다른 팀 구성원을 대표자로 세울 수 없다는 명시적 확인을 위원회가 받은 경우에 한하여 이 비강제 한도를 넘을 수 있습니다(예를 들어 맡으려는 다른 후보가 없거나, 팀 구성원들이 다른 모든 후보에 대해 차단 이의를 제기한 경우).
이 외에는 대표자가 다른 최상위 팀에서 맡을 수 있는 임기 수나, 한 최상위 팀에서 연속되지 않게 맡을 수 있는 임기 수에 대한 강제 한도는 없습니다. 팀은 경험의 연속성과, 여러 사람이 그러한 경험을 쌓을 수 있도록 대표자를 교대하는 것 사이에서 균형을 이루도록 노력해야 합니다.6
대표 임명의 절반은 3월 말에, 나머지 절반은 9월 말에 이루어집니다. 이렇게 하면 모든 위원회 대표가 한꺼번에 바뀌는 일을 피할 수 있습니다. 초기 위원회를 구성할 때와 최상위 팀 구성이 바뀔 때마다 위원회와 최상위 팀은 협력하여 임기 종료일이 3월과 9월에 대략 균등하게 나뉘도록 해야 합니다. 다만 각 임기는 최소 6개월 이상이어야 합니다(지나치게 짧은 임기를 피하기 위한 일시적인 불균형은 허용됩니다).
위원회와 최상위 팀이 적절한 임기 종료일 변경에 합의하지 못하면, 균형을 유지하기 위해 대표들을 두 종료일(최소 6개월 이후) 중 하나에 무작위로 배정합니다.
단일 회사/단체 출신 대표 수 제한
부적절한 일이나 부적절해 보이는 일을 피하기 위해 위원회 대표가 특정 회사, 법인 또는 밀접하게 관련된 법인들 출신으로 과도하게 치우쳐서는 안 됩니다. 위원회 대표가 5명 이하이면 같은 소속의 대표는 1명을 넘을 수 없고, 위원회 대표가 6명 이상이면 같은 소속의 대표는 2명을 넘을 수 없습니다.
밀접하게 관련된 법인에는 같은 법인의 지사/부서/자회사, 상당한 지분 관계로 연결된 법인 및 이와 유사한 경우가 포함됩니다. 위원회는 특이한 경우에 판단을 내릴 수 있으며, 그 결정에서 이해 상충이 생기지 않도록 주의해야 합니다.
위원회 대표가 어떤 회사나 기타 법인에서 소득의 상당 부분을 얻는다면(고용주, 고객, 주요 후원자 등) 그 법인에 소속된 것으로 봅니다. 대표는 소속이 바뀌면 즉시 이를 공개해야 합니다.
대표의 소속 변경, 최상위 팀의 신임 대표 임명, 위원회 규모 변경 등 어떤 이유로든 이 제약이 지켜지지 않게 되면 다음과 같이 제약을 복원합니다.
- 동일한 소속을 가진 대표들은 먼저 자신들끼리 이 이슈를 해결하려고 시도할 수 있으며, 이 경우 한 대표가 자발적으로 물러나고 그 대표의 팀이 다른 사람을 임명합니다.
- 이 결정은 소속 단체가 아니라 대표 본인이 내려야 합니다. 소속 단체가 이 결정에 영향을 미치는 것은 부적절한 일로 간주됩니다.
- 이러한 논의에서 대표들은 동등한 지위를 가집니다. 프로젝트나 위원회에서의 연공서열 같은 요소를 이용해 다른 사람에게 압력을 가해서는 안 됩니다.
- 해당 소속을 가진 대표들이 합의하지 못하면 그중 한 대표를 무작위로 해임합니다. (그래도 제약이 충족되지 않으면, 남은 대표들은 이 절차를 반복하기 전에 다시 자신들끼리 이 이슈를 해결하려고 시도할 수 있습니다.) 이 방식은 최선이 아닌 결과를 낳을 가능성이 높으므로, 일반적으로는 자발적인 해결책이 더 바람직합니다.
- 팀은 즉시 후임자 선정 절차를 시작해야 하지만, 팀의 기존 대표는 남은 임기 중 최대 3개월까지 계속 직무를 수행할 수 있습니다.
- 기존 대표는 신임 대표와 함께 인수인계를 조율해야 하지만, 최대 3개월의 기간 동안 둘 중 누가 실제 대표를 맡을지는 팀이 결정합니다. 최상위 팀의 대표는 언제나 한 명뿐입니다.
후보 기준
다음은 이상적인 후보를 정하기 위한 기준입니다. 이 기준은 유능한 팀 리드나 공동 리드의 기준과 비슷하지만 같지는 않습니다. 팀 리드가 좋은 위원회 대표가 될 수도 있지만, 팀 리드 역할과 위원회 대표 역할은 모두 상당한 시간을 들여야 하므로 두 역할을 서로 다른 사람이 나누어 맡는 편이 나을 가능성이 높습니다. 이 기준은 반드시 충족해야 하는 요건은 아니지만, 누가 팀의 대표를 맡기에 가장 적합한지 판단하는 데 활용할 수 있습니다. 요컨대 대표는 다음을 갖추어야 합니다.
- 위원회의 필요에 쏟을 충분한 시간과 에너지.
- 프로젝트 운영 및 프로젝트 거버넌스 관련 주제를 돕는 일에 대한 관심.
- 자기 팀이나 활발히 기여하는 영역 밖에서도 프로젝트가 필요로 하는 것에 대한 폭넓은 인식.
- 자기 팀이 필요로 하는 것에 대한 예리한 감각.
- 개인적인 의도보다 다른 사람들의 필요를 우선하여 대변하고 중심에 두는 성품과 능력.
- 일부 견해나 자신이 동의하는 견해만이 아니라 팀의 모든 견해를 대변할 능력과 의지.
일부 팀에는 현재 이 기준에 맞는 후보가 많지 않을 수 있지만, 위원회는 더 넓은 프로젝트 안에서 이러한 역량을 적극적으로 키워야 합니다. 이러한 역량은 위원회 구성원 활동뿐 아니라 프로젝트 전반에 걸쳐 도움이 되기 때문입니다.
자격 증명
위원회는 프로젝트의 관리용 자격 증명에 대한 특권적 접근 권한을 갖지 않습니다. 이 접근 권한은 오직 인프라 팀7에만 있습니다. 인프라 팀의 책임에는 인프라의 보안 및 유지 보수성과 균형을 맞추면서, 각 팀이 업무를 효과적으로 수행하는 데 필요한 도구와 접근 권한을 갖추도록 보장하는 일이 포함됩니다. 위원회는 정책을 통해 어떤 팀이 접근 권한을 가져야 하는지 조율하는 일을 도울 수 있습니다.
Rust 재단과의 관계
위원회는 프로젝트 이사(Project director)를 선출하는 절차를 수립할 책임이 있습니다. 프로젝트 이사는 Rust 프로젝트의 이익이 Rust 재단 이사회에 반영되도록 하는 수단입니다.
위원회는 재단 이사회에서 프로젝트의 이익을 대변하고 재단 관련 사안에 대해 특정 결정을 내릴 수 있는 관할을 프로젝트 이사에게 위임합니다. 해당 관할의 정확한 범위는 아직 정해지지 않았습니다.
위원회의 의사 결정 절차
위원회는 운영 결정과 정책 결정이라는 두 가지 유형의 결정을 내립니다. 결정의 분류에 따라 해당 결정에 특정한 고려 사항이 적용될 수 있습니다. 그러나 기본적으로 위원회는 분류와 관계없이 모든 결정에 동의 기반 의사 결정 절차를 사용합니다.
운영 결정과 정책 결정
운영 결정은 위원회가 목표를 수행하기 위해 일상적으로 내리는 결정이며, 여기에는 (수립된 정책에 따라) 회의 밖에서 이루어지는 정기적인 조치도 포함됩니다. 정책 결정은 운영의 틀을 잡고, 방향을 제시하고, 운영을 지원하기 위한 일반적이고 재사용 가능한 패턴이나 프레임워크를 제공합니다. 특히 정책 결정은 운영 결정이나 운영의 다른 측면을 부분적으로 자동화할 수 있습니다. 별도로 명시되지 않는 한, 위원회는 모든 결정에 기본적으로 동의 기반 의사 결정 절차를 따릅니다.
어떤 결정이 운영 결정이고 어떤 결정이 정책 결정인지는 정확하게 정의되어 있지 않으며, 오히려 결정들은 하나의 연속선상 어딘가에 놓입니다. 이 구분의 목적은 위원회의 의사 결정 절차를 지시하거나 제약하는 데 있지 않습니다. 오히려 이 구분은 위원회에 지침을 제공하고, 위원회가 시간이 지남에 따라 자신의 결정을 어떻게 기록하고 리뷰하고 개선할 것인지를 명확히 합니다. 운영/정책 분류와 관련된 요구 사항이나 지침을 적용할 때, 이 정책이나 향후 정책에서 운영 또는 정책 중 어느 것으로도 명시되지 않은 사항은 기본적으로 정책으로 간주합니다.
반복과 예외
정책 결정은 그렇지 않았다면 운영 결정을 반복해서 내려야 했을 사안을 체계적으로 다루는 경우가 많습니다. 위원회는 반복되는 운영 결정이 정책 결정이나 정책 변경의 필요성을 나타내는 시점을 알아차리도록 노력해야 합니다. 특히 위원회는 반복되는 운영 결정이 사실상의 정책으로 굳어지도록 방치하지 않아야 합니다.
기존 정책에 대한 예외는 해당 정책에서 그러한 예외를 명시적으로 허용하지 않는 한 운영 결정으로 만들 수 없습니다. 임시방편적인 예외를 피하면 “일탈의 정상화”를 막는 데 도움이 됩니다.
동의 기반 의사 결정 절차
동의란 어떤 대표자의 요구 사항(따라서 그 대표자가 대표하는 최상위 팀과 하위 팀의 요구 사항)도 무시될 수 없음을 의미합니다. 위원회는 관련된 모든 의견을 듣고, 모든 목소리에 동등한 무게를 두어 공평하게 함께 일할 수 있는 좋은 기반을 마련합니다.
위원회는 동의 기반 의사 결정 방식을 사용합니다. 이 방식에서는 대표자에게 “동의하십니까?“라고 묻는 대신 “반대하십니까?“라고 묻습니다. 이를 통해 제안을 충분히 검토하고도 그 이유에 대한 명확한 피드백 없이 승인하지 않기로 하는 “묵시적 거부권(pocket veto)“을 없앨 수 있습니다. 우려, 피드백, 선호 및 그 밖에 덜 중대한 형태의 의견은 결정을 막지 않지만, 초안 작성과 논의의 이른 단계에서 반영할지 여전히 검토해야 합니다. 충족되지 않은 요구 사항이나 필요를 나타내는 반대 의견은 결정을 진행하려면 반드시 검토되고 해소되어야 합니다.
승인 기준
동의 기반 의사 결정 절차의 승인 기준은 다음과 같습니다.
- 위원회가 지정한 소통 공간(회의 또는 특정 채널) 중 한 곳에 제안을 게시합니다.
- 최소 N-2명의 위원회 대표자(N은 위원회 대표자의 총수입니다)가 최종 제안을 충분히 검토하고 동의했음을 확인합니다.
- 어떤 위원회 대표자로부터도 해소되지 않은 명시적 반대 의견이 없어야 합니다.
- 피드백을 위해 최소 10일의 기간을 둡니다.
이 승인 기준은 정족수 메커니즘을 제공하는 동시에, 대표자들이 제안을 확인할 수 있는 충분한 시간을 보장합니다. 두 명까지 승인 표시를 하지 않아도 되도록 허용하는 것은 프로젝트가 자원봉사로 운영된다는 특성을 인정한 것입니다. 이는 결정의 속도와 동의 및 무반대에 필요한 확인의 양 사이에서 균형을 맞춰 온 경험에 기반하며, 해당 대표자들이 원했다면 반대 의견을 낼 시간이 있었다고 가정합니다. (이는 현재 RFC 승인에 사용되는 절차를 본뜬 것입니다.)
제안한 대표자가 제안을 철회하기로 결정하면 의사 결정 절차는 언제든지 종료될 수 있습니다. 다른 대표자는 언제든지 그 제안을 이어받아 유지할 수 있습니다.
이해 상충으로 인해 위원회가 어떤 결정에 대한 N-2 정족수를 충족할 수 없게 되면, 위원회는 이해 상충을 문서화한 상태로 결정을 진행하는 방법에 관한 “이해 상충” 섹션에 문서화된 절차를 따르지 않는 한 그 결정을 내릴 수 없습니다. 이러한 경우 위원회는 유사한 충돌이 앞으로 재발하지 않도록 적절한 절차와 정책을 검토해야 합니다.
의사 결정 절차의 수정과 조정
위원회는 공개 정책 절차를 통해 결정의 유형별로 서로 다른 의사 결정 절차를 수립할 수 있습니다.
특정 유형의 결정에 어떤 의사 결정 절차를 채택할지 정할 때, 위원회는 신속한 결정의 필요성과 완전한 합의에 대한 확신의 중요성 사이에서 균형을 맞춥니다. 동의 기반 의사 결정 절차는 다음과 같은 스펙트럼 위에 놓입니다.
- 합의 기반 의사 결정(신속한 의사 결정을 희생하더라도 완전한 의견 일치에 대한 확신을 우선시함): 팀 구성원은 제안을 리뷰하고 다른 모든 제안보다 해당 제안을 선호해야 하며, 어떤 팀 구성원이든 차단 이의를 제기할 수 있습니다
- 동의 기반 의사 결정(위원회의 기본 방식으로, 신속한 결정과 의견 일치에 대한 확신 사이의 균형을 맞춤): 팀 구성원은 제안을 리뷰해야 하며 차단 이의를 제기할 수 있습니다
- 1인 재청 및 이의 없음(의견 일치에 대한 확신을 희생하더라도 신속한 의사 결정을 우선시함): 한 명의 팀 구성원이 리뷰하고 지지해야 하며, 어떤 팀 구성원이든 차단 이의를 제기할 수 있습니다
의사 결정 절차를 정의하는 모든 정책은 최소한 제안을 게시할 수 있는 곳, 정족수 요건, 필요한 리뷰 수, 피드백을 위한 최소 대기 시간을 다루어야 합니다. 반대 의견이 없어야 한다는 것은 모든 의사 결정 절차의 승인 기준에 포함됩니다.
이해 상충으로 인해 위원회의 3분의 1을 초과하는 인원이 어떤 결정에 참여할 수 없게 되면, 위원회는 이해 상충을 문서화한 상태로 결정을 진행하는 방법에 관한 “이해 상충” 섹션에 문서화된 절차를 따르지 않는 한 그 결정을 내릴 수 없습니다. (이는 사용 중인 의사 결정 절차의 다른 정족수 요건과 관계없이 적용됩니다.) 이러한 경우 위원회는 비슷한 상충이 앞으로 다시 발생하지 않도록 적절한 절차와 정책을 검토해야 합니다.
위원회는 공개 정책 결정을 통해 자신의 의사 결정 관할 중 일부를 팀, 다른 거버넌스 조직, 또는 운영 책임자, 회의 진행자, 서기/간사처럼 위원회가 만들고 임명하는 역할에 위임할 수도 있습니다.
위원회는 제안의 초안 작성을 위임하더라도 그 제안을 승인하는 결정까지 반드시 위임해야 하는 것은 아니라는 점에 유의하십시오. 이는 여러 팀의 관할에 걸치거나 어느 팀의 관할에도 속하지 않는 프로젝트 전반의 정책에서 필요할 수 있습니다. 이는 새 팀을 점진적으로 꾸려 나갈 때에도 도움이 될 수 있습니다.
안건 및 백로그
위원회의 안건과 백로그는 프로젝트 전반에서 프로젝트 구성원이 제기한 사안을 위원회가 추적하고 그 진행 상황을 알리는 주요 창구입니다.
안건과 백로그의 공정성과 효과성을 높이기 위해 위원회는 다음을 이행해야 합니다.
- 프로젝트 구성원이 위원회에 요청을 제출하고 해당 요청의 진행 상황을 전달받을 수 있는 도구를 사용하십시오.
- 다가오는 기간의 우선순위와 목표를 정할 때 투명하고 포용적인 절차를 사용하십시오. 이 절차에는 모든 대표자의 정기적인 점검과 피드백이 포함되어야 합니다.
- 백로그와 안건에서 장기적인 전략 목표와 단기적인 필요 사이의 균형을 유지하도록 노력하십시오.
- 유연하고 적응력 있게 대처하며, 상황이나 우선순위가 바뀌면 필요에 따라 백로그와 안건을 기꺼이 조정하십시오.
- 백로그가 위원회의 현재 우선순위와 목표를 정확히 반영하도록 정기적으로 백로그를 리뷰하고 갱신하십시오.
- 역할(예: 회의 진행자와 기록 담당자)에 책임을 위임하고 회의 시작 시 안건에 동의하는 등, 백로그의 항목을 안건으로 옮길 때 명확하고 일관된 절차를 따르십시오. 동의 절차에서 거부된 안건 항목은 모두 그 반대 의견을 위원회가 공개하는 회의록에 기록해야 합니다.
교착 상태 해소
경우에 따라 위원회는 긴급하게 결정을 내려야 하지만, 그 시간 안에 모두가 동의할 제안을 마련할 수 없다고 판단할 수 있습니다. 이러한 경우, 적시에 결정을 내리지 못하는 것보다 자신이 반대하는 결정이라도 적시에 내리는 편이 더 나은 결과라는 데 모두가 동의한다면, 위원회는 교착 상태를 해소하기 위해 대안적인 의사 결정 방법을 사용할 수 있습니다. 이 대안적 절차는 비공식적이며, 위원회 구성원은 여전히 기존 의사 결정 절차를 통해 그 결과에 대한 동의를 재확인해야 합니다. 위원회 구성원은 여전히 언제든지 반대 의견을 제기할 수 있습니다.
예를 들어 위원회가 투표에 동의하면, 투표가 끝난 뒤 모든 위원회 구성원은 투표로 도출된 결정이 무엇이든 그에 동의하게 됩니다. 위원회는 특정한 대안적 의사 결정 모델을 선택할 때 예상되는 장점과 단점을 문서화하도록 노력해야 합니다.
교착 상태 해소를 위한 의무적인 메커니즘은 의도적으로 두지 않았습니다. 대표자들이 결정의 결과를 선호하지 않더라도 결정을 내리는 데 모두 동의하지는 않거나, 어느 대표자라도 위원회의 동의를 얻을 수 있는 제안을 아직 만들 수 있다고 생각한다면, 대표자는 언제든지 반대 의견을 유지할 수 있습니다.
대표자가 반대 의견을 철회하거나 (대안적 의사 결정 절차의 결과이든 아니든) 완전히 동의하지는 않는 결정에 동의한 경우, 위원회는 평가 일정을 잡거나 이미 예정된 평가까지의 기간을 단축하는 것을 고려해야 하며, 제기된 우려를 측정하고 평가할 수단을 마련해야 합니다. 이 리뷰의 결과는 위원회가 이전 결정의 변경을 고려해야 하는지 판단하기 위한 것입니다.
피드백 및 평가
모든 정책 결정에는 정책의 일부로 평가 날짜가 포함되어야 합니다. 최초 평가 기간은 이후의 평가 기간보다 짧아야 합니다. 평가 기간의 길이는 상황의 필요에 따라 조정되어야 합니다. 잘 작동하는 것으로 보이고 변경이 거의 필요하지 않은 정책은 불필요한 리뷰에 드는 시간을 줄이도록 기간을 연장해야 합니다. 최근에 조정되었거나 문제가 제기된 정책은 평가 기간을 단축하여 더 빠르게 반복 개선하며 안정에 이르도록 해야 합니다. 위원회는 새 정책의 기간을 정할 때 기본값으로 사용할 수 있도록 정책 유형별 표준 기간을 마련해야 합니다. 예를 들어 역할은 처음에 3개월, 그 이후에는 1년의 평가 날짜를 둘 수 있으며, 일반 정책은 처음에 6개월, 그 이후에는 2년을 기본값으로 둘 수 있습니다.
- 새로운 정책 결정은 언제든지 기존 정책을 수정하거나 대체할 수 있습니다.
- 정책 결정은 버전 이력과 함께 한곳에 모아 공개해야 합니다.
- 현행 정책 문서를 수정할 때는 사람들이 나중에 관련 맥락을 직접 찾아보리라 기대하지 말고, 해당 정책 결정과 관련된 맥락을 포함하거나 링크해야 합니다.
의사 결정의 투명성과 감독
위원회가 내리는 결정은 결정의 종류에 따라 필연적으로 서로 다른 수준의 투명성과 감독을 요구합니다. 이 절에서는 위원회가 자신의 결정에 대해 어떻게 감독을 받을지, 그리고 어떤 결정을 비공개로 또는 공개적으로 내릴 수 있는지에 관한 지침을 제공합니다.
이 RFC는 특정 결정들을 각 범주에 배정합니다. 구체적으로 열거되지 않은 모든 결정은 공개 정책 절차를 따라야 합니다. 위원회는 공개 정책 절차를 통해 이 분류를 발전시킬 수 있습니다.
위원회가 내리는 결정은 가능하고 필요한 감독의 수준에 따라 다음 세 가지 범주 중 하나에 속합니다.
- 위원회가 내부적으로 내릴 수 있는 결정
- 위원회가 필연적으로 비공개로 내려야 하는 결정
- 위원회가 공개 제안을 통해 내려야 하는 결정
위원회가 내부적으로 내릴 수 있는 결정
일부 유형의 운영 결정은 위원회가 내부적으로 내릴 수 있으며, 다만 위원회는 결정이 내려진 후 그 결정에 대한 커뮤니티 피드백을 받을 수 있는 체계를 갖추고 있어야 합니다.
위원회가 내부적으로 내릴 수 있는 결정 목록에 새로운 결정을 추가하려면 공개 정책 결정이 필요합니다. 위원회 자체의 구조, 의사 결정권자 또는 감독에 영향을 미치는 결정은 이 목록에 추가해서는 안 됩니다.
또한 위원회는 공개 제안을 피하려는 목적으로 내부 결정을 반복하여 사실상의 불문 정책을 만드는 일이 없도록 노력해야 합니다. 자세한 내용은 “반복과 예외”를 참조하십시오.
다음 목록은 위원회가 내부적으로 내릴 수 있는 결정을 빠짐없이 열거한 것입니다.
- 그 자체가 공개적으로 진행될 절차를 시작하기로 하는 결정(예: “설문 조사를 만들어 게시하기 시작합시다”, “향후 내릴 이 공개 결정을 위한 RFC 초안을 작성합시다”).
- Rust 프로젝트의 공식 입장문을 표명하고 전달하는 일.
- Rust 재단과 같은 다른 주체에 Rust 프로젝트의 입장을 직접 표명하고 전달하는 일.
- Rust 프로젝트의 소통 수단(블로그 또는 all@)을 통해 소통하는 일.
- 위원회의 조율 방식, 소통에 사용하는 플랫폼, 회의 장소와 시간, 결정을 내리고 기록하는 데 사용하는 템플릿 등 위원회 자체의 내부 절차에 관한 대부분의 운영 결정을 내리는 것(이 문서의 다른 부분에 있는 요건을 따릅니다).
- 회의 주재·진행, 회의록 작성 및 게시, 여러 당사자로부터의 의견 수집 및 정리 등의 목적으로 위원회 내에 임원이나 임시 역할을 임명하는 일.8 이러한 역할(직함, 직무, 현재 담당자)은 반드시 공개적으로 알리고 문서화해야 한다는 점에 유의하십시오.
- 특정 위원회 회의나 논의에 위원회 대표 이외의 특정 참석자를 초대하거나, 더 넓은 커뮤니티에 공개된 회의를 개최하는 일. (특히 위원회는 특정 결정을 논의할 회의나 논의 자리에 해당 결정의 이해관계자를 초대하는 것이 권장됩니다.)
- 하나 이상의 팀이 요청한 결정으로서, 해당 팀들이 공개 제안 없이 내릴 수 있는 통상적인 관할에 속하는 결정을 내리는 일. (팀은 위원회의 결정을 요청하지 않고도 위원회의 의견을 구할 수 있다는 점에 유의하십시오.)
- 팀들의 관할이 겹치거나 모호한 영역에서 일회성 판단을 내리는 일(단, 해당 팀들의 관할을 변경하는 것은 공개 정책 결정이어야 합니다).
- 이 문서나 향후 위원회 정책에서 운영 결정으로 명시하는 모든 결정.
위원회 결정에 대한 의견 제시 메커니즘에 관한 자세한 내용은 책임성 절을 참조하십시오.
위원회가 필연적으로 비공개로 내려야 하는 결정
일부 결정은 필연적으로 개인이나 다른 주체의 사적인 세부 사항을 수반하며, 이러한 세부 사항을 공개하면 해당 개인이나 주체(예: 안전)와 프로젝트(신뢰 약화) 모두에 부정적인 영향을 미치게 됩니다.
이 추가 제약은 예외적인 경우로 간주해야 합니다. 이는 다음 절에 따라 공개 제안이 필요한 결정을 내리는 것까지 허용하지는 않습니다. 다만 위원회가 내부적으로 내리는 결정을 공개 감독에 필요한 정보를 모두 제공하지 않은 채 비공개로 유지하는 것은 허용합니다.
위원회는 해당 사안이 자신의 관할 밖이라고 판단하는 경우(그래서 다른 팀에 맡기기로 하는 경우)나 해당 사안을 공개적으로 처리해야 한다고 판단하는 경우 등에는 비공개로 결정을 내리는 것을 거절할 수도 있습니다. 그러나 그러한 경우에도 위원회는 기밀로 공유받은 정보를 공개적으로 밝힐 수 없습니다(그렇지 않으면 위원회가 그러한 정보를 받을 만큼 신뢰받지 못할 것이기 때문입니다). 안전에 대한 위협이 임박한 경우에는 당연히 예외가 적용됩니다.
비공개 결정으로 정책을 수립해서는 안 됩니다. 또한 위원회는 공개 제안을 피하려는 목적으로 비공개 결정을 반복하여 사실상의 불문 정책을 수립하는 일이 없도록 노력해야 합니다. 자세한 내용은 “반복과 예외”를 참조하십시오.
다음 목록은 위원회가 부분적으로 또는 전적으로 비공개로 내릴 수 있는 결정을 빠짐없이 열거한 것입니다.
- 출범 전에 기밀 유지가 필요한 새로운 업계 / 오픈 소스 이니셔티브와의 관계를 결정하는 일.
- 대인 관계의 역학/갈등이 얽힌 팀 간 분쟁의 개인적 측면을 논의하는 일.
- 프로젝트를 대표하여 제3자와의 계약 협상에 참여하는 일(예: 프로젝트에 제공되는 자원을 수락하는 일).
- 정치, 개인 안전, 또는 사람들이 공개적으로 자유롭게 발언하기에 안전하지 않을 수 있는 기타 주제 중 프로젝트와 관련된 논쟁적 측면을 다루는 결정.
- 팀이나 개인에게 도움과 지원이 필요한지, 그리고 그 이유가 무엇인지를 논의하는 일로, 이는 개인적인 사안과 관련될 수 있습니다.
- 이 문서 또는 향후 위원회 정책이 비공개 결정으로 지정하는 모든 결정.
위원회는 비공개 또는 공개 결정으로 이어지는 비공개 논의에 다른 팀의 구성원을 참여시킬 수 있습니다. 단, 그렇게 함으로써 위원회에 공개된 비공개 정보가 허가 없이 더 넓게 노출되는 경우는 예외입니다. 가능한 경우 위원회는 결정의 영향을 받는 사람이나 팀을 참여시키도록 노력해야 합니다. 이는 추가적인 감독 역할도 합니다.
일부 사안은 완전히 공개하기에는 적합하지 않더라도 더 작고 더 신뢰할 수 있는 범위(예: 모든 프로젝트 구성원, 팀 리드, 또는 관련/영향을 받는 당사자)에서는 공유해도 괜찮을 수 있습니다. 위원회는 해당 정보에 적절한 범위 내에서 가장 넓은 대상과 정보를 공유하도록 노력해야 합니다.
위원회는 정보가 민감한지 불분명한 경우 새로운 결정이나 결정의 일부 측면을 공개하지 않기로 할 수 있습니다. 그러나 시간이 지나 적절한 공유 대상이 누구인지 더 분명해지거나 적절한 공유 대상이 확대되었음이 분명해지면, 위원회는 정보 공유에 관한 결정을 재검토해야 합니다.
위원회는 대인 갈등/분쟁과 관련된 사안에 대해서는 항상 모더레이션 팀을 참여시켜야 합니다. 그러한 사안이 모더레이션 팀의 관할이기 때문이며, 또한 추가적인 감독을 제공하기 위함입니다.
위원회는 한 부분이 비공개여야 한다는 이유만으로 사안 전체를 비공개로 유지하기보다는, 결정이나 관련 논의 중 어느 부분이 반드시 비공개여야 하는지 평가하고, 민감하지 않은 부분을 공개하는 것이 현실적으로 가능한지 검토해야 합니다. 여기에는 논의가 있었다는 사실이나 대략적인 주제가 포함될 수 있으며, 이는 해당 세부 사항 자체가 민감하지 않은 경우에 한합니다.
비공개 사안은 더 이상 민감하지 않게 되면 나중에 공개되거나 부분적으로 공개될 수도 있습니다. 그러나 일부 사안은 결코 공개되지 못할 수도 있으며, 이는 해당 사안이 더 폭넓은 리뷰와 감독의 대상이 결코 되지 않는다는 것을 의미합니다. 따라서 위원회는 비공개 결정을 내리기 전에 신중하고 사려 깊게 판단해야 합니다.
위원회는 비공개 결정을 내리지 않도록 최선을 다해야 합니다. 위원회는 대표들이 그러한 결정을 함께 리뷰하고 그 필요성을 검토하도록 장려하는 적절한 추가 절차를 마련해야 합니다.
위원회가 공개 제안을 통해 내려야 하는 결정
이 범주의 결정을 내릴 때 위원회는 결정을 내리기 전에 더 넓은 Rust 프로젝트로부터 공개적으로 피드백을 구해야 합니다. 이러한 결정은 적절한 공개 결정 절차를 통해 제안되고 결정되며, 현재는 RFC 절차가 이에 해당합니다(다만 위원회는 향후 다른 공개 제안 절차를 채택할 수 있습니다). 공개 결정 절차는 대표자들의 동의(적극적 찬성 또는 이의 없음을 통한 동의)를 요구해야 하고, 위원회 대표자들이 차단 이의를 제기할 수 있도록 허용해야 하며, 공개적인 평가와 논의를 위한 합리적인 시간을 제공해야 하고, 위원회에 공개 피드백을 전달할 수 있는 명확한 경로를 제공해야 합니다.
기존 RFC 절차에 따라, 공개 제안은 결정이 효력을 발휘하기 전에 피드백을 위한 최소 유예 기간을 두어야 합니다. 모든 대표자는 특정 결정에 대한 피드백 기간을 총 최대 20일까지 연장하도록 요청할 수 있습니다. 위원회는 내부 운영 결정을 통해 피드백 기간을 20일을 넘겨 연장할 수 있습니다. 피드백 유예 기간은 제기된 이의가 없어야 한다는 조건을 포함하여 승인에 필요한 나머지 요건이 모두 충족된 때에만 시작됩니다. 유예 기간 중에 이의가 제기되었다가 해소되면, 대기 기간은 처음부터 다시 시작됩니다.
위원회는 팀, Rust 프로젝트, 커뮤니티의 변화하는 요구를 충족하기 위해 시간이 지남에 따라 발전해 나갈 것으로 예상됩니다. 이러한 발전적 변화는 범위가 작을 수도 있고 클 수도 있으며, 그에 상응하는 수준의 감독이 필요합니다. 위원회의 형태에 실질적인 영향을 미치는 변경은 공개 결정 절차를 거쳐야 합니다.
위의 내용에 대한 예외로, 단일 최상위 팀(모더레이션 팀 제외)의 변경 또는 폐지는 해당 최상위 팀이 위임한 대표자를 제외한 위원회의 만장일치 합의로 이루어질 수 있습니다.
위원회는 최종적으로 공개 제안이 되거나 공개적으로 알려지는 내부 결정이 되는 사안에 대해서도 비공개 논의를 할 수 있습니다. 논의가 민감한 경우, 위원회는 결정 참여자들이 더 솔직하고 자유롭게 발언할 수 있도록 이렇게 하기를 원할 수 있습니다. 또한 경우에 따라서는 공개할 수 없는 비공개 정보가, 그렇지 않았다면 공개 결정이나 공개 제안이 되었을 사안에 영향을 미칠 수 있습니다. 위원회는 최대한 투명하고 오해의 소지가 없도록 노력해야 하며, 모든 근거가 비공개인 불투명한 결정은 피해야 합니다.
(이 문서나 향후의 공개 제안을 통해) 다른 범주에 속한다고 명시적으로 지정되지 않은 한 모든 결정은 이 범주에 속한다는 점에 유의하십시오. 따라서 이 목록은 (다른 두 범주의 목록과 달리) 의도적으로 모호하고 광범위하게 작성되었습니다. 이 목록은 반드시 무언가를 규정하려는 것이 아니라, 어떤 결정이 이 범주에 속할 가능성이 높은지에 대한 지침을 제공하기 위한 것입니다.
- 위원회의 의사 결정자 목록이나 위원회의 의사 결정 절차를 변경하는 효과를 갖는 모든 결정입니다. 예를 들면 다음과 같습니다.
- 이 목록(또는 이 문서 전반)을 변경하는 것입니다.
- 위원회의 공개 제안에 사용되는 공표 및 승인 절차를 변경하는 것입니다. 이러한 제안은 제안된 새 절차가 아니라 기존에 확립된 절차를 따라야 합니다.
- 위원회 대표자의 자격 요건에 영향을 미치는 정책을 추가, 변경 또는 폐지하는 것입니다.
- 하나 이상의 최상위 팀을 추가, 변경 또는 폐지하는 것입니다. 여기에는 다음이 포함됩니다.
- 최상위 팀의 관할을 사실상 다른 팀이 될 정도로 변경하는 것입니다.
- 최상위 팀이 다른 팀 아래로 들어가도록 프로젝트를 재편하는 것입니다.
- 최상위 팀이 위임한 대표자 외에 다른 유형의 위원회 대표자를 추가하는 것입니다.
- 위원회 정족수 또는 구속력 있는 결정을 내릴 수 있는 장소에 관한 정책을 추가, 변경 또는 폐지하는 것입니다.
- 일회성 운영 결정이 아닌 모든 정책 결정입니다. (정책 결정과 운영 결정의 차이에 대한 자세한 내용은 의사 결정 섹션을 참고하십시오.) 여기에는 프로젝트의 다른 부분(예: 다른 팀이나 개인)의 결정을 구속하여 사실상 모든 팀의 통상적인 관할에 대한 예외로 작용하는 모든 결정이 포함됩니다. 정책 결정의 몇 가지 예는 다음과 같습니다.
- 이전에 RFC를 통해 만들어진 정책을 포함하여 기존 정책을 변경하거나 확장하는 것입니다.
- Rust 프로젝트 소프트웨어나 Rust 프로젝트의 기타 작업에 영향을 미치는 법률 및 라이선스 정책입니다.
- 행동 강령의 변경.
- Rust 프로젝트 또는 그 산하 팀의 구성원 자격에 영향을 미치는 정책.
- 모더레이션 팀이 위원회 대표 또는 위원회 전체를 모더레이션하는 방식의 변경. 이러한 결정은 모더레이션 팀과 공동으로 내려야 합니다.
- Rust 프로젝트를 대신하여 지속적인 의무를 지는, 다른 프로젝트나 조직과의 합의. (해당 의무에 동의한 팀이 관련된 일회성 의무는 괜찮습니다.)
- 법적 구조의 신설 또는 상당한 수정(예: 추가 재단 설립, Rust 재단과의 관계 변경, 다른 법인과의 제휴).
- 하나 이상의 팀이 요청한 정책 결정으로서, 원래 해당 팀의 통상적인 관할에 속하는 결정을 내리는 것. (팀은 위원회의 결정을 요청하지 않고도 위원회의 의견을 구할 수 있다는 점에 유의하십시오.)
- 특정 유형의 향후 결정을 다른 팀에 위임하지 않고 항상 위원회의 권한에 속하도록 정하는 것.
- 이 문서 또는 향후 위원회 정책이 공개 정책 결정으로 명시하는 모든 결정.
이해 상충
위원회 대표는 자신에게 이해 상충이 있는 결정에 참여하거나 영향력을 행사해서는 안 됩니다.
이해 상충의 잠재적 원인에는 다음이 포함되며, 이에 국한되지 않습니다:
- 개인적 관계: 자기 자신에 관한 결정
- 재정적 관계: 대표에게 실질적인 재정적 영향을 미치는 결정
- 고용 또는 이에 준하는 관계: 같은 회사의 다른 사람이 관련된 결정, 또는 해당 회사에 다른 곳보다 불균형하게 더 큰 이익이나 손해를 주는 결정
- 직업적 관계 또는 기타 소속: 산업·직업·표준·정부 기관 등 대표가 관계를 맺고 있는 조직이 관련된 결정
- 가족/친분 관계: 대표가 공정할 것이라고 기대하기 어려운 사람에 관한 결정(해당 인물을 통해 생기는 다른 유형의 이해 상충 포함, 예: 가족 구성원의 사업)
위원회 대표는 이해 상충을 즉시 공개하고 영향을 받는 결정에서 스스로 물러나야 합니다. 또한 위원회 대표는 잠재적 이해 상충이 생길 만한 원인을 매년 다른 대표와 모더레이션 팀에 미리 공개해야 합니다.
제안에 특정 주체가 명시되지 않더라도 이해 상충이 발생할 수 있다는 점에 유의하십시오. 예를 들어, 위원회 대표는 자신의 지위를 이용하여 제안의 요구 사항을 자신의 고용주에게 불균형하게 유리하도록 조정할 수 없습니다.
Rust 커뮤니티 전반에서 널리 지지받는 제안은, 그 제안이 특정 주체에 유리하지 않은 한, 대표의 고용주나 이에 준하는 곳도 그 제안의 전반적인 분야를 지지한다는 이유만으로 자동으로 그 대표의 이해 상충이 되지는 않습니다. 예를 들어, 특정 Rust 구성 요소의 보안을 개선하자는 제안은 대표의 고용주가 일반적으로 Rust 보안에 관심을 둔다는 이유만으로 그 대표에게 이해 상충이 되지는 않습니다. 그러나 특정 개발자나 보안 전문가를 참여시키자는 제안, 또는 자신의 보수가 그러한 제안에 좌우되는 경우에는 여전히 이해 상충이 생길 수 있습니다.
위원회는 이해 상충이 해당되는 경우, 이를 경미하다고 판단하더라도 면제할 수 없습니다. 다만 위원회는 애초에 이해 상충이 존재하는지 여부를 평가할 수 있습니다. 위원회 대표는 위원회가 그러한 판단을 내릴 수 있도록 잠재적 이해 상충을 제기해야 합니다.
위원회는 결정에서 물러난 대표에게 특정 정보를 요청할 수 있으며, 그 대표는 요청을 받으면 해당 정보를 제공할 수 있습니다.
가능하고 실용적인 경우, 위원회는 이해 상충의 범위를 줄이기 위해 결정을 분리해야 합니다. 예를 들어, 그렇게 함으로써 이해 상충이 후자의 결정에만 해당되게 된다면, 위원회는 특정 유형의 하드웨어에 접근할 수 있도록 마련하는 결정(구체적인 요구 사항을 정하거나 공급업체를 선정하지 않는 결정)을 정확히 어떤 하드웨어를 어디에서 구매할지에 대한 결정과 분리할 수 있습니다.
대표가 Rust 프로젝트의 이익과 어떤 프로젝트 팀의 이익을 동시에 고려하는 것이 반드시 이해 상충인 것은 아닙니다. 특히 대표는 소속 팀의 대리인으로서 해당 팀과 관련된 결정에 정기적으로 참여할 것으로 기대됩니다.
드물기는 하지만 제안된 결정이 충분히 많은 대표에게 이해 상충을 일으켜 나머지 인원으로는 이전에 정한 정족수 요건을 충족할 수 없고, 그럼에도 결정을 반드시 내려야 하는 경우, 최상위 팀들이 해당 결정을 위한 대리 대표를 지정하거나, (공개 결정에 한해) 위원회가 모든 이해 상충을 공개적으로 문서화하면서 결정을 진행하기로 선택할 수 있습니다. (이해 상충을 문서화하더라도 공개 결정을 진행한다고 해서 실제로 이해 상충이 없어지거나 이해 상충이 결정에 영향을 미치는 것을 막을 수 있는 것은 아니며, 단지 이해 상충이 결정에 영향을 미쳤을 수 있는지를 대중이 판단할 수 있게 할 뿐이라는 점에 유의하십시오. 충돌을 완전히 없애는 편이 언제나 더 바람직합니다.) 이런 경우 위원회는 비슷한 충돌이 다시 생기지 않도록 적절한 절차와 정책을 검토해야 합니다.
팀 관할의 결정 및 변경
위원회는 어떤 영역이나 활동을 이미 있는 최상위 팀이나 새로 만든 최상위 팀(모더레이션 팀 제외)의 관할 사이에서 옮길 수 있습니다. 각 최상위 팀은 자기 관할을 더 세분할 수 있지만, 위원회는 최상위 관할만 옮기거나 조정합니다. 세분된 관할을 옮기는 경우, 위원회는 관련 팀들과 협력하여 적절한 후속 조치를 조율합니다. 이 메커니즘은 기존 팀의 관할이 너무 넓어서 현재 구조로는 그 팀이 관할 전체를 감당하리라고 기대하기 어렵다고 위원회가 판단할 때 사용해야 합니다. 그러나 팀이 일부 업무를 수행할 자원이 당장 부족할 뿐인 경우에는 이 메커니즘을 사용해서는 안 됩니다.
또한 최상위 팀의 관할을 확대하려면 위원회의 승인을 받아야 하며, 최상위 팀의 관할을 축소할 때는 위원회에 알려야 합니다. 이런 일은 대개 팀이 스스로 관할을 확대하거나 축소하기로 정할 때 일어납니다. 최상위 팀들이 서로 관할을 조정하기로 합의하는 과정에서 일어날 수도 있습니다. 위원회가 관할 변경을 알고 있어야 하는 이유 중 하나는 위원회가 그 관할을 다른 곳에 다시 배정하거나 의도적으로 배정하지 않은 채로 둘 수 있도록 하기 위해서입니다.
다만 팀은 (단독으로든 공동으로든) 위원회의 승인 없이 자기 관할을 하위 팀에 다시 위임할 수 있습니다. 최상위 팀은 위임을 하더라도 자신에게 배정된 관할 전체에 대해 계속 책임을 집니다(다시 말해, 위임이 성공적으로 이루어지도록 하는 것도 팀의 책임입니다).
팀 사이에서 관할을 옮기는 것은 비교적 무거운 조치이므로, 위원회는 그에 앞서 팀과 함께 대안 전략을 모색하는 쪽을 우선해야 합니다. 또한 이 메커니즘의 사용 사례 중 하나는, 이전에 어떤 팀에 위임했지만 그 팀이 사실상 더 이상 존재하지 않게 된 경우(예를 들어 팀에 시간을 낼 수 있는 사람이 아무도 없는 경우) 그 관할을 옮기는 것이며, 이는 시간과 역량을 갖춘 사람들이 나타나 그 팀을 다시 꾸릴 때까지 비교적 일시적으로 이루어질 수도 있다는 점도 짚어 둘 만합니다. 이 절은 이러한 협의를 정확히 어떻게 할지(또는 할지 말지)에 대해 위원회에 의도적으로 제약을 두지 않습니다.
감독 및 책임 메커니즘
다음은 위원회가 자신과 다른 이들의 책임을 확보하기 위해 사용하는 여러 메커니즘입니다.
위원회의 책임 확보
위원회는 더 넓은 프로젝트와 커뮤니티가 위원회에 거는 기대가 꾸준히 충족되도록 공개적으로 보장해야 합니다. 이는 위원회의 정책, 절차, 결과를 조정하는 방식과 함께, 프로젝트와 커뮤니티의 기대가 현실과 맞지 않을 때 이를 알리고 설명하는 방식으로 이루어져야 합니다.
이를 위해 위원회는 대표를 교대하고 “기본적으로 공개“라는 원칙을 따르는 것에 더해, 정기적으로(적어도 분기마다) 누구나 쉽게 볼 수 있는 방식으로 활동 내용을 공개해야 하며, 직무, 기대, 제약 목록을 평가 기준으로 삼아 위원회가 얼마나 잘 기능하고 있는지에 대한 평가도 함께 제공해야 합니다.
위원회는 해마다 참여할 뜻과 여건이 있는 모든 프로젝트 구성원에게 위원회가 그 목적을 효과적으로 수행하고 있는지에 대한 의견을 구해야 하며, 모든 프로젝트 구성원의 적극적인 참여를 허용하고 장려하는 자리에서 이 의견을 공개적으로 논의해야 합니다. 이를 위해 위원회와 다른 프로젝트 구성원은 이 문서와 이후의 모든 개정본에 나열된 상위 수준의 직무, 기대, 제약을 참고하여 위원회가 직무와 의무를 다하고 있는지 판단합니다.
또한 이 문서, 다른 위원회 정책 및 절차, 또는 위원회의 책임성에 관한 다른 모든 측면을 따르지 않는 일을 주시하고, 지적하며, 그에 동조하기를 거부하는 것은 모든 대표 개개인의 책임입니다. 대표는 “책임 분산”을 적극적으로 피하도록 힘써야 합니다. 책임 분산이란 구성원 각자가 (의식적으로든 무의식적으로든) 다른 누군가가 그 일을 하리라고 믿는 바람에 집단 전체가 그 일을 하지 못하게 되는 현상입니다. 위원회는 절차 문제를 처리하고 점검하며 특히 절차상 이의를 제기하는 책임을 맡을 역할을 따로 지정할 수도 있습니다. 그렇더라도 다른 사람들 역시 여전히 그렇게 할 수 있고, 그렇게 해야 합니다.
위 과정의 어느 부분에서든 위원회가 의무를 다하고 있지 않다는 결론이 나오면, 위원회가 의무를 더 잘 다할 수 있도록 어떻게 바뀔지에 대한 계획을 되도록 빨리 제시해야 합니다. 이를 위해 헌장 등을 변경하는 RFC, 대표 교대, 또는 그 밖의 실질적인 변경이 필요할 수 있습니다. 모든 계획에는 지난 한 해의 경험에 비추어 위원회나 Rust 거버넌스 전체, 또는 둘 다가 어떻게 발전할지에 대한 구체적인 방안이 담겨야 합니다.
위원회 대표의 책임 확보
위원회 대표자는 대표자로서의 의무를 얼마나 잘 수행하고 있는지 돌아보기 위해 서로 간에, 그리고 각자의 최상위 팀과 정기적으로 피드백을 주고받아야 합니다(그 구체적인 방식은 이 문서의 범위를 벗어납니다). 피드백 세션의 목표는 대표자가 프로젝트에 더 잘 기여할 수 있는 방법을 더 잘 이해하도록 돕는 것입니다. 이 피드백은 모든 대표자, 해당 대표자가 속한 최상위 팀의 모든 구성원, 그리고 모더레이션 팀과 공유해야 합니다. 이 피드백에서는 대표자가 잘한 점과 더 잘할 수 있었던 점을 모두 물어야 합니다.
이와 별도로, 대표자는 언제든지 자신의 팀과 동료 대표자로부터 비공개 피드백을 받을 수 있도록 열려 있어야 하며, 위원회에서 자신이 맡은 역할과 그 효과성에 대해 정기적으로 스스로 돌아보아야 합니다.
안전하고 열린 절차를 보장하기 위해, 이러한 피드백 절차에서 나온 결과물은 절대 공개해서는 안 됩니다. 또한 위원회는 결과가 긍정적인 변화로 이어지지 않는 경우 피드백 절차를 되돌아보고 조정해야 합니다.
위원회의 다른 구성원이 어떤 위원회 대표자가 나머지 위원회 구성원과 잘 협력하지 못한다고 느낀다면, 해당 대표자와 대화해야 하며 필요한 경우 그 대표자의 팀과도 대화해야 합니다. 위원회 대표자는 이러한 대화를 원활하게 진행하기 위해 필요에 따라 모더레이션/중재 자원을 활용해야 합니다. 모더레이션은 해당 이슈를 해결하는 데 도움을 줄 수 있으며, 해당 이슈가 조치 가능한 것인지, 어느 정도의 에스컬레이션이 필요한지 판단하는 데도 도움을 줄 수 있습니다.
개별 팀이 자신의 대표자에게 어떻게 책임을 지우는지 규정하는 것은 이 문서의 범위를 벗어나지만, 각 팀이 위의 메커니즘을 참고하여 자체 정책과 절차를 마련할 것을 권장합니다.
팀의 책임성 보장
팀들은 정기적으로 서로 조율하고 협력하며 각자의 필요에 대해 대화합니다. 일반적인 상황에서 위원회는 개별 팀의 자율성을 존중해야 합니다.
그러나 위원회는 팀들이 서로에게, 그리고 프로젝트 전체에 대해 공동으로 서로의 책임을 묻는 수단으로 기능합니다. 위원회는 다음을 할 수 있습니다.
- 다른 팀이나 프로젝트 전체의 고려 사항을 반영하지 못한 결정에 대해 팀에 재고를 요청합니다.
- 팀들이 다른 팀을 보다 정기적으로 고려하는 절차를 수립하도록 장려합니다.
- 팀들의 관할에 대한 공통된 이해를 보장합니다.
- 팀들이 그 관할을 수행할 의지와 능력을 갖추도록 보장합니다.
- 한 팀의 관할을 보다 관리하기 쉬운 단위로 나누는 새로운 팀을 설립합니다.
책임성 절차는 징벌적이어서는 안 되며, 해당 팀들과의 적극적인 협력 속에서 진행되어야 합니다.
팀이 더 넓은 프로젝트에 대해 고의로 선의에 따라 행동하지 않기를 선택하는 극단적인 상황에서, 위원회는 팀의 관할을 변경하거나, 팀 관할의 일부를 다른 팀으로 옮기거나, 팀을 완전히 없앨 권한을 가집니다. 이는 위원회의 일반적인 의사 결정 절차를 통해 이루어집니다. (이는 모더레이션 팀에는 적용되지 않습니다. 위원회와 모더레이션 팀 간의 책임성에 대해서는 다음 절을 참조하십시오.)
각주
-
이 문서 전체에서 “팀“은 하위 팀, 워킹 그룹, 프로젝트 그룹, 이니셔티브를 비롯하여 프로젝트 내의 모든 형태의 공식 협업 구조를 포함합니다. “하위 팀“은 어떤 팀을 거쳐 상위로 보고하는 모든 형태의 협업 구조를 포함합니다. ↩
-
여러 최상위 팀에 속하는 하위 팀이나 개인은 위원회에서 자신을 대변하는 대표자를 여러 명 둠으로써 불균형한 대표성을 가져서는 안 됩니다. 조직 내 어디에든 이와 같은 “다이아몬드” 구조가 존재하는 경우, 그 구조에 관련된 팀들은 모호함이나 책임 분산을 피하기 위해 노력해야 하며, 사람들과 팀들이 문제를 제기하고 피드백을 제공할 때 어떤 경로를 이용해야 하는지 알 수 있도록 해야 합니다. ↩
-
이는 사실상 위원회 대표의 수도 같은 범위로 제한합니다. 이 제한은 그 자체로도 중요하다는 점에 유의하십시오. ↩
-
위원회는 최상위 팀들이 파견한 대표로만 구성되며, 새로운 구성원을 임시로 직접 임명할 수 없습니다. 다만 위원회가 프로젝트에서 공백을 발견한 경우에는 새로운 최상위 팀을 만들 수 있습니다. 특히 위원회는 프로젝트가 현재 조율되고 체계화된 전문성을 갖추지 못했으며 위원회도 그 문제를 해결할 팀에 헌장을 부여할 적절한 해결 구조를 알지 못하는 문제에 대응하기 위해, 팀 창설의 발판을 마련할 수 있습니다. 그러한 경우 위원회는 해당 문제의 해결 공간을 탐색하고, 올바른 해결책을 결정하고, 제안과 헌장을 가지고 위원회에 돌아오는 것을 관할로 하는 팀을 구성할 수 있습니다. 그러면 그 팀은 위원회에 대표를 파견하며, 이 대표는 해당 문제와 해결책의 여러 측면에 관해 위원회와 협력할 수 있습니다. ↩
-
위원회 대표가 된다는 것은 궁극적으로 소속 팀과 프로젝트 전체에 봉사하는 자리입니다. 그 자리를 맡는 사람이 누구든 보람과 흥미를 느끼기를 바라지만, 동시에 그 자리가 차지하려고 다투는 지위로 여겨지지 않기를 바랍니다. ↩
-
실제로 인프라 팀 전체가 모든 자격 증명에 접근할 수 있는 것은 아니며, 팀 내부적으로 최소 권한 원칙을 지키려고 노력합니다. ↩
-
위원회는 이러한 역할을 위원회 대표에게만 맡겨야 하는 것은 아니며, 의향이 있는 프로젝트 구성원이라면 누구든 임명할 수 있습니다. 이러한 역할을 맡는다고 해서 의사 결정 등의 목적상 위원회 구성원이 되는 것은 아닙니다. ↩