Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

리더십 위원회

이 문서는 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) 팀은 우산형 팀입니다. 즉, 직접적인 구성원은 없고 하위 팀 대표자만 있습니다.

위원회는 발사대의 각 하위 팀에 더 적합한 상위 팀을 찾거나 만들기 위해 노력해야 하며, 이후 해당 하위 팀들을 새로운 상위 팀으로 이동시켜야 합니다.

경우에 따라서는 적합한 상위 팀이 이미 존재하지만 아직 하위 팀을 받아들일 준비가 되어 있지 않을 수 있으며, 이런 경우 런칭 패드가 임시 거처 역할을 할 수 있습니다.

런칭 패드는 또한, 폐지되거나 재편된 팀의 하위 팀들이 그 폐지나 재편 과정에서 조직 내 다른 곳에 명시적으로 배치되지 않은 경우, 그 하위 팀들의 기본 거처 역할도 합니다.

위원회는 모든 하위 팀에 대해 새로운 상위 팀을 찾는 작업이 적절히 진행되고 있는지 확인하기 위해 6개월마다 발사대 내 하위 팀 구성을 검토해야 합니다. 다른 최상위 팀과 마찬가지로, 위원회가 더 이상 필요하지 않다고 판단하면 발사대 팀은 폐지될 수 있으며(위원회 내 대표권도 제거됩니다). 런칭 패드 팀을 폐지하는 절차는 다른 최상위 팀의 경우와 동일합니다. 또는 위원회는 발사대 팀에 자체 관할을 부여할 수도 있습니다.

최상위 팀 제거

팀의 최상위 지정을 제거하는(또는 그 외에 위원회 자격에 영향을 미치는) 결정은 제거 대상이 되는 최상위 팀의 대표자를 제외한 모든 위원회 대표자의 동의를 필요로 합니다. 이러한 예외 조항에도 불구하고, 검토 대상 팀의 대표자는 해당 팀의 제거에 관한 위원회 심의에 초대되어야 하며, 위원회는 극단적인 경우에만 해당 팀의 반대를 무릅쓰고 제거해야 합니다.

위원회는 모더레이션 팀을 제거할 수 없습니다. 위원회는 모더레이션 팀의 동의 없이 모더레이션 팀의 관할을 변경할 수 없습니다.

대체 대표 및 대표성 포기

대표는 가용성이나 상황 변화 등의 이유로 필요한 경우 임기를 조기에 종료할 수 있습니다. 이후 해당 최상위 팀은 새로운 대표자 선정을 시작해야 합니다. 대표 역할은 자원봉사직입니다. 누구도 그 역할을 맡을 의무는 없으며, 어떤 팀도 대표직 수행을 팀 구성원으로서의 필수 의무로 만들 수 없습니다. 하지만 대표는 대표직의 의무를 이행하거나, 그 직위에서 사임할 의무가 있습니다.

최상위 팀은 예를 들어 팀이 일시적으로 인력이 부족하고 대표를 맡으려는 사람이 없는 경우와 같이, 일시적으로 대표권을 포기하기로 결정할 수 있습니다. 다만 팀이 위원회 대표자를 지정하지 않으면, 프로젝트 전반의 의사 결정에 능동적으로 참여할 권리를 포기하는 것입니다. 의사 결정을 포함한 모든 위원회 절차는 이러한 누락으로 인해 막혀서는 안 됩니다. 위원회는 여전히 모든 프로젝트 구성원으로부터의 새로운 정보와 이의 제기를 고려할 의무가 있습니다. 다만 위원회는 대표가 없는 팀의 피드백을 특별히 고려하거나 취합하기 위해 결정을 막을 의무는 없습니다.

위원회에 대표자를 보내는 것은 최상위 팀의 의무로 간주되며, 이를 정기적으로 이행하지 못하는 것은 해당 팀이 의무를 다하지 못하고 있음을 의미합니다. 다만 위원회 대표자는 일시적인 질병, 휴가 등으로 인한 단기 부재의 경우에는 그 역할을 포기하지 않습니다.

