멤버십

이 절에서는 rustdoc 팀의 구성원 자격에 대해 다룹니다.

멤버십에 이르는 길

rustdoc 도구에 기여하고자 하는 사람들은 일반적으로 버그 수정이나 새로운 기능 구현으로 시작합니다. 안내나 도움이 필요하시면 Zulip의 t-rustdoc 채널에서 주저하지 말고 물어보십시오!

Rustdoc 구성원

개인이 일정 기간 동안 꾸준히 기여해 온 경우, rustdoc 팀 구성원으로 승격될 수 있습니다(아래 의사 결정 방식 절 참고).

이러한 승격이 적절한 정확한 조건을 정의하기는 어렵습니다. 멤버로 승격되는 것은 단순히 여러 항목을 체크하는 것으로 결정되지 않습니다. 하지만 일반적으로 다음 세 가지를 입증했을 때 준비가 되었다고 여겨집니다.

• “지속력” – 해당 인물은 어떤 형태로든 정기적으로 기여하고 있어야 합니다. 예를 들어 이는 몇 가지 프로젝트를 완료했음을 의미할 수 있습니다.
• “독립성과 친숙함” – 작업을 맡을 때 최소한 자신의 “rustdoc 영역” 범위 내에서는 어느 정도 독립적으로 행동해야 합니다. 또한 간단한 PR에 대해서는 다른 사람을 멘토링할 수 있을 정도가 되어야 합니다.
• “우호성” – rustdoc 팀 구성원은 Rust 조직의 일원이 되며 행동 강령과 관련하여 더 높은 기준을 적용받습니다. 이들은 CoC의 문구뿐 아니라 그 정신도 준수해야 합니다.

멤버로 승격되면 여러 권한이 따라옵니다.

• 멤버는 r+(풀 리퀘스트 승인) 권한을 가지며 리뷰를 수행할 수 있습니다(앞서 논의한 대로 이러한 권한을 적절히 사용할 것이 요구됩니다). 또한 perf/rustc-timer 및 기타 유사한 봇을 제어할 수 있는 권한도 갖습니다. bors와 r+에 대한 문서는 여기를 참고하십시오.

  팁: bors 권한과 관련된 몇 가지 기본 규칙은 다음과 같습니다. 먼저 악성 코드 여부를 확인하지 않았다면 try 빌드를 하지 마십시오. 그리고 해당 코드를 효과적으로 리뷰할 수 있다고 합리적으로 확신하지 못한다면 r+를 하지 마십시오.

• rustdoc 팀 구성원은 Rust 조직의 구성원이므로 레이블을 수정하고 이슈에 배정될 수 있습니다.

• 멤버는 GitHub의 rust-lang/rustdoc 팀에 속하게 되어, 사람들이 팀 전체에 연락하고자 할 때 핑을 받게 됩니다.

• 구성원은 [rust-lang.org 웹 페이지]에 나열되어 있습니다.

여기에는 일부 의무(경우에 따라 선택적 의무)도 따라옵니다.

• 멤버는 FCP에 최대 4주(28일) 이내에 응답할 것이 요구됩니다.
• 멤버는 팀을 돕기 위한 다양한 다른 메인테이너 활동에 참여할 수 있습니다.
• 구성원은 행동 강령과 관련하여 일반인보다 더 높은 기준을 적용받습니다.

rustdoc 구성원이 된다는 것의 의미

rustdoc 팀의 구성원이 되면 여러 가지 일이 일어납니다:

• 내부 논의가 이루어지는 비공개 Zulip 스트림에 접근할 수 있게 됩니다.
• 여러분은 all@rust-lang.org와 rustdoc@rust-lang.org 메일링 리스트에도 구독됩니다. 메일링 리스트 구독이 어떻게 동작하는지 확인하려면 이 파일을 참고하십시오. 둘 다 발송량이 매우 적은 메일링 리스트입니다(연간 몇 통 정도). all@rust-lang.org에 관해서는, 모든 기여자에게 소식을 전하기 위한 방법입니다. 이 주소로부터 스팸을 보내는 일은 없을 것입니다.

