whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Eighth Korean l10n work for release 1.18

Browse Source 
- Translate tasks/administer-cluster/declare-network-policy in Korean (#22526)
- Translate tasks/debug-application-cluster/debug-init-containers in Korean (#22608)
- Fix a missing markdown syntax to enable external link (#22661)
- Translate tasks/administer-cluster/change-pv-reclaim-policy in Korean (#22551)
- Update docs/contribute/participate/ for Korean (#22605)
- Update outdated files in dev-1.18-ko.8 (#22466)
- Translate tasks/administer-cluster/dns-custom-nameservers in Korean (#22524)

Co-authored-by: Daehyun Paik <paik@a30a.dev>
Co-authored-by: Jerry Park <jaehwa@gmail.com>
Co-authored-by: bluefriday <bluefriday86@gmail.com>
Co-authored-by: June Yi <june.yi@samsung.com>
Co-authored-by: Jesang Myung <jesang.myung@gmail.com>
Co-authored-by: Seokho Son <shsongist@gmail.com>
This commit is contained in:
bluefriday
2020-07-15 10:59:52 +09:00
committed by June Yi
parent 6bf2feba74
commit fe296af187
46 changed files with 1454 additions and 654 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/contribute/_index.md
+1 -2
View File
@@ -3,6 +3,7 @@ content_type: concept
title: 쿠버네티스 문서에 기여하기
linktitle: 기여
main_menu: true
no_list: true
weight: 80
card:
name: contribute
@@ -23,8 +24,6 @@ card:
쿠버네티스 문서는 새롭고 경험이 풍부한 모든 기여자의 개선을 환영합니다!
<!-- body -->
## 시작하기
content/ko/docs/contribute/advanced.md
-63
View File
@@ -17,67 +17,6 @@ weight: 98
<!-- body -->
## 일주일 동안 PR 랭글러(Wrangler) 되기
SIG Docs [승인자](/ko/docs/contribute/participating/#승인자)는 리포지터리에 대해 1주일 정도씩 [PR을 조정(wrangling)](https://github.com/kubernetes/website/wiki/PR-Wranglers)하는 역할을 맡는다.
PR 랭글러의 임무는 다음과 같다.
- [스타일](/docs/contribute/style/style-guide/)과 [콘텐츠](/docs/contribute/style/content-guide/) 가이드를 준수하는지에 대해 [열린(open) 풀 리퀘스트](https://github.com/kubernetes/website/pulls)를 매일 리뷰한다.
- 가장 작은 PR(`size/XS`)을 먼저 리뷰한 다음, 가장 큰(`size/XXL`) PR까지 옮겨가며 리뷰를 반복한다.
- 가능한 한 많은 PR을 리뷰한다.
- 각 기여자가 CLA에 서명했는지 확인한다.
- 새로운 기여자가 [CLA](https://github.com/kubernetes/community/blob/master/CLA.md)에 서명하도록 도와준다.
- CLA에 서명하지 않은 기여자에게 CLA에 서명하도록 자동으로 알리려면 [이](https://github.com/zparnold/k8s-docs-pr-botherer) 스크립트를 사용한다.
- 제안된 변경 사항에 대한 피드백을 제공하고 다른 SIG의 멤버로부터의 기술 리뷰가 잘 진행되게 조율한다.
- 제안된 콘텐츠 변경에 대해 PR에 인라인 제안(inline suggestion)을 제공한다.
- 내용을 확인해야 하는 경우, PR에 코멘트를 달고 자세한 내용을 요청한다.
- 관련 `sig/` 레이블을 할당한다.
- 필요한 경우, 파일의 머리말(front matter)에 있는 `reviewers:` 블록의 리뷰어를 할당한다.
- PR의 리뷰 상태를 표시하기 위해 `Docs Review` 와 `Tech Review` 레이블을 할당한다.
- 아직 리뷰되지 않은 PR에 `Needs Doc Review` 나 `Needs Tech Review` 를 할당한다.
- 리뷰가 진행되었고, 병합하기 전에 추가 입력이나 조치가 필요한 PR에 `Doc Review: Open Issues` 나 `Tech Review: Open Issues` 를 할당한다.
- 병합할 수 있는 PR에 `/lgtm` 과 `/approve` 를 할당한다.
- PR이 준비가 되면 병합하거나, 수락해서는 안되는 PR을 닫는다.
- 콘텐츠가 문서의 [스타일 가이드라인](/docs/contribute/style/style-guide/) 중 일부만 충족하더라도 정확한 기술 콘텐츠를 수락하는 것이 좋다. 스타일 문제를 해결하기 위해 `good first issue` 라는 레이블로 새로운 이슈를 연다.
- 새로운 이슈를 매일 심사하고 태그를 지정한다. SIG Docs가 메타데이터를 사용하는 방법에 대한 지침은 [이슈 심사 및 분류](/ko/docs/contribute/review/for-approvers/#이슈-심사와-분류)를 참고한다.
## 랭글러에게 유용한 GitHub 쿼리
다음의 쿼리는 랭글러에게 도움이 된다. 이 쿼리들을 수행하여 작업한 후에는, 리뷰할 나머지 PR 목록은
일반적으로 작다. 이 쿼리들은 특히 현지화 PR을 제외하고, `master` 브랜치만 포함한다(마지막 쿼리는 제외).
- [CLA 서명 없음, 병합할 수 없음](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge+label%3Alanguage%2Fen):
CLA에 서명하도록 기여자에게 상기시킨다. 봇과 사람이 이미 알렸다면, PR을 닫고
CLA에 서명한 후 PR을 열 수 있음을 알린다.
**작성자가 CLA에 서명하지 않은 PR은 리뷰하지 않는다!**
- [LGTM 필요](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-label%3Algtm+):
기술 리뷰가 필요한 경우, 봇이 제안한 리뷰어 중 한 명을 지정한다. 문서 리뷰나
교정이 필요한 경우, 변경 사항을 제안하거나 교정하는 커밋을 PR에 추가하여 진행한다.
- [LGTM 보유, 문서 승인 필요](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+label%3Algtm):
PR을 병합하기 위해 추가 변경이나 업데이트가 필요한지 여부를 결정한다. PR을 병합할 준비가 되었다고 생각되면, `/approve` 코멘트를 남긴다.
- [퀵윈(Quick Wins)](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22+): 명확한 결격 사유가 없는 master에 대한 작은 PR인 경우. ([XS, S, M, L, XL, XXL] 크기의 PR을 작업할 때 크기 레이블에서 "XS"를 변경한다)
- [master 이외의 브랜치에 대한 PR](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-base%3Amaster): `dev-` 브랜치에 대한 것일 경우, 곧 출시될 예정인 릴리스이다. `/assign @<meister's_github-username>` 을 코멘트로 추가하여 [릴리스 마이스터](https://github.com/kubernetes/sig-release/tree/master/release-team)가 그것에 대해 알고 있는지 확인한다. 오래된 브랜치에 대한 PR인 경우, PR 작성자가 가장 적합한 브랜치를 대상으로 하고 있는지 여부를 파악할 수 있도록 도와준다.
### 풀 리퀘스트를 종료하는 시기
리뷰와 승인은 PR 대기열을 최신 상태로 유지하는 도구 중 하나이다. 또 다른 도구는 종료(closure)이다.
- CLA가 2주 동안 서명되지 않은 모든 PR을 닫는다.
PR 작성자는 CLA에 서명한 후 PR을 다시 열 수 있으므로, 이는 어떤 것도 CLA 서명없이 병합되지 않게 하는 위험이 적은 방법이다.
- 작성자가 2주 이상 동안 코멘트나 피드백에 응답하지 않은 모든 PR을 닫는다.
풀 리퀘스트를 닫는 것을 두려워하지 말자. 기여자는 진행 중인 작업을 쉽게 다시 열고 다시 시작할 수 있다. 종종 종료 통지는 작성자가 기여를 재개하고 끝내도록 자극하는 것이다.
풀 리퀘스트를 닫으려면, PR에 `/close` 코멘트를 남긴다.
{{< note >}}
[`fejta-bot`](https://github.com/fejta-bot)이라는 자동화 서비스는 90일 동안 활동이 없으면 자동으로 이슈를 오래된 것으로 표시한 다음, 그 상태에서 추가로 30일 동안 활동이 없으면 종료한다. PR 랭글러는 14-30일 동안 활동이 없으면 이슈를 닫아야 한다.
{{< /note >}}
## 개선 제안
SIG Docs [멤버](/ko/docs/contribute/participating/#멤버)는 개선을 제안할 수 있다.
@@ -245,5 +184,3 @@ SIG Docs [승인자](/ko/docs/contribute/participating/#승인자)는 SIG Docs
녹화를 중지하려면, Stop을 클릭한다.
비디오가 자동으로 유튜브에 업로드된다.
content/ko/docs/contribute/new-content/open-a-pr.md
+17 -7
View File
@@ -97,10 +97,12 @@ git에 익숙하거나, 변경 사항이 몇 줄보다 클 경우,
### 로컬 클론 생성 및 업스트림 설정
3. 터미널 창에서, 포크를 클론한다.
3. 터미널 창에서, 포크를 클론하고 [Docsy Hugo 테마](https://github.com/google/docsy#readme)를 업데이트한다.
```bash
git clone git@github.com/<github_username>/website
cd website
git submodule update --init --recursive --depth 1
```
4. 새 `website` 디렉터리로 이동한다. `kubernetes/website` 리포지터리를 `upstream` 원격으로 설정한다.
@@ -263,18 +265,26 @@ website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할
또는, 컴퓨터에 `hugo` 명령을 설치하여 사용한다.
5. [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/master/netlify.toml)에 지정된 [Hugo](https://gohugo.io/getting-started/installing/) 버전을 설치한다.
1. [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/master/netlify.toml)에 지정된 [Hugo](https://gohugo.io/getting-started/installing/) 버전을 설치한다.
6. 터미널에서, 쿠버네티스 website 리포지터리로 이동하여 Hugo 서버를 시작한다.
2. website 리포지터리를 업데이트하지 않았다면, `website/themes/docsy` 디렉터리가 비어 있다.
테마의 로컬 복제본이 없으면 사이트를 빌드할 수 없다. website 테마를 업데이트하려면, 다음을 실행한다.
```bash
git submodule update --init --recursive --depth 1
```
3. 터미널에서, 쿠버네티스 website 리포지터리로 이동하여 Hugo 서버를 시작한다.
```bash
cd <path_to_your_repo>/website
hugo server
hugo server --buildFuture
```
7. 브라우저의 주소 표시줄에 `https://localhost:1313` 을 입력한다.
4. 웹 브라우저에서 `https://localhost:1313` 으로 이동한다. Hugo는
변경 사항을 보고 필요에 따라 사이트를 다시 구축한다.
8. 로컬의 Hugo 인스턴스를 중지하려면, 터미널로 돌아가서 `Ctrl+C` 를 입력하거나,
5. 로컬의 Hugo 인스턴스를 중지하려면, 터미널로 돌아가서 `Ctrl+C` 를 입력하거나,
    터미널 창을 닫는다.
{{% /tab %}}
@@ -498,4 +508,4 @@ PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을
## {{% heading "whatsnext" %}}
- 리뷰 프로세스에 대한 자세한 내용은 [리뷰하기](/ko/docs/contribute/reviewing/revewing-prs)를 읽어본다.
- 리뷰 프로세스에 대한 자세한 내용은 [리뷰하기](/ko/docs/contribute/review/reviewing-prs)를 읽어본다.
content/ko/docs/contribute/participate/_index.md
+120
View File
@@ -0,0 +1,120 @@
---
title: SIG Docs에 참여하기
content_type: concept
weight: 60
card:
name: contribute
weight: 60
---
<!-- overview -->
SIG Docs는 쿠버네티스 프로젝트의
[분과회(special interest group)](https://github.com/kubernetes/community/blob/master/sig-list.md)
중 하나로, 쿠버네티스 전반에 대한 문서를 작성하고, 업데이트하며 유지보수하는 일을 주로 수행한다.
분과회에 대한 보다 자세한 정보는
[커뮤니티 GitHub 저장소 내 SIG Docs](https://github.com/kubernetes/community/tree/master/sig-docs)
를 참조한다.
SIG Docs는 모든 컨트리뷰터의 콘텐츠와 리뷰를 환영한다.
누구나 풀 리퀘스트(PR)를 요청할 수 있고,
누구나 콘텐츠에 대해 이슈를 등록하거나 진행 중인 풀 리퀘스트에 코멘트를 등록할 수 있다.
[멤버](/ko/docs/contribute/participating/roles-and-responsibilities/#멤버), [리뷰어](/ko/docs/contribute/participating/roles-and-responsibilities/#리뷰어), 또는 [승인자](/ko/docs/contribute/participating/roles-and-responsibilities/#승인자)가 될 수 있다.
이런 역할은 변경을 승인하고 커밋할 수 있도록 보다 많은 접근 권한과 이에 상응하는 책임이 수반된다.
쿠버네티스 커뮤니티 내에서 멤버십이 운영되는 방식에 대한 보다 많은 정보를 확인하려면
[커뮤니티 멤버십](https://github.com/kubernetes/community/blob/master/community-membership.md)
문서를 확인한다.
문서의 나머지에서는 대외적으로 쿠버네티스를 가장 잘 드러내는 수단 중 하나인 쿠버네티스 웹사이트와
문서를 관리하는 책임을 가지는 SIG Docs에서,
이런 체계가 작동하는 특유의 방식에 대한 윤곽을 잡아보겠다.
<!-- body -->
## SIG Docs 의장
SIG Docs를 포함한 각 SIG는, 한 명 이상의 SIG 멤버가 의장 역할을 하도록 선정한다. 이들은 SIG Docs와
다른 쿠버네티스 조직 간 연락책(point of contact)이 된다. 이들은 쿠버네티스 프로젝트 전반의 조직과
그 안에서 SIG Docs가 어떻게 운영되는지에 대한 폭넓은 지식을 갖추어야한다.
현재 의장의 목록을 확인하려면
[리더십](https://github.com/kubernetes/community/tree/master/sig-docs#leadership)
문서를 참조한다.
## 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라고 부르는 자동화 툴을 사용한다.
[쿠버네티스 웹사이트 리포지터리](https://github.com/kubernetes/website)는
다음의 두개의 [prow 플러그인](https://github.com/kubernetes/test-infra/tree/master/prow/plugins)을
사용한다.
- blunderbuss
- approve
이 두 플러그인은 `kubernetes/website` GitHub 리포지터리 최상위 수준에 있는
[OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS)와
[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES)
파일을 사용해서
해당 리포지터리에 대해 prow가 작동하는 방식을 제어한다.
OWNERS 파일은 SIG Docs 리뷰어와 승인자의 목록을 포함한다. OWNERS 파일은 하위 디렉터리에 있을 수
있고, 해당 하위 디렉터리와 그 이하의 파일에 대해 리뷰어와 승인자 역할을 수행할 사람을 새로 지정할 수 있다.
일반적인 OWNERS 파일에 대한 보다 많은 정보는
[OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md)
문서를 참고한다.
추가로, 개별 마크다운(Markdown) 파일 내 전문에
리뷰어와 승인자를 개별 GitHub 사용자 이름이나 GitHub 그룹으로 열거할 수 있다.
OWNERS 파일과 마크다운 파일 내 전문의 조합은
자동화 시스템이 누구에게 기술적, 편집적 리뷰를 요청해야 할지를
PR 소유자에게 조언하는데 활용된다.
## 병합 작업 방식
풀 리퀘스트 요청이 콘텐츠를 발행하는데 사용하는
브랜치에 병합되면, 해당 콘텐츠는 http://kubernetes.io 에 공개된다. 게시된 콘텐츠의
품질을 높히기 위해 SIG Docs 승인자가 풀 리퀘스트를 병합하는 것을 제한한다.
작동 방식은 다음과 같다.
- 풀 리퀘스트에 `lgtm` 과 `approve` 레이블이 있고, `hold` 레이블이 없고,
모든 테스트를 통과하면 풀 리퀘스트는 자동으로 병합된다.
- 쿠버네티스 조직의 멤버와 SIG Docs 승인자들은 지정된 풀 리퀘스트의
자동 병합을 방지하기 위해 코멘트를 추가할 수 있다(코멘트에 `/hold` 추가 또는
`/lgtm` 코멘트 보류).
- 모든 쿠버네티스 멤버는 코멘트에 `/lgtm` 을 추가해서 `lgtm` 레이블을 추가할 수 있다.
- SIG Docs 승인자들만이 코멘트에 `/approve` 를
추가해서 풀 리퀘스트를 병합할 수 있다. 일부 승인자들은
[PR Wrangler](/ko/docs/contribute/advanced/#일주일-동안-pr-랭글러-wrangler-되기) 또는 [SIG Docs 의장](#sig-docs-의장)과
같은 특정 역할도 수행한다.
## {{% heading "whatsnext" %}}
쿠버네티스 문서화에 기여하는 일에 대한 보다 많은 정보는 다음 문서를 참고한다.
- [신규 콘텐츠 기여하기](/ko/docs/contribute/new-content/overview/)
- [콘텐츠 검토하기](/ko/docs/contribute/review/reviewing-prs/)
- [문서 스타일 가이드](/ko/docs/contribute/style/)
content/ko/docs/contribute/participate/pr-wranglers.md
+70
View File
@@ -0,0 +1,70 @@
---
title: PR 랭글러(PR Wrangler)
content_type: concept
weight: 20
---
<!-- overview -->
SIG Docs [승인자](/ko/docs/contribute/participating/roles-and-responsibilites/#승인자)는 리포지터리에 대해 일주일 동안 교대로 [풀 리퀘스트 관리](https://github.com/kubernetes/website/wiki/PR-Wranglers)를 수행한다.
이 섹션은 PR 랭글러의 의무에 대해 다룬다. 좋은 리뷰 제공에 대한 자세한 내용은 [Reviewing changes](/ko/docs/contribute/review/)를 참고한다.
<!-- body -->
## 의무
PR 랭글러는 일주일 간 매일 다음의 일을 해야 한다.
- 매일 새로 올라오는 이슈를 심사하고 태그를 지정한다. SIG Docs가 메타데이터를 사용하는 방법에 대한 지침은 [이슈 심사 및 분류](/docs/contribute/review/for-approvers/#triage-and-categorize-issues)를 참고한다.
- [스타일](/docs/contribute/style/style-guide/)과 [콘텐츠](/docs/contribute/style/content-guide/) 가이드를 준수하는지에 대해 [열린(open) 풀 리퀘스트](https://github.com/kubernetes/website/pulls)를 매일 리뷰한다.
- 가장 작은 PR(`size/XS`)부터 시작하고, 가장 큰(`size/XXL`) PR까지 리뷰한다. 가능한 한 많은 PR을 리뷰한다.
- PR 기여자들이 [CLA]()에 서명했는지 확인한다.
- CLA에 서명하지 않은 기여자에게 CLA에 서명하도록 알리려면 [이](https://github.com/zparnold/k8s-docs-pr-botherer) 스크립트를 사용한다.
- 제안된 변경 사항에 대한 피드백을 제공하고 다른 SIG의 멤버에게 기술 리뷰를 요청한다.
- 제안된 콘텐츠 변경에 대해 PR에 인라인 제안(inline suggestion)을 제공한다.
- 내용을 확인해야 하는 경우, PR에 코멘트를 달고 자세한 내용을 요청한다.
- 관련 `sig/` 레이블을 할당한다.
- 필요한 경우, 파일의 머리말(front matter)에 있는 `reviewers:` 블록의 리뷰어를 할당한다.
- PR을 병합하려면 승인을 위한 `approve` 코멘트를 사용한다. 준비가 되면 PR을 병합한다.
- 병합하기 전에 PR은 다른 멤버의 `/lgtm` 코멘트를 받아야 한다.
- [스타일 지침]을 충족하지 않지만 기술적으로는 정확한 PR은 수락하는 것을 고려한다. 스타일 문제를 해결하는 `good first issue` 레이블의 새로운 이슈를 올리면 된다.
### 랭글러를 위해 도움이 되는 GitHub 쿼리
다음의 쿼리는 랭글러에게 도움이 된다.
이 쿼리들을 수행하여 작업한 후에는, 리뷰할 나머지 PR 목록은 일반적으로 작다.
이 쿼리들은 특히 현지화 PR을 제외한다. 모든 쿼리는 마지막 쿼리를 제외하고 메인 브렌치를 대상으로 한다.
- [CLA 서명 없음, 병합할 수 없음](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge+label%3Alanguage%2Fen):
CLA에 서명하도록 기여자에게 상기시킨다. 봇과 사람이 이미 알렸다면, PR을 닫고
CLA에 서명한 후 PR을 열 수 있음을 알린다.
**작성자가 CLA에 서명하지 않은 PR은 리뷰하지 않는다!**
- [LGTM 필요](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-label%3Algtm+):
멤버의 LGTM이 필요한 PR을 나열한다. PR에 기술 리뷰가 필요한 경우, 봇이 제안한 리뷰어 중 한 명을
지정한다. 콘텐츠에 대한 작업이 필요하다면, 제안하거나 인라인 피드백을 추가한다.
- [LGTM 보유, 문서 승인 필요](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+label%3Algtm):
병합을 위해 `/approve` 코멘트가 필요한 PR을 나열한다.
- [퀵윈(Quick Wins)](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22+): 명확한 결격 사유가 없는 메인 브랜치에 대한 PR을 나열한다. ([XS, S, M, L, XL, XXL] 크기의 PR을 작업할 때 크기 레이블에서 "XS"를 변경한다)
- [메인 브랜치이외의 브랜치에 대한 PR](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-base%3Amaster): `dev-` 브랜치에 대한 것일 경우, 곧 출시될 예정인 릴리스이다. `/assign @<meister's_github-username>` 을 사용하여 [문서 릴리스 관리자](https://github.com/kubernetes/sig-release/tree/master/release-team#kubernetes-release-team-roles)를 할당한다. 오래된 브랜치에 대한 PR인 경우, PR 작성자가 가장 적합한 브랜치를 대상으로 하고 있는지 여부를 파악할 수 있도록 도와준다.
### 풀 리퀘스트를 종료하는 시기
리뷰와 승인은 PR 대기열을 최신 상태로 유지하는 도구 중 하나이다. 또 다른 도구는 종료(closure)이다.
다음의 상황에서 PR을 닫는다.
- 작성자가 CLA에 2주 동안 서명하지 않았다.
작성자는 CLA에 서명한 후 PR을 다시 열 수 있다. 이는 어떤 것도 CLA 서명없이 병합되지 않게 하는 위험이 적은 방법이다.
- 작성자가 2주 이상 동안 코멘트나 피드백에 응답하지 않았다.
풀 리퀘스트를 닫는 것을 두려워하지 말자. 기여자는 진행 중인 작업을 쉽게 다시 열고 다시 시작할 수 있다. 종종 종료 통지는 작성자가 기여를 재개하고 끝내도록 자극하는 것이다.
풀 리퀘스트를 닫으려면, PR에 `/close` 코멘트를 남긴다.
{{< note >}}
[`fejta-bot`](https://github.com/fejta-bot)이라는 봇은 90일 동안 활동이 없으면 이슈를 오래된 것(stale)으로 표시한다. 30일이 더 지나면 rotten으로 표시하고 종료한다. PR 랭글러는 14-30일 동안 활동이 없으면 이슈를 닫아야 한다.
{{< /note >}}
content/ko/docs/contribute/participate/roles-and-responsibilties.md
+195
View File
@@ -0,0 +1,195 @@
---
title: 역할과 책임
content_type: concept
weight: 10
---
<!-- overview -->
누구나 쿠버네티스에 기여할 수 있다. SIG Docs에 대한 기여가 커짐에 따라, 커뮤니티의 다양한 멤버십을 신청할 수 있다.
이러한 역할을 통해 커뮤니티 내에서 더 많은 책임을 질 수 있다.
각 역할마다 많은 시간과 노력이 필요하다. 역할은 다음과 같다.
- 모든 사람: 쿠버네티스 문서에 정기적으로 기여하는 기여자
- 멤버: 이슈를 할당, 심사하고 풀 리퀘스트에 대한 구속력 없는 리뷰를 제공할 수 있다.
- 리뷰어: 문서의 풀 리퀘스트에 대한 리뷰를 리딩할 수 있으며 변경 사항에 대한 품질을 보증할 수 있다.
- 승인자: 문서에 대한 리뷰를 리딩하고 변경 사항을 병합할 수 있다
<!-- body -->
## 모든 사람
GitHub 계정을 가진 누구나 쿠버네티스에 기여할 수 있다. SIG Docs는 모든 새로운 기여자를 환영한다!
모든 사람은 다음의 작업을 할 수 있다.
- [`kubernetes/website`](https://github.com/kubernetes/website)를 포함한 모든 [쿠버네티스] 리포지터리에서 이슈를 올린다.
- 풀 리퀘스트에 대해 구속력 없는 피드백을 제공한다.
- 현지화에 기여한다.
- [슬랙](http://slack.k8s.io/) 또는 [SIG docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에 개선을 제안한다.
[CLA에 서명](/ko/docs/contribute/new-content/overview/#sign-the-cla) 후에 누구나 다음을 할 수 있다.
- 기존 콘텐츠를 개선하거나, 새 콘텐츠를 추가하거나, 블로그 게시물 또는 사례연구 작성을 위해 풀 리퀘스트를 연다.
- 다이어그램, 그래픽 자산 그리고 포함할 수 있는 스크린캐스트와 비디오를 제작한다.
자세한 내용은 [새로운 콘텐츠 기여하기](/ko/docs/contribute/new-content/)를 참고한다.
## 멤버
멤버는 `kubernetes/website` 에 여러 개의 풀 리퀘스트를 제출한 사람이다. 멤버는 [쿠버네티스 GitHub 조직](https://github.com/kubernetes)의 회원이다.
멤버는 다음의 작업을 할 수 있다.
- [모든 사람](#모든-사람)에 나열된 모든 것을 한다.
- 풀 리퀘스트에 `/lgtm` 코멘트를 사용하여 LGTM(looks good to me) 레이블을 추가한다.
{{< note >}}
`/lgtm` 사용은 자동화를 트리거한다. 만약 구속력 없는 승인을 제공하려면, 단순히 "LGTM" 코멘트를 남기는 것도 좋다!
{{< /note >}}
- `/hold` 코멘트를 사용하여 풀 리퀘스트에 대한 병합을 차단한다.
- `/assign` 코멘트를 사용하여 풀 리퀘스트에 리뷰어를 지정한다.
- 풀 리퀘스트에 구속력 없는 리뷰를 제공한다.
- 자동화를 사용하여 이슈를 심사하고 분류한다.
- 새로운 기능에 대한 문서를 작성한다.
### 멤버 되기
최소 5개의 실질적인 풀 리퀘스트를 제출하고 다른 [요구 사항](https://github.com/kubernetes/community/blob/master/community-membership.md#member)을 충족시킨 후, 다음의 단계를 따른다.
1. 멤버십을 [후원](/docs/contribute/advanced#sponsor-a-new-contributor)해 줄 두 명의 [리뷰어](#리뷰어) 또는 [승인자](#승인자)를 찾는다.
[슬랙의 #sig-docs 채널](https://kubernetes.slack.com) 또는
[SIG Docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에서 후원을 요청한다.
{{< note >}}
SIG Docs 멤버 개인에게 직접 email을 보내거나
슬랙 다이렉트 메시지를 보내지 않는다. 반드시 지원서를 제출하기 전에 후원을 요청해야 한다.
{{< /note >}}
2. [`kubernetes/org`](https://github.com/kubernetes/org/) 리포지터리에 GitHub 이슈를 등록한다. **Organization Membership Request** 이슈 템플릿을 사용한다.
3. 후원자에게 GitHub 이슈를 알린다. 다음 중 하나를 수행할 수 있다.
- 이슈에서 후원자의 GitHub 사용자 이름을 코멘트로 추가한다. (`@<GitHub-username>`)
- 슬랙 또는 이메일을 사용해 이슈 링크를 후원자에게 보낸다.
후원자는 `+1` 투표로 여러분의 요청을 승인할 것이다. 후원자가 요청을 승인하면, 쿠버네티스 GitHub 관리자가 여러분을 멤버로 추가한다. 축하한다!
만약 멤버십이 수락되지 않으면 피드백을 받게 될 것이다. 피드백의 내용을 해결한 후, 다시 지원하자.
4. 여러분의 이메일 계정으로 수신된 쿠버네티스 GitHub 조직으로의 초대를 수락한다.
{{< note >}}
GitHub은 초대를 여러분 계정의 기본 이메일 주소로 보낸다.
{{< /note >}}
## 리뷰어
리뷰어는 열린 풀 리퀘스트를 리뷰할 책임이 있다. 멤버 피드백과는 달리, 여러분은 리뷰어의 피드백을 반드시 해결해야 한다. 리뷰어는 [@kubernetes/sig-docs-{language}-reviews](https://github.com/orgs/kubernetes/teams?query=sig-docs) GitHub 팀의 멤버이다.
리뷰어는 다음의 작업을 수행할 수 있다.
- [모든 사람](#모든-사람)과 [멤버](#멤버)에 나열된 모든 것을 수행한다.
- 풀 리퀘스트 리뷰와 구속력 있는 피드백을 제공한다.
{{< note >}}
구속력 없는 피드백을 제공하려면, 코멘트에 "선택 사항: "과 같은 문구를 접두어로 남긴다.
{{< /note >}}
- 코드에서 사용자 화면 문자열 편집
- 코드 코멘트 개선
여러분은 SIG DOcs 리뷰어이거나, 특정 주제 영역의 문서에 대한 리뷰어일 수 있다.
### 풀 리퀘스트에 대한 리뷰어 할당
자동화 시스템은 모든 풀 리퀘스트에 대해 리뷰어를 할당한다. `/assign
[@_github_handle]` 코멘트를 남겨 특정 사람에게 리뷰를 요청할 수
있다.
지정된 리뷰어가 PR에 코멘트를 남기지 않는다면, 다른 리뷰어가 개입할 수 있다. 필요에 따라 기술 리뷰어를 지정할 수도 있다.
### `/lgtm` 사용하기
LGTM은 "Looks good to me"의 약자이며 풀 리퀘스트가 기술적으로 정확하고 병합할 준비가 되었음을 나타낸다. 모든 PR은 리뷰어의 `/lgtm` 코멘트가 필요하고 병합을 위해 승인자의 `/approve` 코멘트가 필요하다.
리뷰어의 `/lgtm` 코멘트는 구속력 있고 자동화 시스템이 `lgtm` 레이블을 추가하도록 트리거한다.
### 리뷰어 되기
[요건](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer)을
충족하면, SIG Docs 리뷰어가 될 수 있다. 다른 SIG의 리뷰어는 SIG Docs의 리뷰어 자격에 반드시 별도로 지원해야 한다.
지원하려면, 다음을 수행한다.
1. `kubernetes/website` 리포지터리 내
[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) 파일의 섹션에
여러분의 GitHub 사용자 이름을 추가하는 풀 리퀘스트를 연다.
{{< note >}}
자신을 추가할 위치가 확실하지 않으면, `sig-docs-ko-reviews` 에 추가한다.
{{< /note >}}
2. PR을 하나 이상의 SIG-Docs 승인자(`sig-docs-{language}-owners` 에 나열된 사용자 이름)에게 지정한다.
승인되면, SIG Docs 리더가 적당한 GitHub 팀에 여러분을 추가한다. 일단 추가되면, [K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)이 새로운 풀 리퀘스트에서 리뷰어로 여러분을 할당하고 제안한다.
## 승인자
승인자는 병합하기 위해 풀 리퀘스트를 리뷰하고 승인한다. 승인자는
[@kubernetes/sig-docs-{language}-owners](https://github.com/orgs/kubernetes/teams/?query=sig-docs) GitHub 팀의 멤버이다.
승인자는 다음의 작업을 할 수 있다.
- [모든 사람](#모든-사람), [멤버](#멤버) 그리고 [리뷰어](#리뷰어) 하위의 모든 목록을 할 수 있다.
- 코멘트에 `/approve` 를 사용해서 풀 리퀘스트를 승인하고, 병합해서 기여자의 컨텐츠를 게시한다.
- 스타일 가이드 개선을 제안한다.
- 문서 테스트 개선을 제안한다.
- 쿠버네티스 웹사이트 또는 다른 도구 개선을 제안한다.
PR에 이미 `/lgtm` 이 있거나, 승인자도 `/lgtm` 코멘트를 남긴다면, PR은 자동으로 병합된다. SIG Docs 승인자는 추가적인 기술 리뷰가 필요치 않는 변경에 대해서만 `/lgtm` 을 남겨야 한다.
### 풀 리퀘스트 승인
승인자와 SIG Docs 리더는 website 리포지터리로 풀 리퀘스트를 병합할 수 있는 유일한 사람들이다. 이것은 특정한 책임이 따른다.
- 승인자는 PR들을 리포지터리에 병합하는 `/approve` 명령을 사용할 수 있다.
{{< warning >}}
부주의한 머지로 인해 사이트를 파괴할 수 있으므로, 머지할 때에 그 의미를 확인해야 한다.
{{< /warning >}}
- 제안된 변경이 [컨트리뷰션 가이드 라인](/docs/contribute/style/content-guide/#contributing-content)에 적합한지 확인한다.
질문이 생기거나 확실하지 않다면 자유롭게 추가 리뷰를 요청한다.
- PR을 `/approve` 하기 전에 Netlify 테스트 결과를 검토한다.
<img src="/images/docs/contribute/netlify-pass.png" width="75%" alt="승인 전에 반드시 Netlify 테스트를 통과해야 한다" />
- 승인 전에 PR에 대한 Netlify 프리뷰 페이지를 방문하여, 제대로 보이는지 확인한다.
- 주간 로테이션을 위해 [PR Wrangler 로테이션 스케줄](https://github.com/kubernetes/website/wiki/PR-Wranglers)에 참여한다. SIG Docs는 모든 승인자들이 이 로테이션에 참여할
것으로 기대한다. 자세한 내용은 [PR 랭글러(PR wrangler)](/ko/docs/contribute/participating/pr-wranglers/)를
참고한다.
## 승인자 되기
[요구 사항](https://github.com/kubernetes/community/blob/master/community-membership.md#approver)을 충족하면 SIG Docs 승인자가 될 수 있다. 다른 SIG의 승인자는 SIG Docs의 승인자 자격에 대해 별도로 신청해야 한다.
지원하려면 다음을 수행한다.
1. `kubernetes/website` 리포지터리 내 [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) 파일의 섹션에 자신을 추가하는 풀 리퀘스트를 연다.
{{< note >}}
자신을 추가할 위치가 확실하지 않으면, `sig-docs-ko-owners` 에 추가한다.
{{< /note >}}
2. PR에 한 명 이상의 현재 SIG Docs 승인자를 지정한다.
승인되면, SIG Docs 리더가 적당한 GitHub 팀에 여러분을 추가한다. 일단 추가되면, [@k8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)이 새로운 풀 리퀘스트에서 승인자로 여러분을 할당하고 제안한다.
## {{% heading "whatsnext" %}}
- 모든 승인자가 교대로 수행하는 역할인 [PR 랭글러](/ko/docs/contribute/participating/pr-wranglers)에 대해 읽어보기
content/ko/docs/contribute/participating.md
-314
View File
@@ -1,314 +0,0 @@
---
title: SIG Docs에 참여하기
content_type: concept
weight: 60
card:
name: contribute
weight: 60
---
<!-- overview -->
SIG Docs는 쿠버네티스 프로젝트의
[분과회(special interest group)](https://github.com/kubernetes/community/blob/master/sig-list.md)
중 하나로, 쿠버네티스 전반에 대한 문서를 작성하고, 업데이트하며 유지보수하는 일을 주로 수행한다.
분과회에 대한 보다 자세한 정보는
[커뮤니티 GitHub 저장소 내 SIG Docs](https://github.com/kubernetes/community/tree/master/sig-docs)
를 참조한다.
SIG Docs는 모든 컨트리뷰터의 콘텐츠와 리뷰를 환영한다.
누구나 풀 리퀘스트(PR)를 요청할 수 있고,
누구나 콘텐츠에 대해 이슈를 등록하거나 진행 중인 풀 리퀘스트에 코멘트를 등록할 수 있다.
[멤버](#멤버), [리뷰어](#리뷰어), 또는 [승인자](#승인자)가 될 수 있다.
이런 역할은 변경을 승인하고 커밋할 수 있도록 보다 많은 접근 권한과 이에 상응하는 책임이 수반된다.
쿠버네티스 커뮤니티 내에서 멤버십이 운영되는 방식에 대한 보다 많은 정보를 확인하려면
[커뮤니티 멤버십](https://github.com/kubernetes/community/blob/master/community-membership.md)
문서를 확인한다.
문서의 나머지에서는 대외적으로 쿠버네티스를 가장 잘 드러내는 수단 중 하나인 쿠버네티스 웹사이트와
문서를 관리하는 책임을 가지는 SIG Docs에서,
이런 체계가 작동하는 특유의 방식에 대한 윤곽을 잡아보겠다.
<!-- body -->
## 역할과 책임
- **모든 사람** 은 쿠버네티스 문서에 기여할 수 있다. 기여 시 [CLA에 서명](/ko/docs/contribute/new-content/overview/#sign-the-cla)하고 GitHub 계정을 가지고 있어야 한다.
- 쿠버네티스 조직의 **멤버** 는 쿠버네티스 프로젝트에 시간과 노력을 투자한 기여자이다. 일반적으로 승인되는 변경이 되는 풀 리퀘스트를 연다. 멤버십 기준은 [커뮤니티 멤버십](https://github.com/kubernetes/community/blob/master/community-membership.md)을 참조한다.
- SIG Docs의 **리뷰어** 는 쿠버네티스 조직의 일원으로
문서 풀 리퀘스트에 관심을 표명했고, SIG Docs 승인자에
의해 GitHub 리포지터리에 있는 GitHub
그룹과 `OWNER` 파일에 추가되었다.
- SIG Docs의 **승인자** 는 프로젝트에 대한 지속적인 헌신을 보여준
좋은 멤버이다. 승인자는 쿠버네티스 조직을 대신해서
풀 리퀘스트를 병합하고 컨텐츠를 게시할 수 있다.
또한 승인자는 더 큰 쿠버네티스 커뮤니티의 SIG Docs를 대표할 수 있다.
릴리즈 조정과 같은 SIG Docs 승인자의 일부 의무에는
상당한 시간 투입이 필요하다.
## 모든 사람
누구나 다음 작업을 할 수 있다.
- 문서를 포함한 쿠버네티스의 모든 부분에 대해 GitHub 이슈 열기.
- 풀 리퀘스트에 대한 구속력 없는 피드백 제공
- 기존 컨텐츠를 현지화하는데 도움주는 것
- [슬랙](http://slack.k8s.io/) 또는 [SIG docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에 개선할 아이디어를 제시한다.
- `/lgtm` Prow 명령 ("looks good to me" 의 줄임말)을 사용해서 병합을 위한 풀 리퀘스트의 변경을 추천한다.
{{< note >}}
만약 쿠버네티스 조직의 멤버가 아니라면, `/lgtm` 을 사용하는 것은 자동화된 시스템에 아무런 영향을 주지 않는다.
{{< /note >}}
[CLA에 서명](/ko/docs/contribute/new-content/overview/#sign-the-cla) 후에 누구나 다음을 할 수 있다.
- 기존 콘텐츠를 개선하거나, 새 콘텐츠를 추가하거나, 블로그 게시물 또는 사례연구 작성을 위해 풀 리퀘스트를 연다.
## 멤버
멤버는 [멤버 기준](https://github.com/kubernetes/community/blob/master/community-membership.md#member)을 충족하는 쿠버네티스 프로젝트에 기여한 사람들이다. SIG Docs는 쿠버네티스 커뮤니티의 모든 멤버로부터 기여를 환경하며,
기술적 정확성에 대한 다른 SIG 멤버들의 검토를 수시로 요청한다.
쿠버네티스 조직의 모든 멤버는 다음 작업을 할 수 있다.
- [모든 사람](#모든-사람) 하위에 나열된 모든 것
- 풀 리퀘스트 코멘트에 `/lgtm` 을 사용해서 LGTM(looks good to me) 레이블을 붙일 수 있다.
- 풀 리퀘스트에 이미 LGTM 과 승인 레이블이 있는 경우에 풀 리퀘스트가 병합되지 않도록 코멘트에 `/hold` 를 사용할 수 있다.
- 코멘트에 `/assign` 을 사용해서 풀 리퀘스트에 리뷰어를 배정한다.
### 멤버 되기
최소 5개의 실질적인 풀 리퀘스트를 성공적으로 제출한 경우, 쿠버네티스 조직의
[멤버십](https://github.com/kubernetes/community/blob/master/community-membership.md#member)을
요청할 수 있다. 다음의 단계를 따른다.
1. 멤버십을 [후원](/docs/contribute/advanced#sponsor-a-new-contributor)해 줄 두 명의 리뷰어 또는 승인자를
찾는다.
[쿠버네티스 Slack 인스턴스의 #sig-docs 채널](https://kubernetes.slack.com) 또는
[SIG Docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에서
후원을 요청한다.
{{< note >}}
SIG Docs 멤버 개인에게 직접 email을 보내거나
Slack 다이렉트 메시지를 보내지 않는다.
{{< /note >}}
2. `kubernetes/org` 리포지터리에 멤버십을 요청하는 GitHub 이슈를 등록한다.
[커뮤니티 멤버십](https://github.com/kubernetes/community/blob/master/community-membership.md)
문서의 가이드라인을 따라서 양식을 채운다.
3. 해당 GitHub 이슈에 후원자를 at-mentioning(`@<GitHub-username>`을 포함한 코멘트를 추가)하거나
링크를 직접 보내주어서
후원자가 해당 GitHub 이슈를 확인하고 `+1` 표를 줄 수 있도록 한다.
4. 멤버십이 승인되면, 요청에 할당된 GitHub 관리자 팀 멤버가 승인되었음을 업데이트해주고
해당 GitHub 이슈를 종료한다.
축하한다, 이제 멤버가 되었다!
만약 멤버십 요청이 받아들여지지 않으면,
멤버십 위원회에서 재지원 전에
필요한 정보나 단계를 알려준다.
## 리뷰어
리뷰어는
[@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews)
GitHub 그룹의 멤버이다. 리뷰어는 문서 풀 리퀘스트를 리뷰하고 제안받은 변경에 대한 피드백을
제공한다. 리뷰어는 다음 작업을 수행할 수 있다.
- [모든 사람](#모든-사람)과 [멤버](#멤버)에 나열된 모든 것을 수행
- 새 기능의 문서화
- 이슈 해결 및 분류
- 풀 리퀘스트 리뷰와 구속력있는 피드백 제공
- 다이어그램, 그래픽 자산과 포함가능한 스크린샷과 비디오를 생성
- 코드에서 사용자 화면 문자열 편집
- 코드 코멘트 개선
### 풀 리퀘스트에 대한 리뷰어 할당
자동화 시스템은 풀 리퀘스트에 대해 리뷰어를 할당하고, 사용자는 해당 풀 리퀘스트에
`/assign [@_github_handle]` 코멘트를 남겨서 특정 리뷰어에게 리뷰를 요청할 수 있다.
풀 리퀘스트가 기술적으로 정확하고 더 변경이 필요하지 않다는 의미로,
리뷰어는 `/lgtm` 코멘트를
해당 풀 리퀘스트에 추가할 수 있다.
할당된 리뷰어가 내용을 아직 리뷰하지 않은 경우,
다른 리뷰어가 나설 수 있다. 추가로, 기술 리뷰어를
할당해서 그들이 `/lgtm`을 주기를 기다릴 수도 있다.
사소한 변경이나 기술적 리뷰가 필요한 PR의 경우, SIG Docs [승인자](#승인자)가 `/lgtm`을 줄
수도 있다.
리뷰어의 `/approve` 코멘트는 자동화 시스템에서 무시된다.
### 리뷰어 되기
[요건](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer)을
충족하면, SIG Docs 리뷰어가 될 수 있다.
다른 SIG의 리뷰어는 SIG Docs의 리뷰어 자격에
반드시 별도로 지원해야 한다.
지원하려면, `kubernetes/website` 저장소의
[최상위 OWNERS 파일](https://github.com/kubernetes/website/blob/master/OWNERS)
내 `reviewers` 섹션에 자신을 추가하는 풀 리퀘스트를 연다. PR을 한 명 이상의 현재 SIG Docs
승인자에게 할당한다.
풀 리퀘스트가 승인되면, 이제 SIG Docs 리뷰어가 된다.
[K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)이
새로운 풀 리퀘스트에 대한 리뷰어로 당신을 추천하게 된다.
일단 승인되면, 현재 SIG Docs 승인자가
[@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews)
GitHub 그룹에 당신을 추가하기를 요청한다. `kubernetes-website-admins` GitHub 그룹의
멤버만이 신규 멤버를 GitHub 그룹에 추가할 수 있다.
## 승인자
승인자는
[@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers)
GitHub 그룹의 멤버이다. [SIG Docs 팀과 자동화](#sig-docs-팀과-자동화) 문서를 참조한다.
승인자는 다음의 작업을 할 수 있다.
- [모든 사람](#모든-사람), [멤버](#멤버) 그리고 [리뷰어](#리뷰어) 하위의 모든 목록을 할 수 있다.
- 코멘트에 `/approve` 를 사용해서 풀 리퀘스트를 승인하고, 병합해서 기여자의 컨텐츠를 게시한다.
만약 승인자가 아닌 사람이 코멘트에 승인을 남기면 자동화 시스템에서 이를 무시한다.
- 쿠버네티스 릴리즈팀에 문서 담당자로 참여
- 스타일 가이드 개선 제안
- 문서 테스트 개선 제안
- 쿠버네티스 웹사이트 또는 다른 도구 개선 제안
PR이 이미 `/lgtm`을 받았거나, 승인자가 `/lgtm`을 포함한 코멘트를 남긴 경우에는
해당 PR이 자동으로 머지된다. SIG Docs 승인자는 추가적인 기술 리뷰가 필요하지 않은 변경에 대해서만
`/lgtm`을 남겨야한다.
### 승인자 되기
[요건](https://github.com/kubernetes/community/blob/master/community-membership.md#approver)을
충족하면, SIG Docs 승인자가 될 수 있다.
다른 SIG의 승인자는 SIG Docs의 승인자 자격에
반드시 별도로 지원해야 한다.
지원하려면, `kubernetes/website` 저장소의
[최상위 OWNERS 파일](https://github.com/kubernetes/website/blob/master/OWNERS)
내 `approvers` 섹션에 자신을 추가하는 풀 리퀘스트를 연다. PR을 한 명 이상의 현재 SIG Docs
승인자에게 할당한다.
풀 리퀘스트가 승인되면, 이제 SIG Docs 승인자가 된다.
[K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)이
새로운 풀 리퀘스트에 대한 리뷰어로 당신을 추천하게 된다.
일단 승인되면, 현재 SIG Docs 승인자가
[@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers)
GitHub 그룹에 당신을 추가하기를 요청한다. `kubernetes-website-admins` GitHub 그룹의
멤버만이 신규 멤버를 GitHub 그룹에 추가할 수 있다.
### 승인자의 책임
승인자는 리뷰와 풀리퀘스트를 웹사이트 리포지터리에 머지하여 문서를 개선한다. 이 역할에는 추가적인 권한이 필요하므로, 승인자에게는 별도의 책임이 부여된다.
- 승인자는 PR들을 리포에 머지하는 `/approve` 명령을 사용할 수 있다.
부주의한 머지로 인해 사이트를 파괴할 수 있으므로, 머지할 때에 그 의미를 확인해야 한다.
- 제안된 변경이 [컨트리뷰션 가이드 라인](/docs/contribute/style/content-guide/#contributing-content)에 적합한지 확인한다.
질문이 생기거나 확실하지 않다면 자유롭게 추가 리뷰를 요청한다.
- PR을 `/approve` 하기 전에 Netlify 테스트 결과를 검토한다.
<img src="/images/docs/contribute/netlify-pass.png" width="75%" alt="승인 전에 반드시 Netlify 테스트를 통과해야 한다" />
- 승인 전에 PR에 대한 Netlify 프리뷰 페이지를 방문하여, 제대로 보이는지 확인한다.
- 주간 로테이션을 위해 [PR Wrangler 로테이션 스케줄](https://github.com/kubernetes/website/wiki/PR-Wranglers)에 참여한다. SIG Docs는 모든 승인자들이 이 로테이션에 참여할
것으로 기대한다. [일주일 간 PR Wrangler 되기](/ko/docs/contribute/advanced/#일주일-동안-pr-랭글러-wrangler-되기)
문서를 참고한다.
## SIG Docs 의장
SIG Docs를 포함한 각 SIG는, 한 명 이상의 SIG 멤버가 의장 역할을 하도록 선정한다. 이들은 SIG Docs와
다른 쿠버네티스 조직 간 연락책(point of contact)이 된다. 이들은 쿠버네티스 프로젝트 전반의 조직과
그 안에서 SIG Docs가 어떻게 운영되는지에 대한 폭넓은 지식을 갖추어야한다.
현재 의장의 목록을 확인하려면
[리더십](https://github.com/kubernetes/community/tree/master/sig-docs#leadership)
문서를 참조한다.
## SIG Docs 팀과 자동화
SIG Docs의 자동화는 다음의 두 가지 자동화 메커니즘에 의존한다.
GitHub 그룹과 OWNERS 파일이다.
### GitHub 그룹
GitHub의 SIG Docs 그룹은 두 팀을 정의한다.
- [@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers)
- [@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews)
그룹의 전원과 의사소통하기 위해서
각각 GitHub 코멘트에서 그룹의 `@name`으로 참조할 수 있다.
이 팀은 중복되지만, 정확히 일치하지는 않으며, 이 그룹은 자동화 툴에서 사용된다.
이슈, 풀 리퀘스트를 할당하고,
PR 승인을 지원하기 위해서 자동화 시스템이 OWNERS 파일의 정보를 활용한다.
### OWNERS 파일과 전문(front-matter)
쿠버네티스 프로젝트는 GitHub 이슈와 풀 리퀘스트 자동화와 관련해서 prow라고 부르는 자동화 툴을 사용한다.
[쿠버네티스 웹사이트 리포지터리](https://github.com/kubernetes/website)는
다음의 두개의 [prow 플러그인](https://github.com/kubernetes/test-infra/tree/master/prow/plugins)을
사용한다.
- blunderbuss
- approve
이 두 플러그인은 `kubernetes/website` GitHub 리포지터리 최상위 수준에 있는
[OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS)와
[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES)
파일을 사용해서
해당 리포지터리에 대해 prow가 작동하는 방식을 제어한다.
OWNERS 파일은 SIG Docs 리뷰어와 승인자의 목록을 포함한다. OWNERS 파일은 하위 디렉터리에 있을 수
있고, 해당 하위 디렉터리와 그 이하의 파일에 대해 리뷰어와 승인자 역할을 수행할 사람을 새로 지정할 수 있다.
일반적인 OWNERS 파일에 대한 보다 많은 정보는
[OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md)
문서를 참고한다.
추가로, 개별 마크다운(Markdown) 파일 내 전문에
리뷰어와 승인자를 개별 GitHub 사용자 이름이나 GitHub 그룹으로 열거할 수 있다.
OWNERS 파일과 마크다운 파일 내 전문의 조합은
자동화 시스템이 누구에게 기술적, 편집적 리뷰를 요청해야 할지를
PR 소유자에게 조언하는데 활용된다.
## 병합 작업 방식
풀 리퀘스트 요청이 콘텐츠(현재 `master`)를 발행하는데 사용하는
브랜치에 병합되면 그 내용이 전 세계에 공개된다. 게시된 콘텐츠의
품질을 높히기 위해 SIG Docs 승인자가 풀 리퀘스트를 병합하는 것을 제한한다.
작동 방식은 다음과 같다.
- 풀 리퀘스트에 `lgtm` 과 `approve` 레이블이 있고, `hold` 레이블이 없고,
모든 테스트를 통과하면 풀 리퀘스트는 자동으로 병합된다.
- 쿠버네티스 조직의 멤버와 SIG Docs 승인자들은 지정된 풀 리퀘스트의
자동 병합을 방지하기 위해 코멘트를 추가할 수 있다(코멘트에 `/hold` 추가 또는
`/lgtm` 코멘트 보류).
- 모든 쿠버네티스 멤버는 코멘트에 `/lgtm` 을 추가해서 `lgtm` 레이블을 추가할 수 있다.
- SIG Docs 승인자들만이 코멘트에 `/approve` 를
추가해서 풀 리퀘스트를 병합할 수 있다. 일부 승인자들은
[PR Wrangler](/ko/docs/contribute/advanced/#일주일-동안-pr-랭글러-wrangler-되기) 또는 [SIG Docs 의장](#sig-docs-의장)과
같은 특정 역할도 수행한다.
## {{% heading "whatsnext" %}}
쿠버네티스 문서화에 기여하는 일에 대한 보다 많은 정보는 다음 문서를 참고한다.
- [신규 콘텐츠 기여하기](/ko/docs/contribute/new-content/overview/)
- [콘텐츠 검토하기](/ko/docs/contribute/review/reviewing-prs/)
- [문서 스타일 가이드](/ko/docs/contribute/style/)
content/ko/docs/contribute/style/write-new-topic.md
+10 -2
View File
@@ -28,9 +28,17 @@ weight: 20
튜토리얼 | 튜토리얼 페이지는 여러 쿠버네티스의 특징들을 하나로 묶어서 목적을 달성하는 방법을 보여준다. 튜토리얼은 독자들이 페이지를 읽을 때 실제로 할 수 있는 몇 가지 단계의 순서를 제공한다. 또는 관련 코드 일부에 대한 설명을 제공할 수도 있다. 예를 들어 튜토리얼은 코드 샘플의 연습을 제공할 수 있다. 튜토리얼에는 쿠버네티스의 특징에 대한 간략한 설명이 포함될 수 있지만 개별 기능에 대한 자세한 설명은 관련 개념 문서과 연결지어야 한다.
{{< /table >}}
### 새 페이지 작성
작성하는 각각의 새 페이지에 대해 [콘텐츠 타입](/docs/contribute/style/page-content-types/)을
사용하자. 페이지 타입을 사용하면
지정된 타입의 문서 간에 일관성을 보장할 수 있다.
사용하자. 문서 사이트는 새 콘텐츠 페이지를 작성하기 위한 템플리트 또는
[Hugo archetypes](https://gohugo.io/content-management/archetypes/)을
제공한다. 새로운 타입의 페이지를 작성하려면, 작성하려는 파일의 경로로 `hugo new` 를
실행한다. 예를 들면, 다음과 같다.
```
hugo new docs/concepts/my-first-concept.md
```
## 제목과 파일 이름 선택