승인자와 리뷰어의 리뷰

SIG Docs 리뷰어와 승인자는 변경 사항을 리뷰할 때 몇 가지 추가 작업을 수행한다.

매주 특정 문서 승인자 역할의 지원자가 풀 리퀘스트를 심사하고 리뷰한다. 이 사람은 일주일 동안 "PR 랭글러(Wrangler)"이다. 자세한 정보는 PR 랭글러 스케줄러를 참고한다. PR 랭글러가 되려면, 매주 SIG Docs 회의에 참석하고 자원한다. 이번 주에 해당 일정이 없는 경우에도, 아직 리뷰 중이 아닌 풀 리퀘스트(PR)를 여전히 리뷰할 수 있다.

로테이션 외에도, 봇은 영향을 받는 파일의 소유자를 기반으로 PR에 대한 리뷰어와 승인자를 할당한다.

PR 리뷰

쿠버네티스의 문서는 쿠버네티스의 코드 리뷰 프로세스를 따른다.

풀 리퀘스트 리뷰에 설명된 모든 내용이 적용되지만, 리뷰어와 승인자도 다음을 수행해야 한다.

• /assign Prow 명령을 사용하여 필요에 따라 특정 리뷰어를 PR에 할당한다. 이는 코드 기여자에게 기술 리뷰를 요청할 때 특히 중요하다.

  참고:

  마크다운 파일 상단의 헤더에 있는 reviewers 필드를 보고 기술 리뷰를 제공할 수 있는 사람을 확인한다.

• PR이 콘텐츠와 스타일 가이드를 따르는 지 확인한다. 그렇지 않은 경우 가이드의 관련 부분에 작성자를 연결한다.

• 적용이 가능한 경우 GitHub Request Changes 옵션을 사용하여 PR 작성자에게 변경을 제안한다.

• 제안한 사항이 구현된 경우, /approve 또는 /lgtm Prow 명령을 사용하여 GitHub에서 리뷰 상태를 변경한다.

다른 사람의 PR에 커밋

PR 코멘트를 남기는 것이 도움이 되지만, 대신 다른 사람의 PR에 커밋을 해야 하는 경우가 있다.

다른 사람이 명시적으로 요청하거나, 오랫동안 중단된 PR을 재개하려는 경우가 아니라면 다른 사람에게서 "가져오지" 않는다. 단기적으로는 작업이 빠를 수 있지만, 그 사람이 기여할 기회를 박탈하게 된다.

사용할 프로세스는 이미 PR의 범위에 있는 파일을 편집해야 하는지, 또는 PR이 아직 다루지 않은 파일을 편집해야 하는지에 따라 다르다.

다음 중 하나에 해당하면 다른 사람의 PR에 커밋할 수 없다.

• PR 작성자가 브랜치를 https://github.com/kubernetes/website/ 리포지터리로 직접 푸시한 경우, 푸시 접근 권한이 있는 리뷰어만 다른 사용자의 PR에 커밋할 수 있다.

  참고:

  다음 번부터는 작성자가 자신의 포크에 브랜치를 푸시하도록 권장한다.

• PR 작성자가 승인자의 수정을 명시적으로 허용하지 않는다.

리뷰를 위한 Prow 명령

Prow는 풀 리퀘스트 (PR)에 대한 작업을 실행하는 쿠버네티스 기반 CI/CD 시스템이다. Prow는 챗봇 스타일 명령으로 쿠버네티스 조직 전체에서 레이블 추가와 제거, 이슈 종료 및 승인자 할당과 같은 GitHub 작업을 처리할 수 있다. /<command-name> 형식을 사용하여 Prow 명령을 GitHub 코멘트로 입력한다.

리뷰어와 승인자가 사용하는 가장 일반적인 Prow 명령은 다음과 같다.

PR에서 사용할 수 있는 명령어들을 보려면 Prow 명령 레퍼런스를 참고한다.

이슈 심사와 분류

일반적으로, SIG Docs는 쿠버네티스 이슈 심사 프로세스를 따르며 동일한 레이블을 사용한다.

이 GitHub 이슈 필터는 심사가 필요한 이슈를 찾는다.

이슈 심사

1. 이슈 확인