최상위 팀은 주 대표자가 참석할 수 없는 경우를 대비하여 대리 대표자를 지정할 수 있습니다. 이 대리 대표자는 주 대표자가 복귀할 때까지 위원회 대표자의 역할을 온전히 맡습니다. 대체 대표는 주 대표가 참석할 때는 (참석자 수가 두 배가 되는 것을 피하기 위해) 정기적으로 회의에 참석하지 않습니다.

팀의 대표자와 모든 대리 대표자가 3주 연속으로 위원회 절차에 참여하지 못할 경우, 해당 팀이 참여 가능한 대표자를 제공할 수 있을 때까지 그 팀의 대표자는 위원회의 의사 결정 정족수 요건에 산입되지 않습니다. 위원회는 이것이 발효되기 전에 해당 팀에 이를 통지해야 합니다. 팀이 위원회가 자신들의 의견 없이 또는 자신들을 대신하여 이의를 제기할 수단 없이 결정을 내리지 않도록 하고자 한다면, 이용 가능한 대리 대표자를 반드시 확보해야 합니다.

최상위 팀은 필요한 경우 임기가 끝나기 전에 대표자를 교체할 수 있습니다. 하지만 연속성을 유지하는 데는 부담이 따르므로, 팀은 필요 이상으로 대표를 자주 교체하지 않도록 해야 합니다. 팀은 자신들이 지속적으로 다루고자 하는 팀 고유의 이슈나 입장에 대해 자신의 대표와 대체 대표에게 브리핑할 일차적인 책임이 있습니다. 위원회와 팀은 위원회 내 진행 중인 이슈에 대한 연속성을 유지하는 책임과, 대리 대표자 및 기타 신규 대표자에게 맥락을 제공하는 책임을 공유합니다.

비공개 사안의 경우, 위원회는 불필요하게 비공개 정보가 퍼지는 것을 막기 위해 대리 대표자에게 알리는 것을 신중하게 판단해야 하며, 대리 대표자가 대신 나서야 할 필요가 있을 경우 위원회는 그들에게 브리핑할 수 있습니다.

임기 제한

위원회 대표자의 임기는 1년입니다. 각 대표자는 특정 대표 위임(특정 최상위 팀으로부터의 위임)에 대해 연속 3개 완전 임기라는 소프트 한도를 가집니다. 대표자는 해당 팀으로부터 다른 팀 구성원을 대표자로 내세울 수 없다는 명시적 확인(예: 대체 가능한 후보가 없거나, 팀 구성원들이 다른 후보에 대해 막는 이의를 가지고 있는 경우)을 위원회가 받은 경우에 한해서만 이 소프트 한도를 초과할 수 있습니다.

이 외에는, 대표자가 다른 최상위 팀을 위해 봉사할 수 있는 임기 수나 하나의 최상위 팀에 대해 비연속적으로 봉사할 수 있는 임기 수에는 엄격한 한도가 없습니다. 팀은 경험의 연속성과 여러 사람에게 그러한 경험을 제공하기 위한 대표 순환 사이의 균형을 추구해야 합니다.6

대표자 임명의 절반은 3월 말에, 절반은 9월 말에 이루어집니다. 이는 모든 위원회 대표자가 동시에 교체되는 것을 방지합니다. 초기 위원회의 경우, 그리고 최상위 팀의 구성이 변경될 때마다, 위원회와 최상위 팀들은 임기 종료일이 3월과 9월 사이에 대략 균등하게 나뉘도록 함께 노력해야 합니다. 다만 각 임기는 최소 6개월은 지속되어야 합니다(지나치게 짧은 임기를 피하기 위해 일시적인 불균형은 허용됩니다).

위원회와 최상위 팀들이 적절한 임기 종료일 변경에 합의하지 못하는 경우, 균형을 유지하기 위해 대표자들은 (최소 6개월 이후의) 두 종료일 중 하나에 무작위로 배정됩니다.

단일 회사/단체 출신 대표자 수 제한

