숙련된 기여자인 경우, 작업에 광범위한 변경이 필요한 새 기여자와 쌍을 이루어 리뷰해 본다.
리뷰 과정
일반적으로, 영어로 콘텐츠와 스타일에 대한 풀 리퀘스트를 리뷰한다. 그림 1은 리뷰 과정의 단계를 보여 준다.각 단계에 대한 상세 사항은 아래에 나와 있다.
flowchart LR
subgraph fourth[리뷰 시작]
direction TB
S[ ] -.-
M[코멘트 작성] --> N[변경 사항 리뷰]
N --> O[새 기여자가 어떤 코멘트를 반영할지 선택해야 함]
end
subgraph third[PR 선택]
direction TB
T[ ] -.-
J[본문과 코멘트 확인]--> K[Netlify 미리보기 빌드로 변경 사항 미리보기]
end
A[열려 있는 PR 목록 확인]--> B[레이블을 이용하여 PR을 필터링]
B --> third --> fourth
classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
class A,B,J,K,M,N,O grey
class S,T spacewhite
class third,fourth white
cncf-cla: yes(권장): CLA에 서명하지 않은 기여자가 제출한 PR은 병합할 수 없다.자세한 내용은 CLA 서명을
참고한다.
language/en(권장): 영어 문서에 대한 PR 전용 필터이다.
size/<size>: 특정 크기의 PR을 필터링한다. 새로 시작하는 사람이라면, 더 작은 PR로 시작한다.
또한, PR이 진행 중인 작업으로 표시되지 않았는지 확인한다. work in progress 레이블을 사용하는 PR은 아직 리뷰할 준비가 되지 않은 PR이다.
리뷰할 PR을 선택한 후, 다음을 통해 변경 사항을 이해한다.
PR 설명을 통해 변경 사항을 이해하고, 연결된 이슈 읽기
다른 리뷰어의 의견 읽기
Files changed 탭을 클릭하여 변경된 파일과 행 보기
Conversation 탭의 맨 아래에 있는 PR의 빌드 확인 섹션으로 스크롤하여
Netlify 미리보기 빌드의 변경 사항을 확인.다음은 스크린샷이다(GitHub 데스크탑 사이트이며,태블릿 또는 스마트폰 장치에서 리뷰하는 경우 GitHub 웹 UI가 약간 다르다).미리보기를 열려면,체크 목록의 deploy/netlify 행의 Details 링크를 클릭한다.
Files changed 탭으로 이동하여 리뷰를 시작한다.
코멘트를 달려는 줄 옆에 있는 + 기호를 클릭한다.
행에 대한 의견을 작성하고 Add single comments(작성할 의견이 하나만 있는 경우)또는 Start a review(작성할 의견이 여러 개인 경우)를 클릭한다.
완료되면, 페이지 상단에서 Review changes 를 클릭한다. 여기에서
리뷰에 대한 요약을 추가한다(기여자에게 긍정적인 의견을 남겨주기 바란다!).항상 "Comment" 를 선택해야 한다
리뷰를 완료할 때, "Request changes" 버튼을 누르지 않는다.만약 몇몇 변경 사항들이 반영되기 전에 PR이 병합되는 것을 막고 싶다면,"/hold" 명령어를 사용한다.왜 "/hold"를 사용하는지 언급해줘야 하며, 어떤 경우에 홀드가 제거되는지에
대해서 명세해주는 것은 기여자에게 도움이 된다.
리뷰를 완료할 때, "Approve" 버튼을 누르지 않는다.대부분의 경우 "/approve" 명령어를 대신 사용한다.
리뷰 체크리스트
리뷰할 때, 다음을 시작점으로 사용한다.
언어와 문법
언어나 문법에 명백한 오류가 있는가? 무언가를 표현하는 더 좋은 방법이 있는가?
기여자가 변경한 부분의 언어와 문법에 집중한다.기여자가 문서 전체를 갱신하는 것을 목표로 하지 않는 한,해당 문서의 모든 이슈들을 해결할 의무는 없다.
PR이 기존의 문서를 갱신하는 경우, 갱신된 부분을 검토하는데 집중한다.변경된 내용이 기술적으로, 그리고 문서적으로 정확한지
검토한다.기여자가 해결하려는 문제와 직접적으로 관련 있지는 않은 문제들을 발견할 경우,개별적인 이슈로써 처리한다 (그 전에
해당 문제가 이슈화 되어있는지 확인한다).
문서의 경로를 이동 한 PR이 있는지 주의한다.기여자가 문서의 이름을 변경하거나 두개 이상의 문서들을 합치는 경우, 우리(쿠버네티스 SIG Docs)는
해당 기여자에게 이동된 문서에서 발견할 수 있는 모든 문법이나 철자 오류를 수정하도록 요청하는 것을 지양한다.
evergreen 게시물이 무엇인지와
어떤 기준으로 게시물이 evergreen인지 판단하는지에 대해서도 숙지해야 한다.
블로그 게시물에는 직접 인용과
간접 화법이 포함될 수 있다. 누군가에게 기인하거나
발생한 대화의 일부에 대해 다른 표현을 제안하는 것은 피한다. 원문 화자의
문법이 정확하지 않다고 생각하더라도 마찬가지이다. 이러한 경우에도 명백히 잘못된 경우가 아니면
작성자가 제안한 구두점을 존중한다.
프로젝트로서, 쿠버네티스 프로젝트가
무기한 유지 관리를 약속하는 경우에만 블로그 게시물을 유지 관리됨(evergreen: true 표시)으로 표시한다.일부 블로그 게시물은 반드시 유지 관리되어야 하며, 우리는 항상 릴리스 공지를 항상 evergreen으로 표시한다. 이 점을 어떻게 검토해야 할지 확실하지 않은 경우 다른 기여자에게 문의한다.
콘텐츠 가이드는 블로그 게시물과 이를 추가하는 PR에 무조건 적용된다. 가이드의 일부 제한 사항은 문서에만 적용되며, 블로그 게시물에는 적용되지 않는다는 점에 유의한다.
마크다운 소스가 올바른 페이지 콘텐츠 유형 및 / 또는 layout을 사용하고 있는지 확인한다.
기타
사소한 내용만을 가지고 기여하는 것에 주의한다.사소한 수정으로 간주할 수 있는 수정 요청을 발견한다면, 해당 정책을 알려주는 것이 바람직하다(실질적인 개선 사항이라면 수용 가능하다).
공백을 수정하는 기여자들로 하여금
PR의 첫번째 커밋에서 공백을 수정한 뒤 다른 변경 사항들을 추가하도록 권장한다. 이는
검토와 병합 과정을 더욱 쉽게 한다. 특히 대량으로 공백을 정리하는 하나의 커밋에서 발생하는
사소한 변경 사항들에 주의한다.(만약 이를 확인한 경우, 기여자에게 수정을 권장하도록 한다).
리뷰어로서, PR에서 공백 문제나 오타 등 크게 중요하지 않은 사소한 이슈들을 발견하는 경우,리뷰 앞에 nit:을 붙인다.이렇게 함으로써 기여자가 해당 피드백이 크게 중요하지 않다는 것을 알 수 있다.
nit 으로 표시된 피드백을 제외하고 모든 이슈들을 해결한 PR은 병합할 수 있다.이러한 경우, 아직 해결되지 않는 nit 사항들에 대하여 새롭게 이슈를 여는 것을 권장한다.또한 새로운 이슈를 Good First Issue로써
표시할 수 있는지에 대해 고려해본다. 가능한 경우, 이것은 새로운 기여자에게 좋은 소스가 된다.
