트리아지 절차
풀 리퀘스트 트리아지
상태 태그
-
S-waiting-on-author - 작성자가 리뷰어의 의견을 반영하도록 변경해야 하거나, 병합 충돌이나 테스트 실패가 있는 상태입니다. 이 태그는 PR이 다른 PR 때문에 막혀 있는 경우(보통 S-blocked 레이블도 함께 붙습니다)나 crater 실행을 기다리는 경우처럼 드문 경우도 포함합니다. 이런 경우에도 PR을 진행시킬 책임은 작성자에게 있습니다.
작업 중인 PR에도 사용하며, 이런 PR은 GitHub에서 초안(draft)으로 표시되기도 합니다.
-
S-waiting-on-review - 리뷰가 끝나지 않은 상태입니다.
-
S-waiting-on-t-lang - T-lang의 피드백을 기다리는 중입니다.
-
S-waiting-on-t-compiler - T-compiler의 피드백을 기다리는 중입니다.
-
S-waiting-on-t-libs - T-libs의 피드백을 기다리는 중입니다.
-
S-waiting-on-bors - 승인을 받았고 병합을 기다리는 중입니다. bors가 관리합니다.
-
S-waiting-on-crater - PR이 생태계에 미칠 영향을 확인하기 위해 기다리는 중입니다.
-
S-waiting-on-bikeshed - 사소한 세부 사항에 대한 합의를 기다리는 중입니다.
-
S-waiting-on-perf - perf 실행 결과를 기다리는 중입니다.
-
S-waiting-on-ACP - API 변경 제안(ACP)을 기다리는 중입니다.
-
S-blocked - 다른 PR이 병합되거나 논의가 결론 나기를 기다리는 중입니다.
-
S-inactive - 한동안 활동이 없는 상태입니다.
-
S-experimental - 트리아지하지 않아야 하는 실험적인 PR입니다. 예전에는 이 용도로 S-waiting-on-author를 사용했지만, S-experimental은 해당 PR이 일부 변경 사항을 시험해 보기 위한 실험임을 알려 줍니다.
또한 상태 태그가 없는 PR도 확인하십시오. 이 목록은 rustbot이 제대로 작동하지 않아 리뷰어를 지정하지 못했고, 그래서 S-waiting-on-review도 붙지 않은 PR을 찾을 때 유용합니다. 이 목록을 확인하지 않으면 이런 PR은 놓치기 쉽습니다. (r? @ghost가 있는 PR은 작성자가 아직 리뷰를 원하지 않는다는 뜻이므로 트리아지하지 않는 것이 좋습니다.)
절차
우리는 주로 세 가지 상태 레이블을 트리아지합니다. S-waiting-on-review, S-waiting-on-author, 그리고 가끔 S-blocked입니다. 각 레이블의 절차는 다음과 같습니다.
S-waiting-on-review
S-waiting-on-review 레이블이 붙은 모든 PR을 보려면 이 링크를 클릭하십시오. 마지막 업데이트 후 15일 이상(하루 정도 차이는 괜찮습니다) 지난 PR만 트리아지하십시오.
각 PR에 대해 다음을 수행하십시오.
-
PR에 새 충돌이 생겼거나, CI가 실패했거나, 새 리뷰가 달렸다면 레이블을 S-waiting-on-author로 바꾸고 작성자에게 핑을 보내십시오.
-
해당 PR을 보고서에 추가하십시오.
S-waiting-on-author
이 링크를 클릭하면 S-waiting-on-author 레이블이 붙은 모든 PR을 볼 수 있습니다. 마지막으로 업데이트된 지 15일 이상 지난 PR만 트리아지하십시오(하루 정도의 오차는 허용됩니다).
각 PR에 대해 다음을 수행하십시오.
-
PR이 작성자에게 기다리던 작업을 작성자가 완료했다면 레이블을 S-waiting-on-review로 변경하십시오.
그렇지 않고 작성자가 아직 해야 할 일이 남아 있다면, 작성자가 Rust 팀의 구성원이 아닌 경우에 작성자에게 핑을 보내십시오(워킹 그룹은 포함하지 않으며,
T-compiler,T-lang,T-rustdoc등과 같은 팀만 해당합니다). -
해당 PR을 보고서에 추가하십시오.
S-blocked
S-blocked PR은 가끔씩만(예: 한 달에 한 번) 확인하면 됩니다. 이 링크를 클릭하면 S-blocked 레이블이 붙은 모든 PR을 볼 수 있습니다.
각 PR에 대해 다음을 수행하십시오.
-
여전히 블록된 상태라면 그대로 두십시오.
그렇지 않고 더 이상 블록된 상태가 아니라면 S-blocked를 제거하십시오(적절한 경우 S-waiting-on-review와 같은 상태 레이블도 추가하십시오).
-
해당 PR을 보고서에 추가하십시오.
트리아지 보고서
트리아지한 각 PR에 관한 정보를 보고서에 기록해야 합니다. 보고서는 다음과 같은 형태의 간단한 문서일 뿐입니다.
S-waiting-on-review
#12345 20일 - 여전히 리뷰 대기 중 - 작성자: ferris, 담당자: bors
[…]
보고서의 형태는 달라도 되지만, 각 PR에 대해 다음 정보는 반드시 포함하십시오.
-
PR 번호(예:
#12345). 링크를 직접 추가할 필요는 없습니다. Rust Zulip이 PR(및 이슈) 번호에 자동으로 링크를 걸어 줍니다. -
마지막 활동 이후 경과한 일수. “활동“이란 다음을 의미합니다.
- 작성자, 리뷰어 또는 팀 구성원이 댓글을 달거나 리뷰한 경우, 또는
- bors가 병합 충돌에 관해 댓글을 단 경우, 또는
- PR에 푸시가 이루어진 경우,
- 기타 등등.
-
작성자, 리뷰어, 그리고 PR이 기다리고 있는 대상(사람, 팀, 다른 PR 등).
-
현재 상태와 가장 최근 활동의 내용(예: 병합 충돌, 리뷰어의 댓글).
PR 트리아지를 마쳤다면 #t-release/triage Zulip 스트림에 있는 이번 주 트리아지 토픽에 보고서를 게시하십시오. 토픽 이름은 YYYY-MM-DD to YYYY-MM-DD와 같은 형식이어야 합니다. 여기서 한 주는 월요일부터 일요일까지라는 점에 유의하십시오.
토픽이 없다면 다음 bash 한 줄 명령으로 토픽 제목을 생성할 수 있습니다(GNU date 필요).
echo "$(date -I --date="$([ "z$(date +%a)" = "zMon" ] && echo 'today' || echo 'last monday')") to $(date -I --date="$([ "z$(date +%a)" = "zSun" ] && echo 'today' || echo 'next sunday')")"
중복 작업 피하기
트리아지는 가장 오래된 이슈부터 살펴보는 방식으로 진행되기도 하므로, S-* 레이블 중 하나를 다시 적용하면 이슈/PR의 마지막 수정 시각이 갱신되어 다른 트리아지 담당자에게 이미 처리된 항목임을 알릴 수 있습니다.