제안, 승인 및 안정화
rustdoc에 기여할 때는 실험이나 리팩터링을 진행할 권한을 얻기 위해서든, 기능을 안정화할 때든 피드백과 승인을 모아야 하는 경우가 매우 흔합니다. 이 문서는 rustdoc 팀이 승인 결정을 내리기 위해 사용하는 다양한 절차와 각 절차를 언제 사용해야 하는지를 정리하는 것을 목표로 합니다.
승인
팀이 제안을 승인할 때 사용할 수 있는 메커니즘은 두 가지입니다(모든 승인 메커니즘이 각 제안 방식에 적합한 것은 아니므로 아래를 참고하십시오):
- r+
- 제안(RFC 또는 FCP)은 병합 승인이 되면 r+ 처리됩니다.
- r+는 PR을 승인하는 데에만 사용할 수 있습니다.
- FCP
- 최종 의견 수렴 기간에는 제안을 승인하기 위해 rustdoc 팀 과반수(전체 구성원 중 2명을 제외한 인원)의 서명이 필요하며, 그 후 10일의 대기 기간을 거칩니다.
- FCP는 모든 형태의 제안을 승인하는 데 사용할 수 있습니다.
제안
rustdoc 팀에 변경을 제안하는 방법에는 세 가지가 있습니다. 적절한 선택은 아래에서 설명하는 제안의 성격에 따라 달라집니다.
- rustdoc zulip thread에서 논의를 시작하십시오.
- 이것이 선호되는 방법입니다. 이 방법은 결국 팀이 대폭적인 변경을 요구하거나 심지어 거부할 경우, 사용자가 구현에 너무 많은 시간을 낭비하는 것을 방지할 수 있습니다. 논의 후 수용되면, 변경 사항에 따라 RFC 또는 PR이 다음 단계가 됩니다.
- 의견 요청(Request For Comments, RFC)
- RFC는
rust-lang/rfcs저장소에 대한 풀 리퀘스트이며, 중요한 변경 사항을 위해 예약된 무거운 제안 메커니즘입니다. - RFC 제안은 오직 FCP로만 승인할 수 있습니다.
- RFC는
- 풀 리퀘스트(PR)
rust-lang/rust저장소에 풀 리퀘스트를 여는 것은 대부분의 제안에 적합한 가벼운 방식입니다. 이 방식은 rustdoc 플래그의 안정화나 새 타깃 추가와 같은 경우에 선호됩니다.- PR 제안은 FCP 또는 *r+*로 승인할 수 있습니다. *r+*만으로 충분하지 않은 경우에는 아래의 FCP/RFC가 언제 필요한가? 절을 참고하십시오.
- 이슈
- 앞서 언급한 방법 중 어느 것이 가장 적합한지 모르겠다면,
rust-lang/rust저장소에 이슈를 여는 것도 좋은 출발점입니다.
- 앞서 언급한 방법 중 어느 것이 가장 적합한지 모르겠다면,
FCP/RFC가 언제 필요한가?
GUI 웹 인터페이스의 UI/UX 변경, 새로운 명령줄 인수, 새로운 속성 등과 같은 소규모 사용자 대상 변경의 안정화에는 FCP가 필요합니다. 하지만 변경 사항이 너무 크거나 중요하다고 판단되면, 변경이 받아들여지기 전에 RFC를 작성하고 승인받아야 합니다.
FCP를 시작할 때는 관심 없는 변경 사항에 대한 알림이 사람들에게 가지 않도록, 이슈/PR에 관련 하위 팀만 레이블로 지정되어 있는지 확인하십시오.
승인이 필요한 기여를 누군가가 승인 없이 진행하면 어떻게 됩니까?
기여에 필요한 승인이 RFC를 요구하는 경우, 해당 기여는 종료되거나 차단됨으로 표시되어야 하며, 먼저 RFC를 작성하도록 요청해야 합니다. 특정 기여에 대해 풀 리퀘스트 승인만으로 충분하다면(아래 참조), 승인 절차를 시작할 수 있습니다.
승인을 받기 전에 실험적으로 코드를 작업해도 됩니까?
물론입니다! 풀 리퀘스트를 작업하거나 코드를 작성하는 것은 자유입니다. 하지만 그러한 풀 리퀘스트는 실험적인 것으로 표시되어야 하며, 병합되어서는 안 되고, (사람들이 원하지 않는 한) 누구도 이를 검토할 의무가 없습니다.
좋은 제안이란 무엇입니까?
좋은 제안은 다음 사항을 다룹니다.