SIG Docs는 모든 컨트리뷰터의 콘텐츠와 리뷰를 환영한다.
누구나 풀 리퀘스트(PR)를 요청할 수 있고,
누구나 콘텐츠에 대해 이슈를 등록하거나 진행 중인 풀 리퀘스트에 코멘트를 등록할 수 있다.
멤버,
리뷰어, 또는
승인자가 될 수 있다.
이런 역할은 변경을 승인하고 커밋할 수 있도록 보다 많은 접근 권한과 이에 상응하는 책임이 수반된다.
쿠버네티스 커뮤니티 내에서 멤버십이 운영되는 방식에 대한 보다 많은 정보를 확인하려면
커뮤니티 멤버십
문서를 확인한다.
문서의 나머지에서는 대외적으로 쿠버네티스를 가장 잘 드러내는 수단 중 하나인 쿠버네티스 웹사이트와
문서를 관리하는 책임을 가지는 SIG Docs에서,
이런 체계가 작동하는 특유의 방식에 대한 윤곽을 잡아보겠다.
SIG Docs 의장
SIG Docs를 포함한 각 SIG는, 한 명 이상의 SIG 멤버가 의장 역할을 하도록 선정한다. 이들은 SIG Docs와
다른 쿠버네티스 조직 간 연락책(point of contact)이 된다. 이들은 쿠버네티스 프로젝트 전반의 조직과
그 안에서 SIG Docs가 어떻게 운영되는지에 대한 폭넓은 지식을 갖추어야한다.
현재 의장의 목록을 확인하려면
리더십
문서를 참조한다.
SIG Docs 팀과 자동화
SIG Docs의 자동화는 다음의 두 가지 메커니즘에 의존한다.
GitHub 팀과 OWNERS 파일이다.
GitHub 팀
GitHub의 SIG Docs [팀]에는 두 분류가 있다.
승인자와 리더를 위한 @sig-docs-{language}-owners
리뷰어를 위한 @sig-docs-{language}-reviewers
그룹의 전원과 의사소통하기 위해서
각각 GitHub 코멘트에서 그룹의 @name으로 참조할 수 있다.
가끔은 Prow와 GitHub 팀은 정확히 일치하지 않고 중복된다.
이슈, 풀 리퀘스트를 할당하고, PR 승인을 지원하기 위해서
자동화 시스템이 OWNERS 파일의 정보를 활용한다.
OWNERS 파일과 전문(front-matter)
쿠버네티스 프로젝트는 GitHub 이슈와 풀 리퀘스트 자동화와 관련해서 prow라고 부르는 자동화 툴을 사용한다.
쿠버네티스 웹사이트 리포지터리는
다음의 두개의 prow 플러그인을
사용한다.
blunderbuss
approve
이 두 플러그인은 kubernetes/website GitHub 리포지터리 최상위 수준에 있는
OWNERS와
OWNERS_ALIASES
파일을 사용해서
해당 리포지터리에 대해 prow가 작동하는 방식을 제어한다.
OWNERS 파일은 SIG Docs 리뷰어와 승인자의 목록을 포함한다. OWNERS 파일은 하위 디렉터리에 있을 수
있고, 해당 하위 디렉터리와 그 이하의 파일에 대해 리뷰어와 승인자 역할을 수행할 사람을 새로 지정할 수 있다.
일반적인 OWNERS 파일에 대한 보다 많은 정보는
OWNERS
문서를 참고한다.
추가로, 개별 마크다운(Markdown) 파일 내 전문에
리뷰어와 승인자를 개별 GitHub 사용자 이름이나 GitHub 그룹으로 열거할 수 있다.
OWNERS 파일과 마크다운 파일 내 전문의 조합은
자동화 시스템이 누구에게 기술적, 편집적 리뷰를 요청해야 할지를
PR 소유자에게 조언하는데 활용된다.
병합 작업 방식
풀 리퀘스트 요청이 콘텐츠를 발행하는데 사용하는
브랜치에 병합되면, 해당 콘텐츠는 https://kubernetes.io 에 공개된다. 게시된 콘텐츠의
품질을 높히기 위해 SIG Docs 승인자가 풀 리퀘스트를 병합하는 것을 제한한다.
작동 방식은 다음과 같다.
풀 리퀘스트에 lgtm 과 approve 레이블이 있고, hold 레이블이 없고,
모든 테스트를 통과하면 풀 리퀘스트는 자동으로 병합된다.
쿠버네티스 조직의 멤버와 SIG Docs 승인자들은 지정된 풀 리퀘스트의
자동 병합을 방지하기 위해 코멘트를 추가할 수 있다(코멘트에 /hold 추가 또는
/lgtm 코멘트 보류).
모든 쿠버네티스 멤버는 코멘트에 /lgtm 을 추가해서 lgtm 레이블을 추가할 수 있다.
SIG Docs 승인자들만이 코멘트에 /approve 를
추가해서 풀 리퀘스트를 병합할 수 있다. 일부 승인자들은
PR Wrangler 또는 SIG Docs 의장과
같은 특정 역할도 수행한다.
퀵윈(Quick Wins): 명확한 결격 사유가 없는 메인 브랜치에 대한 PR을 나열한다. ([XS, S, M, L, XL, XXL] 크기의 PR을 작업할 때 크기 레이블에서 "XS"를 변경한다)
메인 브랜치이외의 브랜치에 대한 PR: dev- 브랜치에 대한 것일 경우, 곧 출시될 예정인 릴리스이다. /assign @<meister's_github-username> 을 사용하여 문서 릴리스 관리자를 할당한다. 오래된 브랜치에 대한 PR인 경우, PR 작성자가 가장 적합한 브랜치를 대상으로 하고 있는지 여부를 파악할 수 있도록 도와준다.
랭글러를 위한 유용한 Prow 명령어
# 한글 레이블 추가
/language ko
# 둘 이상의 커밋인 경우 PR에 스쿼시 레이블 추가
/label tide/merge-method-squash
# Prow를 통해 PR 제목 변경(예: 진행 중인 작업(work-in-progress) [WIP] 또는 PR의 더 상세한 내용)
/retitle [WIP] <TITLE>
풀 리퀘스트를 종료하는 시기
리뷰와 승인은 PR 대기열을 최신 상태로 유지하는 도구 중 하나이다. 또 다른 도구는 종료(closure)이다.
다음의 상황에서 PR을 닫는다.
작성자가 CLA에 2주 동안 서명하지 않았다.
작성자는 CLA에 서명한 후 PR을 다시 열 수 있다. 이는 어떤 것도 CLA 서명없이 병합되지 않게 하는 위험이 적은 방법이다.
작성자가 2주 이상 동안 코멘트나 피드백에 응답하지 않았다.
풀 리퀘스트를 닫는 것을 두려워하지 말자. 기여자는 진행 중인 작업을 쉽게 다시 열고 다시 시작할 수 있다. 종종 종료 통지는 작성자가 기여를 재개하고 끝내도록 자극하는 것이다.
풀 리퀘스트를 닫으려면, PR에 /close 코멘트를 남긴다.
참고:fejta-bot이라는 봇은 90일 동안 활동이 없으면 이슈를 오래된 것(stale)으로 표시한다. 30일이 더 지나면 rotten으로 표시하고 종료한다. PR 랭글러는 14-30일 동안 활동이 없으면 이슈를 닫아야 한다.