위원회 대표는 부적절함이나 부적절해 보이는 것을 피하기 위해 어느 한 회사, 법인, 또는 밀접하게 연관된 법인 집단에서 편중되어 나와서는 안 됩니다. 위원회의 대표가 5명 이하이면 동일한 소속을 가진 대표는 1명을 초과할 수 없으며, 위원회의 대표가 6명 이상이면 동일한 소속을 가진 대표는 2명을 초과할 수 없습니다.

밀접하게 연관된 법인에는 동일 법인의 지사/부문/자회사, 상당한 지분 관계로 연결된 법인 등이 포함됩니다. 위원회는 이례적인 경우에 판단을 내릴 수 있으며, 그러한 결정에서 이해 상충을 피하도록 유의해야 합니다.

위원회 대표는 어떤 회사나 다른 법인으로부터 소득의 상당 부분을 얻는 경우(고용주, 클라이언트, 또는 주요 후원자 등으로부터) 그 법인과 소속 관계에 있는 것입니다. 대표자는 소속 변경 사항을 신속히 공개해야 합니다.

대표가 소속을 변경하거나, 최상위 팀이 새 대표를 임명하거나, 위원회 규모가 변경되는 등의 이유로 이 제약이 성립하지 않게 되면, 다음과 같이 제약을 복원합니다:

  • 동일한 소속을 가진 대표자들은 먼저 스스로 이슈를 해결하고자 시도할 수 있으며, 이 경우 한 대표자가 자발적으로 물러나고 해당 팀이 다른 사람을 새로 임명합니다.
    • 이는 소속 법인이 아니라 대표자 본인의 결정이어야 하며, 소속 법인이 이 결정에 영향을 미치는 것은 부적절한 것으로 간주됩니다.
    • 이러한 논의에서 대표들은 동등한 지위를 가지며, 프로젝트나 위원회 내 연차와 같은 요소를 사람들에게 압력을 가하는 데 사용해서는 안 됩니다.
  • 해당 소속을 가진 대표자들이 합의에 이르지 못하면, 그중 한 명이 무작위로 제외됩니다. (이 제약이 여전히 충족되지 않으면, 남은 대표자들이 다시 한 번 스스로 이슈를 해결하고자 시도한 후 이 과정을 반복할 수 있습니다.) 이는 최적이 아닌 결과를 낳을 가능성이 높으므로, 일반적으로 자발적인 해결책이 더 바람직합니다.
  • 팀은 즉시 후임자 선정 절차를 시작해야 하지만, 팀의 기존 대표자는 남은 임기 중 최대 3개월까지 계속 재직할 수 있습니다.
  • 기존 대표자는 신임 대표자와 전환을 조율해야 하지만, 최대 3개월의 기간 동안 누가 실제 대표자가 될지는 해당 팀의 선택입니다. 최상위 팀에서 나오는 대표는 항상 단 한 명뿐입니다.

후보자 기준

다음은 이상적인 후보자를 결정하기 위한 기준입니다. 이는 효과적인 팀 리드나 공동 리드의 기준과 유사하지만 동일하지는 않습니다. 팀 리드가 위원회 대표로서도 좋은 자질을 가질 수는 있지만, 팀 리드 역할과 위원회 대표 역할은 모두 상당한 시간 투자를 필요로 하므로, 이는 그 역할들을 서로 다른 사람들에게 나누어 맡기는 동기가 될 가능성이 높습니다. 이 기준은 엄격한 요건이 아니라 누가 팀의 대표자로 가장 적합한 위치에 있는지 판단하는 데 사용할 수 있습니다. 요컨대 대표자는 다음을 갖추어야 합니다:

  • 위원회의 필요에 할애할 충분한 시간과 에너지.
  • 프로젝트 운영 및 프로젝트 거버넌스 주제를 돕는 데 대한 관심.
  • 자신의 팀이나 활발히 기여하는 영역을 벗어난 프로젝트의 필요에 대한 폭넓은 인식.
  • 자신의 팀이 무엇을 필요로 하는지에 대한 예리한 감각.
  • 개인적인 의도보다 타인의 필요를 대변하고 중심에 두는 기질과 능력.
  • 자기 팀의 일부 견해나 자신이 동의하는 견해만이 아니라 모든 관점을 대변할 능력과 의지.

