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

Third Korean l10n work for release 1.18

Browse Source 
- Translate cluster-administration/networking.md in Korean
- Fix issue with concepts/storage/volumes.md
- Translate /concepts/configuration/pod-overhead in Korean
- Update to Outdated files in the dev-1.18-ko.3 branch.
- Translate concepts/configuration/configmap.md in Korean
- Translate contribute/review/reviewing-prs/ in Korean
- Translate concepts/configuration/pod-priority-preemption.md in Korean
- Translate tasks/configure-pod-container/configure-volume-storage in Korean
- Translate contribute/new-content/new-content/ in Korean
- Translate concepts/architecture/control-plane-node-communication.md in Korean
- Restore the deleted master-node-communication.md file
- Translate concepts/cluster-administration/addons.md in Korean
- Translate contribute/new-content/overview/ in Korean
- Translate tasks/tools/install-kubectl.md in Korean
- Translate concepts/configuration/manage-resources-containers.md in Korean
- Translate tasks/administer-cluster/kubeadm/kubeadm-upgrade/ in Korean
- add new words to Korean glossary and fix minor
- Translate contribute/style/_index.md in Korean
- Translate concepts/cloud-administration/cloud-providers.md in Korean
- Translate contribute/review/for-approvers.md in Korean

Co-authored-by:    Jerry Park <jaehwa@gmail.com>
Co-authored-by:    Seokho Son <shsongist@gmail.com>
Co-authored-by:    jmyung <jesang.myung@gmail.com>
Co-authored-by:    coolguyhong <podolsmith@naver.com>
Co-authored-by:    Yuk, Yongsu <ysyukr@gmail.com>
Co-authored-by:    bluefriday <bluefriday86@gmail.com>
Co-authored-by:    SangshikLee <neolss@gmail.com>
This commit is contained in:
Jerry Park
2020-04-11 15:21:34 +09:00
committed by Claudia J.Kang
parent c74ce882ec
commit ca62e21766
67 changed files with 4827 additions and 313 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/contribute/review/_index.md
+14
View File
@@ -0,0 +1,14 @@
---
title: 변경 사항 리뷰하기
weight: 30
---
{{% capture overview %}}
이 섹션은 콘텐츠를 리뷰하는 방법에 대해 설명한다.
{{% /capture %}}
{{% capture body %}}
{{% /capture %}}
content/ko/docs/contribute/review/for-approvers.md
+228
View File
@@ -0,0 +1,228 @@
---
title: 승인자와 리뷰어의 리뷰
linktitle: 승인자와 리뷰어용
slug: for-approvers
content_template: templates/concept
weight: 20
---
{{% capture overview %}}
SIG Docs [리뷰어](/ko/docs/contribute/participating/#리뷰어)와 [승인자](/ko/docs/contribute/participating/#승인자)는 변경 사항을 리뷰할 때 몇 가지 추가 작업을 수행한다.
매주 특정 문서 승인자 역할의 지원자가
풀 리퀘스트를 심사하고 리뷰한다. 이
사람은 일주일 동안 "PR 랭글러(Wrangler)"이다. 자세한
정보는 [PR 랭글러 스케줄러](https://github.com/kubernetes/website/wiki/PR-Wranglers)를 참고한다. PR 랭글러가 되려면, 매주 SIG Docs 회의에 참석하고 자원한다. 이번 주에 해당 일정이 없는 경우에도, 아직 리뷰 중이 아닌
풀 리퀘스트(PR)를 여전히 리뷰할 수 있다.
로테이션 외에도, 봇은 영향을 받는 파일의 소유자를 기반으로
PR에 대한 리뷰어와 승인자를 할당한다.
{{% /capture %}}
{{% capture body %}}
## PR 리뷰
쿠버네티스의 문서는 [쿠버네티스의 코드 리뷰 프로세스](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md#the-code-review-process)를 따른다.
[풀 리퀘스트 리뷰](/ko/docs/contribute/review/reviewing-prs)에 설명된 모든 내용이 적용되지만, 리뷰어와 승인자도 다음을 수행해야 한다.
- `/assign` Prow 명령을 사용하여 필요에 따라 특정 리뷰어를 PR에 할당한다. 이는 코드 기여자에게
기술 리뷰를 요청할 때 특히 중요하다.
{{< note >}}
마크다운 파일 맨 위에 있는 헤더의 `reviewers` 필드를 보고 기술 리뷰를
제공할 수 있는 사람을 확인한다.
{{< /note >}}
- PR이 [콘텐츠](/docs/contribute/style/content-guide/)와 [스타일](/docs/contribute/style/style-guide/) 가이드를 따르는 지 확인한다. 그렇지 않은 경우 가이드의 관련 부분에 작성자를 연결한다.
- 적용이 가능한 경우 GitHub **Request Changes** 옵션을 사용하여 PR 작성자에게 변경을 제안한다.
- 제안한 사항이 구현된 경우, `/approve` 또는 `/lgtm` Prow 명령을 사용하여 GitHub에서 리뷰 상태를 변경한다.
## 다른 사람의 PR에 커밋
PR 코멘트를 남기는 것이 도움이 되지만, 대신 다른 사람의 PR에 커밋을
해야 하는 경우가 있다.
다른 사람이 명시적으로 요청하거나, 오랫동안
중단된 PR을 재개하려는 경우가 아니라면 다른 사람에게서 "가져오지" 마라. 단기적으로는
작업이 빠를 수 있지만, 그 사람이 기여할 기회를 박탈하게 된다.
사용할 프로세스는 이미 PR의 범위에 있는 파일을 편집해야
하는지, 또는 PR이 아직 다루지 않은 파일을 편집해야 하는지에 따라 다르다.
다음 중 하나에 해당하면 다른 사람의 PR에 커밋할 수
없다.
- PR 작성자가 브랜치를
[https://github.com/kubernetes/website/](https://github.com/kubernetes/website/)
리포지터리로 직접 푸시한 경우, 푸시 접근 권한이 있는 리뷰어만 다른 사용자의 PR에 커밋할 수 있다.
{{< note >}}
다음 번부터는 PR을 열기 전에 작성자가 브랜치를 자신의 포크로
푸시하도록 권장한다.
{{< /note >}}
- PR 작성자가 승인자의 수정을 명시적으로 허용하지 않는다.
## 리뷰를 위한 Prow 명령
[Prow](https://github.com/kubernetes/test-infra/blob/master/prow/README.md)는
풀 리퀘스트 (PR)에 대한 작업을 실행하는 쿠버네티스 기반 CI/CD 시스템이다. Prow는
챗봇 스타일 명령으로 쿠버네티스
조직 전체에서 [레이블 추가와
제거](#이슈-레이블-추가와-제거), 이슈 종료 및 승인자 할당과 같은 GitHub 작업을 처리할 수 ​​있다. `/<command-name>` 형식을 사용하여 Prow 명령을 GitHub 코멘트로 입력한다.
리뷰어와 승인자가 사용하는 가장 일반적인 Prow 명령은 다음과 같다.
{{< table caption="리뷰를 위한 Prow 명령" >}}
Prow 명령 | 역할 제한 | 설명
:------------|:------------------|:-----------
`/lgtm` | 누구나, 리뷰어나 승인자가 사용한다면 자동화를 트리거한다. | PR 리뷰를 마치고 변경 사항에 만족했음을 나타낸다.
`/approve` | 승인자 | PR을 병합(merge)하기 위해 승인한다.
`/assign` | 리뷰어 또는 승인자 | PR을 리뷰하거나 승인할 사람을 지정한다.
`/close` | 리뷰어 또는 승인자 | 이슈 또는 PR을 닫는다.
`/hold` | 누구나 | 자동으로 병합할 수 없음을 나타내는 `do-not-merge/hold` 레이블을 추가한다.
`/hold cancel` | 누구나 | `do-not-merge/hold` 레이블을 제거한다.
{{< /table >}}
PR에서 사용할 수 있는 명령의 전체 목록을 보려면
[Prow 명령 레퍼런스](https://prow.k8s.io/command-help)를 참고한다.
## 이슈 심사와 분류
일반적으로, SIG Docs는 [쿠버네티스 이슈 심사](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md) 프로세스를 따르며 동일한 레이블을 사용한다.
이 GitHub 이슈 [필터](https://github.com/kubernetes/website/issues?q=is%3Aissue+is%3Aopen+-label%3Apriority%2Fbacklog+-label%3Apriority%2Fimportant-longterm+-label%3Apriority%2Fimportant-soon+-label%3Atriage%2Fneeds-information+-label%3Atriage%2Fsupport+sort%3Acreated-asc)는
심사가 필요한 이슈를 찾는다.
### 이슈 심사
1. 이슈 확인
- 이슈가 website 문서에 관한 것인지 확인한다. 질문에 답하거나
리소스에 리포터를 지정하면 일부 이슈를 신속하게 종결할 수 있다. 자세한 내용은
[지원 요청 또는 코드 버그 리포트](#지원-요청-또는-코드-버그-리포트) 섹션을 참고한다.
- 이슈가 가치가 있는지 평가한다.
- 이슈의 내용에 실행할 수 있는 세부 사항이 충분하지 않거나 템플릿의 내용이
제대로 작성되지 않은 경우 `triage/needs-information` 레이블을 추가한다.
- `lifecycle/stale` 과 `triage/needs-information` 레이블이 모두 있으면 이슈를 닫는다.
2. 우선순위 레이블을
추가한다([이슈 심사 가이드라인](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md#define-priority)은 우선순위 레이블을 자세히 정의함).
{{< table caption="이슈 레이블" >}}
레이블 | 설명
:------------|:------------------
`priority/critical-urgent` | 이 작업을 지금 즉시 수행한다.
`priority/important-soon` | 3개월 이내에 이 작업을 수행한다.
`priority/important-longterm` | 6개월 이내에 이 작업을 수행한다.
`priority/backlog` | 무기한 연기할 수 있다. 자원이 있을 때 수행한다.
`priority/awaiting-more-evidence` | 잠재적으로 좋은 이슈에 대해 잊지 않도록 표시한다.
`help` 또는 `good first issue` | 쿠버네티스나 SIG Docs 경험이 거의 없는 사람에게 적합하다. 자세한 내용은 [도움이 필요함 및 좋은 첫 번째 이슈 레이블](https://github.com/kubernetes/community/blob/master/contributors/guide/help-wanted.md)을 참고한다.
{{< /table >}}
재량에 따라, 이슈의 소유권을 가져와서 PR을
제출한다(특히, 이미 수행 중인 작업과 관련이 있거나 빠르다면).
이슈 심사에 대해 질문이 있다면, 슬랙의 `#sig-docs` 채널이나
[kubernetes-sig-docs 메일링리스트](https://groups.google.com/forum/#!forum/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 리포지터리의 레이블 섹션](https://github.com/kubernetes/website/labels)을 참고한다. SIG Docs에서 모든 레이블을 사용하는 것은 아니다.
### 이슈의 lifecycle 레이블
이슈는 일반적으로 신속하게 열리고 닫힌다.
그러나, 가끔씩은 이슈가 열린 후 비활성 상태로 있다.
어떤 경우에는 이슈가 90일 이상 열려 있을 수도 있다.
{{< table caption="이슈의 lifecycle 레이블" >}}
레이블 | 설명
:------------|:------------------
`lifecycle/stale` | 90일이 지나도 아무런 활동이 없는 이슈는 자동으로 오래된 것(stale)으로 표시된다. `/remove-lifecycle stale` 명령을 사용하여 라이프사이클을 수동으로 되돌리지 않으면 이슈가 자동으로 닫힌다.
`lifecycle/frozen` | 90일 동안 활동이 없어도 이 레이블의 이슈는 오래된 것(stale)으로 바뀌지 않는다. 사용자는 `priority/important-longterm` 레이블이 있는 이슈처럼 90일보다 훨씬 오래 열려 있어야 하는 이슈에 이 레이블을 수동으로 추가한다.
{{< /table >}}
## 특별한 이슈 유형의 처리
SIG Docs가 처리 방법을 문서화할 정도로 다음과 같은 유형의 이슈를
자주 경험하게 된다.
### 중복된 이슈
단일 문제에 대해 하나 이상의 이슈가 열려 있으면, 이를 단일 이슈로 합친다.
열린 상태를 유지할 이슈를 결정한 다음(또는
새로운 이슈를 열어야 함), 모든 관련 정보로 이동하여 관련 이슈를 연결해야 한다.
마지막으로, 동일한 문제를 설명하는 다른 모든 이슈에
`triage/duplicate` 레이블을 지정하고 닫는다. 하나의 이슈만 해결하는 것으로 혼동을 줄이고
같은 문제에 대한 중복 작업을 피할 수 있다.
### 깨진 링크 이슈
깨진 링크 이슈가 API 문서나 `kubectl` 문서에 있는 경우, 문제가 완전히 이해될 때까지 `/priority critical-urgent` 레이블을 할당한다. 다른 모든 깨진 링크 이슈는 수동으로 수정해야하므로, `/priority important-longterm` 를 할당한다.
### 블로그 이슈
[쿠버네티스 블로그](https://kubernetes.io/blog/) 항목은 시간이 지남에 따라
구식이 될 것으로 예상한다. 따라서, 1년 미만의 블로그 항목만 유지 관리한다.
1년이 지난 블로그 항목과 관련된 이슈일 경우,
수정하지 않고 이슈를 닫는다.
### 지원 요청 또는 코드 버그 리포트
문서에 대한 일부 이슈는 실제로 기본 코드와 관련된 이슈이거나, 튜토리얼과
같은 무언가가 작동하지 않을 때 도움을 요청하는 것이다.
문서와 관련이 없는 이슈의 경우, `triage/support` 레이블과 함께 요청자에게 지원받을 수 있는 곳(슬랙, Stack Overflow)을
알려주며 이슈를 닫고, 기능 관련 버그에 대한 이슈인 경우,
관련 리포지터리를 코멘트로 남긴다(`kubernetes/kubernetes` 는
시작하기 좋은 곳이다).
지원 요청에 대한 샘플 응답은 다음과 같다.
```none
이 이슈는 지원 요청과 비슷하지만
문서 관련 이슈와는 관련이 없는 것 같습니다.
[쿠버네티스 슬랙](http://slack.k8s.io/)의
`#kubernetes-users` 채널에서 질문을 하시기 바랍니다. 또한,
[Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)와
같은 리소스를 검색하여 유사한 질문에 대한 답변을
얻을 수도 있습니다.
https://github.com/kubernetes/kubernetes 에서
쿠버네티스 기능 관련 이슈를 열 수도 있습니다.
문서에 대한 이슈인 경우 이 이슈를 다시 여십시오.
```
샘플 코드 버그 리포트 응답은 다음과 같다.
```none
이 이슈는 문서에 대한 이슈보다 코드에 대한 이슈와
비슷합니다. https://github.com/kubernetes/kubernetes/issues 에서
이슈를 여십시오.
문서에 대한 이슈인 경우 이 이슈를 다시 여십시오.
```
{{% /capture %}}
content/ko/docs/contribute/review/reviewing-prs.md
+98
View File
@@ -0,0 +1,98 @@
---
title: 풀 리퀘스트 리뷰
content_template: templates/concept
main_menu: true
weight: 10
---
{{% capture overview %}}
누구나 문서화에 대한 풀 리퀘스트를 리뷰할 수 있다. 쿠버네티스 website 리포지터리의 [풀 리퀘스트](https://github.com/kubernetes/website/pulls) 섹션을 방문하여 열린(open) 풀 리퀘스트를 확인한다.
문서화에 대한 풀 리퀘스트를 리뷰하는 것은
쿠버네티스 커뮤니티에 자신을 소개하는 훌륭한 방법이다.
아울러, 코드 베이스(code base)를 배우고 다른 기여자와 신뢰를 구축하는 데 도움이 된다.
리뷰하기 전에, 다음을 수행하는 것이 좋다.
- 적합한 코멘트를 남길 수 있도록 [콘텐츠 가이드](/docs/contribute/style/content-guide/)와
[스타일 가이드](/docs/contribute/style/style-guide/)를 읽는다.
- 쿠버네티스 문서화 커뮤니티의 다양한 [역할과 책임](/docs/contribute/participating/#roles-and-responsibilities)을 이해한다.
{{% /capture %}}
{{% capture body %}}
## 시작하기 전에
리뷰를 시작하기 전에 다음을 명심하자.
- [CNCF 행동 강령](https://github.com/cncf/foundation/blob/master/code-of-conduct-languages/ko.md)을 읽고 항상 준수한다.
- 정중하고, 사려 깊고, 도움이 되자.
- PR의 긍정적인 측면과 변화에 대한 의견을 남긴다.
- 당신의 리뷰를 어떻게 받아들일지에 대해 공감하고 주의한다.
- 좋은 의도를 가지고 명확한 질문을 한다.
- 숙련된 기여자인 경우, 작업에 광범위한 변경이 필요한 새 기여자와 쌍을 이루어 리뷰해 본다.
## 리뷰 과정
일반적으로, 영어로 콘텐츠와 스타일에 대한 풀 리퀘스트를 리뷰한다.
1. [https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls)로
이동한다.
쿠버네티스 website와 문서에 대한 모든 열린 풀 리퀘스트 목록이
표시된다.
2. 다음 레이블 중 하나 또는 모두를 사용하여 열린 PR을 필터링한다.
- `cncf-cla: yes`(권장): CLA에 서명하지 않은 기여자가 제출한 PR은 병합할 수 없다. 자세한 내용은 [CLA 서명](/docs/contribute/new-content/overview/#sign-the-cla)을 참고한다.
- `language/en`(권장): 영어 문서에 대한 PR 전용 필터이다.
- `size/<size>`: 특정 크기의 PR을 필터링한다. 새로 시작하는 사람이라면, 더 작은 PR로 시작한다.
또한, PR이 진행 중인 작업으로 표시되지 않았는지 확인한다. `work in progress` 레이블을 사용하는 PR은 아직 리뷰할 준비가 되지 않은 PR이다.
3. 리뷰할 PR을 선택한 후, 다음을 통해 변경 사항을 이해한다.
- PR 설명을 통해 변경 사항을 이해하고, 연결된 이슈 읽기
- 다른 리뷰어의 의견 읽기
- **Files changed** 탭을 클릭하여 변경된 파일과 행 보기
- **Conversation** 탭의 맨 아래에 있는 PR의 빌드 확인 섹션으로 스크롤하여 **deploy/netlify** 행의 **Details** 링크를 클릭하고 Netlify 미리보기 빌드의 변경 사항을 확인
4. **Files changed** 탭으로 이동하여 리뷰를 시작한다.
1. 코멘트을 달려는 줄 옆에 있는 `+` 기호를 클릭한다.
2. 행에 대한 의견을 작성하고 **Add single comments**(작성할 의견이 하나만 있는 경우) 또는 **Start a review**(작성할 의견이 여러 개인 경우)를 클릭한다.
3. 완료되면, 페이지 상단에서 **Review changes** 를 클릭한다. 여기에서
리뷰에 대한 요약을 추가하고(기여자에게 긍정적인 의견을 남겨주기 바란다!),
PR을 승인하거나, 의견을 보내거나 필요에 따라 변경을 요청할 수 있다. 새로운 기여자는
항상 **Comment** 를 선택해야 한다.
## 리뷰 체크리스트
리뷰할 때, 다음을 시작점으로 사용한다.
### 언어와 문법
- 언어나 문법에 명백한 오류가 있는가? 무언가를 표현하는 더 좋은 방법이 있는가?
- 더 간단한 단어로 대체될 수 있는 복잡하거나 오래된 단어가 있는가?
- 비 차별적 대안으로 대체될 수 있는 단어, 용어 또는 문구가 있는가?
- 단어 선택과 대소문자는 [스타일 가이드](/docs/contribute/style/style-guide/)를 따르는가?
- 더 짧고 간결하게 만들 수 있는 긴 문장이 있는가?
- 목록이나 표로 더 잘 표현할 수 있는 긴 단락이 있는가?
### 콘텐츠
- 쿠버네티스 사이트의 다른 곳에도 비슷한 콘텐츠가 있는가?
- 콘텐츠가 오프-사이트, 개별 업체, 또는 공개되지 않은 소스 문서에 과도하게 링크되는가?
### 웹 사이트
- 이 PR이 페이지 제목, slug/alias 또는 앵커(anchor) 링크를 변경 또는 제거하는가? 그렇다면, 이 PR의 결과로 끊어진 링크가 있는가? slug를 변경 없이 페이지 제목을 변경하는 등의 다른 옵션이 있는가?
- PR이 새로운 페이지를 소개하는가? 그렇다면,
- 페이지가 올바른 [페이지 템플릿](/docs/contribute/style/page-templates/)과 연관된 Hugo 단축 코드를 사용하는가?
- 섹션의 측면 탐색에 페이지가 올바르게 나타나는가?
- 페이지가 [문서 홈](/ko/docs/home/) 목록에 나타나야 하는가?
- 변경 사항이 Netlify 미리보기에 표시되는가? 목록, 코드 블록, 표, 메모 및 이미지에 특히 주의한다.
### 기타
오타나 공백과 같은 작은 이슈의 PR인 경우, 코멘트 앞에 `nit:` 를 추가한다. 이를 통해 문서의 저자는 이슈가 긴급하지 않다는 것을 알 수 있다.
{{% /capture %}}