• 이슈가 website 문서에 관한 것인지 확인한다. 질문에 답하거나 리소스에 리포터를 지정하면 일부 이슈를 신속하게 종결할 수 있다. 자세한 내용은 지원 요청 또는 코드 버그 리포트 섹션을 참고한다.
• 이슈가 가치가 있는지 평가한다.
• 이슈의 내용에 실행할 수 있는 세부 사항이 충분하지 않거나 템플릿의 내용이 제대로 작성되지 않은 경우 triage/needs-information 레이블을 추가한다.
• lifecycle/stale 과 triage/needs-information 레이블이 모두 있으면 이슈를 닫는다.

2. 우선순위 레이블을 추가한다( 이슈 심사 가이드라인은 우선순위 레이블을 자세히 정의함).

재량에 따라, 이슈의 소유권을 가져와서 PR을 제출한다 (특히, 이미 수행 중인 작업과 관련이 있거나 빠르다면).

이슈 심사에 대해 질문이 있다면, 슬랙의 #sig-docs 채널이나 kubernetes-sig-docs 메일링리스트에 문의한다.

이슈 레이블 추가와 제거

레이블을 추가하려면, 다음의 형식 중 하나로 코멘트를 남긴다.

• /<label-to-add> (예: /good-first-issue)
• /<label-category> <label-to-add> (예: /triage needs-information 또는 /language ko)

레이블을 제거하려면, 다음의 형식 중 하나로 코멘트를 남긴다.

• /remove-<label-to-remove> (예: /remove-help)
• /remove-<label-category> <label-to-remove> (예: /remove-triage needs-information)

두 경우 모두, 사용하려는 레이블은 이미 존재하는 레이블이어야 한다. 존재하지 않는 레이블을 추가하려고 하면, 명령이 자동으로 무시된다.

모든 레이블 목록에 대해서는 website 리포지터리의 레이블 섹션을 참고한다. SIG Docs에서 모든 레이블을 사용하는 것은 아니다.

이슈의 lifecycle 레이블

이슈는 일반적으로 신속하게 열리고 닫힌다. 그러나, 가끔씩은 이슈가 열린 후 비활성 상태로 있다. 어떤 경우에는 이슈가 90일 이상 열려 있을 수도 있다.

특별한 이슈 유형의 처리

SIG Docs가 처리 방법을 문서화할 정도로 다음과 같은 유형의 이슈를 자주 경험하게 된다.

중복된 이슈

단일 문제에 대해 하나 이상의 이슈가 열려 있으면, 이를 단일 이슈로 합친다. 열린 상태를 유지할 이슈를 결정한 다음(또는 새로운 이슈를 열어야 함), 모든 관련 정보로 이동하여 관련 이슈를 연결해야 한다. 마지막으로, 동일한 문제를 설명하는 다른 모든 이슈에 triage/duplicate 레이블을 지정하고 닫는다. 하나의 이슈만 해결하는 것으로 혼동을 줄이고 같은 문제에 대한 중복 작업을 피할 수 있다.

깨진 링크 이슈

깨진 링크 이슈가 API 문서나 kubectl 문서에 있는 경우, 문제가 완전히 이해될 때까지 /priority critical-urgent 레이블을 할당한다. 다른 모든 깨진 링크 이슈는 수동으로 수정해야하므로, /priority important-longterm 를 할당한다.

블로그 이슈

쿠버네티스 블로그 항목은 시간이 지남에 따라 구식이 될 것으로 예상한다. 따라서, 1년 미만의 블로그 항목만 유지 관리한다. 1년이 지난 블로그 항목과 관련된 이슈일 경우, 수정하지 않고 이슈를 닫는다.

PR을 마감할 때 보내는 메시지에 기사 업데이트와 유지 관리 링크를 포함할 수 있다.

관련된 이유가 있는 경우 예외를 두는 것은 괜찮다.

지원 요청 또는 코드 버그 리포트

문서에 대한 일부 이슈는 실제로 기본 코드와 관련된 이슈이거나, 튜토리얼과 같은 무언가가 작동하지 않을 때 도움을 요청하는 것이다. 문서와 관련이 없는 이슈의 경우, triage/support 레이블과 함께 요청자에게 지원받을 수 있는 곳(슬랙, Stack Overflow)을 알려주며 이슈를 닫고, 기능 관련 버그에 대한 이슈인 경우, 관련 리포지터리를 코멘트로 남긴다(kubernetes/kubernetes 는 시작하기 좋은 곳이다).