일부 팀은 현재 이 기준에 맞는 후보가 풍부하지 않을 수 있지만, 위원회는 더 큰 프로젝트 내에서 이러한 역량을 적극적으로 육성해야 합니다. 이는 위원회 구성원 자격뿐 아니라 프로젝트 전체에 걸쳐 도움이 되기 때문입니다.

자격 증명

위원회는 프로젝트의 관리 자격 증명에 대한 특권적 접근 권한을 갖지 않습니다. 이 접근 권한은 오직 인프라 팀에만 있습니다7. 인프라 팀의 책임에는 우리 인프라의 보안과 유지보수성 사이에서 균형을 유지하면서, 팀들이 효과적으로 작업을 수행하는 데 필요한 도구와 접근 권한을 갖추도록 보장하는 것이 포함됩니다. 위원회는 정책을 통해 어떤 팀이 접근 권한을 가져야 하는지 조율하는 데 도움을 줄 수 있습니다.

Rust 재단과의 관계

위원회는 프로젝트 이사(Project directors)를 선임하는 절차를 수립할 책임이 있습니다. 프로젝트 이사는 Rust 프로젝트의 이해관계가 Rust 재단 이사회에 반영되도록 하는 메커니즘입니다.

위원회는 재단 이사회에서 프로젝트의 이해관계를 대변하고 재단 관련 사안에 관해 특정 결정을 내리는 관할을 프로젝트 이사에게 위임합니다. 그 관할의 정확한 경계는 아직 명시되지 않았습니다.

위원회의 의사결정 절차

위원회는 운영 결정과 정책 결정이라는 두 가지 유형의 결정을 내립니다. 특정 고려사항은 결정의 분류에 따라 해당 결정에 적용될 수 있습니다. 그러나 기본적으로 위원회는 분류와 관계없이 모든 결정에 대해 합의(consent) 의사결정 절차를 사용합니다.

운영 결정 대 정책 결정

운영 결정은 위원회가 목표를 수행하기 위해 일상적으로 내리는 결정으로, (수립된 정책에 근거하여) 회의 밖에서 이루어지는 정기적인 조치도 포함됩니다. 정책 결정은 운영을 틀 짓고, 안내하며, 지원하기 위한 일반적이고 재사용 가능한 패턴이나 프레임워크를 제공합니다. 특히, 정책 결정은 운영 결정이나 운영의 다른 측면에 대한 부분적인 자동화를 제공할 수 있습니다. 위원회는 달리 명시되지 않는 한 모든 결정에 대해 기본적으로 합의 의사결정 절차를 사용합니다.

어떤 결정이 운영에 해당하고 어떤 결정이 정책에 해당하는지는 정확히 정의되어 있지 않으며, 오히려 하나의 연속선상 어딘가에 위치합니다. 이 구분의 목적은 위원회의 의사결정 절차를 지시하거나 제약하는 데 있지 않습니다. 대신, 이 구분은 위원회에 지침을 제공하며, 위원회가 시간이 지남에 따라 자신의 결정을 어떻게 기록·검토·개선하고자 하는지를 명확히 합니다. 운영/정책 분류와 관련된 요건이나 지침의 목적상, 본 정책이나 향후 정책에서 운영 또는 정책 어느 쪽으로도 명시되지 않은 것은 기본적으로 정책으로 간주됩니다.

반복과 예외

정책 결정은 그렇지 않으면 반복적인 운영 결정이 필요했을 사안을 체계적으로 다루는 경우가 많습니다. 위원회는 반복되는 운영 결정이 정책 결정이나 정책 변경의 필요성을 나타내는 시점을 인식하도록 노력해야 합니다. 특히, 위원회는 반복되는 운영 결정이 사실상의 정책으로 굳어지도록 방치하는 것을 피해야 합니다.

기존 정책에 대한 예외는, 해당 정책에서 명시적으로 그러한 예외를 허용하지 않는 한 운영 결정을 통해 만들어질 수 없습니다. 임의적인 예외를 피하는 것은 “일탈의 정상화”를 방지하는 데 도움이 됩니다.