rustdoc 팀 내의 역할

Rustdoc에는 여러 개의 서로 다른 영역이 있으며 팀 구성원 모두가 그 모든 영역에서 작업하는 것은 아닙니다. 현재 세 가지 주요 영역이 있습니다:

• 프론트엔드: 검색, 프론트엔드 기능, 프론트엔드 설정을 포함하여 HTML/CSS/JS 및 (HTML) UI/UX 변경과 관련된 모든 것입니다.
• JSON 백엔드: rustdoc-json-types 크레이트를 포함하여 --output-format=json 백엔드 작업입니다.
• 내부: rustdoc의 내부, 즉 컴파일러와의 상호작용, doctest, rustdoc 내부 코드 표현 생성, 명령줄 인자 파싱, lint, intra-doc 링크 등입니다.

이 그룹들은 완전한 팀이 아니며, 따라서 이 그룹들 중 어느 곳이든 속하려면 rustdoc 팀의 구성원이어야 합니다.

현재는 프론트엔드 그룹만이 팀 저장소에서 공식적인 지위를 가지고 있으며 rustdoc-frontend라고 불립니다. rustdoc 팀 구성원이 이 그룹에 참여하는 데 관심이 있다면 추가해 달라고 요청할 수 있습니다.

rustdoc 역할은 자신의 영역에만 영향을 미치는 경우 자체적으로 FCP와 RFC를 처리하며, 그렇지 않은 경우에는 필요에 따라 다른 역할이나 다른 팀까지 절차에 추가됩니다.

프론트엔드 그룹을 예로 들어봅시다. 이는 rustdoc 팀의 일부이므로, 이 그룹에 합류하려면 rustdoc 팀의 구성원이어야 합니다. 프론트엔드 그룹에 속한다는 것은 프론트엔드 풀 리퀘스트에 대한 리뷰 순환에 참여하도록 권장되며, 프론트엔드 FCP와 RFC에 응답해야 함을 의미합니다.

승진 결정이 이루어지는 방식

개인이 rustdoc에 얼마간 기여해 온 후에는 기존 팀 구성원에 의해 비공개 Zulip rustdoc 팀 채널에서 지명될 수 있습니다. 모든 지명은 비공개 Zulip rustdoc 팀 채널에서 이루어져야 합니다.

rustdoc 팀 구성원들은 해당 개인에게 구성원 초대를 확대하는 데 우려가 있는지 확인하며, 10일 후(이의가 없는 경우) 초대가 발송됩니다.

초대가 해당 개인에 의해 수락되면, rustdoc 팀 리드는 새로운 역할을 반영하도록 team 저장소를 업데이트합니다.

전임 구성원 상태

rustdoc 팀 구성원이 언제든 참여를 잠시 쉬고 싶다면, 스스로 전임 구성원 상태로 전환할 수 있습니다. 전임 구성원 상태가 되면 GitHub 별칭 등에서 제외되어, 핑이나 메시지로 방해받을 필요가 없어집니다. 또한 r+ 권한도 갖지 않게 됩니다. 다만 전임 구성원은 여전히 GitHub 조직 전체의 구성원으로 남습니다.

전임 구성원 상태에 있는 사람은 언제든지 “활성” 상태로 복귀를 요청할 수 있습니다. 이 요청은 특별한 사정이 없는 한 통상적으로 자동 승인됩니다.

전임 구성원 상태에 있는 사람은 이전에 도달했던 수준의 팀 구성원으로 여전히 남아 있으며, 이를 공개적으로 밝힐 수 있으나, 활동했던 기간도 함께 명시해야 합니다.

6개월간 비활동 시 자동 전임 구성원 상태 전환

구성원 또는 메인테이너가 rustdoc에서 6개월간 비활동 상태였다면, 전임 구성원 상태로 전환됩니다.