트리아지 절차
풀 리퀘스트 트리아지
상태 태그
-
S-waiting-on-author - 작성자가 리뷰어 의견을 반영하기 위해 변경을 가해야 하거나, 병합 충돌·테스트 실패가 존재하는 상태입니다. 이는 PR이 다른 PR에 의해 막혀 있는 경우(보통 S-blocked 레이블이 함께 붙습니다)나 crater 실행을 기다리는 경우 등 더 모호한 사례도 포함합니다 – PR을 진전시키는 것은 작성자의 책임입니다.
진행 중인(work-in-progress) 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의 마지막 수정 타임스탬프가 갱신되어 다른 트리아지 담당자에게 이미 처리되었음을 알려줍니다.