동의 의사결정 절차

합의(consent)란 어떤 대표의 요구사항도(그리고 따라서 그가 대표하는 최상위 팀과 하위 팀의 요구사항도) 무시될 수 없음을 의미합니다. 위원회는 모든 관련 의견을 청취하며, 모든 목소리가 동등하게 반영되어 함께 공평하게 일할 수 있는 좋은 토대를 마련합니다.

위원회는 “동의합니까?“라고 묻는 대신 “반대합니까?“라고 묻는 합의 의사결정 방식을 사용합니다. 이는 제안을 충분히 검토했음에도 이유에 대한 명확한 피드백 없이 승인하지 않기로 결정하는 “숨겨진 거부권(pocket veto)“을 없애줍니다. 우려사항, 피드백, 선호사항 등 상대적으로 덜 중요한 형태의 피드백은 의사결정을 막지 않지만, 초안 작성과 논의의 더 이른 단계에서 반영을 고려해야 합니다. 충족되지 않은 요구사항이나 필요를 나타내는 이의는 결정을 진행하기 위해 반드시 고려되고 해결되어야 합니다.

승인 기준

동의 의사결정 프로세스에는 다음과 같은 승인 기준이 있습니다.

  • 위원회가 지정한 소통 공간(회의 또는 특정 채널) 중 한 곳에 제안을 게시합니다.
  • 위원회 대표자 중 최소 N-2명(N은 전체 위원회 대표자 수)이 최종 제안을 완전히 검토하고 동의를 표했다는 확인을 받은 경우.
  • 어떤 위원회 대표자로부터도 미해결 상태의 명시적 반대가 없는 경우.
  • 피드백을 위해 최소 10일을 제공하는 것입니다.

승인 기준은 정족수 메커니즘과 함께 대표자들이 제안을 확인할 충분한 시간을 제공합니다. 두 명의 미승인을 허용하는 것은 이 프로젝트의 자원봉사적 성격을 인정하는 것으로, 동의와 무이의에 필요한 확인의 양과 의사결정 속도의 균형을 맞춘 경험에 기반합니다. 이는 해당 대표자들이 이의를 제기하고자 했다면 그럴 시간이 있었다는 것을 전제로 합니다. (이는 오늘날 RFC 승인에 사용되는 프로세스를 본떠 만든 것입니다.)

의사결정 프로세스는 제안을 제기한 대표자가 자신의 제안을 철회하기로 결정하면 언제든지 종료될 수 있습니다. 다른 대표자는 언제든지 제안을 인수하여 이를 계속 유지할 수 있습니다.

이해상충으로 인해 위원회가 결정에 필요한 N-2 정족수를 충족하지 못하는 경우, 위원회는 이해상충이 기록된 상태로 결정을 진행하는 방법에 관한 “이해상충” 섹션에 문서화된 절차를 따르지 않는 한 해당 결정을 내릴 수 없습니다. 이러한 경우 위원회는 유사한 이해상충이 향후 재발하지 않도록 적절한 절차와 정책을 검토해야 합니다.

의사결정 프로세스의 수정 및 조정

공개 정책 절차를 사용하여 위원회는 결정 유형별로 서로 다른 의사결정 절차를 수립할 수 있습니다.

특정 유형의 결정에 어떤 의사결정 절차를 채택할지 결정할 때, 위원회는 신속한 결정의 필요성과 완전한 합의에 대한 확신의 중요성 사이에서 균형을 맞춥니다. 동의 의사결정 프로세스는 다음과 같은 스펙트럼에 걸쳐 있습니다.

  • 만장일치 의사결정(신속한 의사결정을 희생하고 완전한 합의에 대한 확신을 우선시함): 팀 구성원은 반드시 검토하고 제안을 다른 모든 것보다 선호해야 하며, 어떤 팀 구성원이든 저지 이의를 제기할 수 있음
  • 동의 의사결정(위원회의 기본값이며, 신속한 결정과 합의에 대한 확신 사이에서 균형을 이룹니다): 팀 구성원들이 검토해야 하며 저지 반대를 제기할 수 있습니다
  • 1인 승인 및 무반대(합의에 대한 확신을 희생하여 신속한 의사결정을 우선시합니다): 팀 구성원 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 거버넌스 전체가 어떻게 발전할지에 관한 구체적인 방안이 포함되어야 합니다.