지원 요청에 대한 샘플 응답은 다음과 같다.

이 이슈는 지원 요청과 비슷하지만
문서 관련 이슈와는 관련이 없는 것 같습니다.
[쿠버네티스 슬랙](https://slack.k8s.io/)의
`#kubernetes-users` 채널에서 질문을 하시기 바랍니다. 또한,
[Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes)와
같은 리소스를 검색하여 유사한 질문에 대한 답변을
얻을 수도 있다.

https://github.com/kubernetes/kubernetes 에서
쿠버네티스 기능 관련 이슈를 열 수도 있다.

문서에 대한 이슈인 경우 이 이슈를 다시 여십시오.

샘플 코드 버그 리포트 응답은 다음과 같다.

이 이슈는 문서에 대한 이슈보다 코드에 대한 이슈와
비슷합니다. https://github.com/kubernetes/kubernetes/issues 에서
이슈를 여십시오.

문서에 대한 이슈인 경우 이 이슈를 다시 여십시오.

스쿼시

승인자로서 풀 리퀘스트(PR)를 검토할 때 다음과 같은 다양한 경우가 있다.

• 기여자에게 커밋을 스쿼시하도록 안내한다.
• 기여자를 대신하여 커밋을 스쿼시한다.
• 기여자에게 아직 스쿼시하지 않도록 안내한다.
• 스쿼시를 방지한다.

기여자의 스쿼시 안내: 신규 기여자는 풀 리퀘스트(PR)에서 커밋을 스쿼시해야 한다는 사실을 모를 수 있다. 만약 그렇다면, 스쿼시를 하도록 안내하고, 유용한 정보 링크를 제공하고, 필요시 도움을 받을 수 있도록 제안한다. 유용한 링크는 다음과 같다.

• 문서 기여자를 위한 풀 리퀘스트 열기 및 커밋 스쿼시하기.
• 개발자를 위한 다이어그램을 포함한 GitHub 워크플로.

기여자를 위한 커밋 스쿼시: 기여자가 커밋 스쿼시에 어려움을 겪거나 PR을 병합할 시간적 압박이 있는 경우, 기여자를 대신하여 스쿼시를 수행할 수 있다.

• kubernetes/website 저장소는 풀 리퀘스트 병합을 위한 스쿼시를 허용하도록 구성되어 있다. 단지 커밋 스쿼시 버튼을 선택하면 된다.
• PR에서 기여자가 메인테이너 PR을 관리할 수 있도록 허용하는 경우, 기여자의 커밋을 스쿼시하고 해당 포크를 결과로 업데이트할 수 있다. 스쿼시하기 전에 기여자에게 최신 변경 사항을 저장하고 PR에 푸시하도록 안내한다. 스쿼시한 후에는 스쿼시된 커밋을 로컬 복제본으로 가져오도록 안내한다.
• GitHub에서 커밋을 스쿼시하도록 하려면 레이블을 사용하여 Tide / GitHub가 스쿼시를 수행하거나 PR을 병합할 때 커밋 스쿼시 버튼을 클릭한다.

기여자에게는 스쿼시를 하지 않도록 안내

• 한 커밋에서 문제가 발생하거나 잘못된 작업이 발생하고 마지막 커밋에서 이 오류를 되돌리는 경우, 커밋을 스쿼시하지 않는다. GitHub의 PR과 Netlify 미리보기의 "파일 변경됨" 탭은 모두 정상적으로 보이지만, 이 PR을 병합하면 다른 사람들에게 리베이스 또는 병합 충돌이 발생할 수 있다. 다른 기여자에게 이러한 위험을 방지하기 위해 필요에 따라 개입한다.

절대 스쿼시하지 않는다

• 현지화 또는 새 버전의 문서를 릴리스하는 경우, 사용자 포크가 아닌 브랜치에서 병합하는 경우, 절대 커밋을 스쿼시하지 않는다. 해당 파일의 커밋 히스토리를 유지해야 하므로 스쿼시하지 않는 것이 중요하다.