제안, 승인 및 안정화
rustdoc에 기여할 때는 실험이나 리팩터링을 진행할 허가를 얻기 위해서든, 기능을 안정화하기 위해서든 피드백과 승인을 받아야 하는 경우가 매우 흔합니다. 이 문서는 rustdoc 팀이 승인 결정을 내리는 데 사용하는 다양한 절차와 각 절차를 언제 사용해야 하는지를 요약하는 것을 목표로 합니다.
승인
팀이 제안을 승인하는 데 사용할 수 있는 메커니즘은 두 가지입니다(모든 승인 메커니즘이 모든 제안 방식에 적합한 것은 아니므로 아래를 참고하십시오):
- r+
- 제안(RFC 또는 FCP)은 병합이 승인되면 r+를 받습니다.
- r+는 PR을 승인하는 데에만 사용할 수 있습니다.
- FCP
- 최종 의견 수렴 기간을 통해 제안을 승인하려면 rustdoc 팀 과반수(전체 구성원 중 2명을 제외한 인원)의 서명이 필요하며, 그 후 10일의 대기 기간을 거칩니다.
- FCP는 모든 형태의 제안을 승인하는 데 사용할 수 있습니다.
제안
rustdoc 팀에 변경을 제안하는 방법은 세 가지입니다. 적절한 방법은 아래에 설명된 제안의 성격에 따라 달라집니다.
- rustdoc Zulip 스레드에서 논의를 시작하십시오.
- 이것이 권장되는 방법입니다. 이렇게 하면 결국 팀이 주요 변경을 요청하거나 아예 거절하는 경우에, 사용자가 무언가를 구현하느라 너무 많은 시간을 낭비하지 않도록 막을 수 있습니다. 논의 후 제안이 수락되면, 변경 사항에 따라 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를 작성해 달라는 요청과 함께 닫히거나 차단됨으로 표시되어야 합니다. 특정 기여에 대해 PR 승인만으로 충분하다면(아래 참조), 승인 절차를 시작할 수 있습니다.
승인을 받기 전에 실험적으로 코드 작업을 해도 됩니까?
물론입니다! 자유롭게 PR 작업을 하거나 코드를 작성하셔도 됩니다. 다만 그러한 PR은 실험적인 것으로 표시해야 하며, 병합되어서는 안 되고, 누군가 리뷰해 주리라 기대해서도 안 됩니다(원하는 사람이 있다면 예외입니다).
좋은 제안의 조건은 무엇입니까?
좋은 제안은 다음 사항을 다룹니다.