위원회 대표자의 책무성 보장

위원회 대표자는 자신이 대표자로서의 임무를 얼마나 잘 이행하고 있는지 되돌아보기 위해, 서로 간에 그리고 각자의 최상위 팀과(그 구체적인 성격은 이 문서의 범위를 벗어남) 정기적인 피드백에 참여해야 합니다. 피드백 세션의 목표는 대표자들이 프로젝트를 더 잘 섬길 수 있는 방법을 더 잘 이해하도록 돕는 것입니다. 이 피드백은 모든 대표자, 해당 대표자의 최상위 팀의 모든 구성원, 그리고 모더레이션 팀과 공유되어야 합니다. 이 피드백은 대표자들이 잘한 점과 더 잘할 수 있었던 점을 모두 물어야 합니다.

별도로, 대표자는 언제든지 자신의 팀 및 동료 대표자로부터의 비공개 피드백에 열려 있어야 하며, 위원회에서의 자신의 역할과 효과성에 대해 정기적으로 자기 성찰을 해야 합니다.

안전하고 열린 과정을 보장하기 위해, 이러한 피드백 과정의 결과물은 절대 공개되어서는 안 됩니다. 위원회는 또한 결과가 긍정적인 변화로 이어지지 않을 경우 피드백 절차를 되돌아보고 조정해야 합니다.

위원회의 다른 구성원이 어떤 위원회 대표자가 위원회의 나머지 구성원들과 잘 협업하지 못하고 있다고 느낄 경우, 그들은 해당 대표자와, 필요하다면 그 대표자의 팀과도 대화해야 합니다. 위원회 대표자는 그러한 대화를 원활히 하기 위해 필요에 따라 모더레이션/중재 자원을 끌어와야 합니다. 모더레이션(중재)은 해당 이슈를 해결하는 데 도움을 줄 수 있으며, 그 이슈가 조치 가능한지, 그리고 어느 정도의 에스컬레이션을 필요로 하는지 판단할 수 있습니다.

개별 팀이 어떻게 자신의 대표자에게 책임을 묻는지 명시하는 것은 이 문서의 범위를 벗어나지만, 우리는 팀들이 위의 메커니즘을 자신들의 정책과 절차를 위한 영감으로 활용할 것을 권장합니다.

팀의 책임성 보장

팀들은 정기적으로 서로 조율하고 협력하며 자신들의 필요에 관해 대화를 나누고 있으며, 정상적인 상황에서 위원회는 개별 팀의 자율성을 존중해야 합니다.

그러나 위원회는 팀들이 서로에 대해, 그리고 프로젝트 전체에 대해 공동으로 책무성을 지도록 하는 수단으로 기능합니다. 위원회가 할 수 있는 일은 다음과 같습니다:

  • 다른 팀이나 프로젝트 전체의 고려사항을 반영하지 못한 결정을 재고하도록 팀에 요청합니다.
  • 팀들이 다른 팀을 더 정기적으로 고려하는 프로세스를 수립하도록 장려합니다.
  • 팀들의 관할 범위에 대한 공통된 이해를 보장합니다.
  • 팀들이 해당 관할 범위를 이행할 의지와 능력이 있는지 확인합니다.
  • 팀의 관할을 더 관리하기 쉬운 단위로 나누는 새로운 팀을 설립하는 것.

책임성 절차는 징벌적이어서는 안 되며, 해당 절차는 관련 팀들의 적극적인 협력 하에 진행되어야 합니다.

팀들이 더 넓은 프로젝트에 대해 선의로 행동하지 않기로 고의로 선택하는 극단적인 상황에서는, 위원회가 팀의 관할을 변경하거나, 팀 관할의 일부를 다른 팀으로 옮기거나, 팀을 완전히 없앨 권한을 가집니다. 이는 위원회의 일반적인 의사결정 절차를 통해 이루어집니다. (이는 모더레이션 팀에는 적용되지 않습니다. 위원회와 모더레이션 팀 간의 책무성에 관해서는 다음 절을 참고하십시오.)

각주

  1. 여기서 ’권한’이라는 용어는 Rust 프로젝트의 성공을 보장하기 위해 위원회가 지니는 권능과 책임을 가리킵니다. 이 문서는 이러한 권능의 한계를 명시하여, 위원회가 자신이 지닌 권한을 프로젝트의 사안을 책임지는 팀들에게 위임하도록 합니다. 이러한 관심사에는 제품 비전, 일상적인 절차, 엔지니어링 결정, 멘토링, 마케팅 등이 포함될 수 있으나 이에 국한되지는 않습니다. ↩

  2. 이 문서 전체에서 “팀“은 하위 팀, 워킹 그룹, 프로젝트 그룹, 이니셔티브, 그리고 프로젝트 내의 모든 다른 형태의 공식 협업 구조를 포함합니다. “하위 팀“은 어느 팀을 통해 보고되는 모든 형태의 협업 구조를 포함합니다. ↩

  3. 여러 최상위 팀에 속하는 하위 팀이나 개인들은 위원회에서 그들을 대변하는 여러 명의 대표자를 두어 불균형한 대표성을 얻어서는 안 됩니다. 조직 내 어디에서든 이러한 “다이아몬드” 구조가 존재할 때마다, 그 구조에 관련된 팀들은 모호함이나 책임의 분산을 피하기 위해 노력해야 하며, 사람들과 팀들이 문제를 제기하고 피드백을 제공하기 위해 어떤 경로를 사용해야 하는지 알도록 보장해야 합니다. ↩

  4. 이는 또한 위원회 대표자의 수를 사실상 동일한 범위로 제한하는 효과를 가집니다. 이 제약 사항은 그 자체로도 중요하다는 점에 유의하십시오. ↩

  5. 위원회는 오직 최상위 팀들이 제공하는 대표자로만 구성되며, 스스로에게 새로운 임시 구성원을 임명할 수 없습니다. 그러나 위원회가 프로젝트 내의 공백을 발견할 경우, 새로운 최상위 팀을 만들 수 있습니다. 특히 위원회는 프로젝트가 현재 조율되거나 조직된 전문성을 갖추지 못한 문제, 그리고 위원회가 그 문제를 해결할 팀에 헌장을 부여할 올바른 해결 구조를 알지 못하는 문제를 다루기 위해 팀 창설을 부트스트랩할 수 있습니다. 그런 경우, 위원회는 그 문제의 해결 공간을 탐색하고 올바른 해결책을 결정한 뒤 위원회에 제안 및 헌장을 가지고 돌아오는 것을 관할로 하는 팀을 모을 수 있습니다. 그 팀은 이후 위원회에 대표자를 제공하며, 그 대표자는 해당 문제와 해결책의 측면들에 관해 위원회와 협력할 수 있습니다. ↩

  6. 위원회 대표자가 된다는 것은 궁극적으로 각 팀과 프로젝트 전체에 대한 봉사의 자리입니다. 우리는 이 자리를 맡는 사람이 누구든 그것이 보람 있고 몰입할 수 있는 자리이기를 바라는 한편, 그것이 다투어 쟁취해야 할 지위의 자리로 여겨지지 않기를 바랍니다. ↩

  7. 실무상 인프라 팀 전체가 모든 자격 증명에 접근할 수 있는 것은 아니며, 내부적으로 최소 권한 원칙을 충족하고자 노력합니다. ↩

  8. 위원회는 그러한 역할을 반드시 위원회 대표자에게만 배정해야 하는 것은 아니며, 위원회는 기꺼이 나서는 어떤 프로젝트 구성원이든 임명할 수 있습니다. 그러한 역할은 의사결정과 같은 목적에 있어 위원회의 구성원 자격을 구성하지 않습니다. ↩