Third Korean l10n work for release 1.18
- 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
committed by
Claudia J.Kang
Claudia J.Kang
parent
c74ce882ec
commit
ca62e21766
@@ -35,7 +35,7 @@ card:
|
||||
|
||||
1. CNCF [Contributor License Agreement](https://github.com/kubernetes/community/blob/master/CLA.md)에 서명합니다.
|
||||
2. [문서 리포지터리](https://github.com/kubernetes/website) 와 웹사이트의 [정적 사이트 생성기](https://gohugo.io)를 숙지합니다.
|
||||
3. [풀 리퀘스트 열기](/docs/contribute/new-content/open-a-pr/)와 [변경 검토](/docs/contribute/review/reviewing-prs/)의 기본 프로세스를 이해하도록 합니다.
|
||||
3. [풀 리퀘스트 열기](/docs/contribute/new-content/new-content/)와 [변경 검토](/docs/contribute/review/reviewing-prs/)의 기본 프로세스를 이해하도록 합니다.
|
||||
|
||||
일부 작업에는 쿠버네티스 조직에서 더 많은 신뢰와 더 많은 접근이 필요할 수 있습니다.
|
||||
역할과 권한에 대한 자세한 내용은
|
||||
@@ -44,6 +44,7 @@ card:
|
||||
## 첫 번째 기여
|
||||
|
||||
- [기여 개요](/docs/contribute/new-content/overview/)를 읽고 기여할 수 있는 다양한 방법에 대해 알아봅니다.
|
||||
- [kubernetes/website에 기여하기](https://github.com/kubernetes/website/contribute)를 참조하여 좋은 진입점이 되는 이슈를 찾을 수 있습니다.
|
||||
- 기존 문서에 대해 [GitHub을 사용해서 풀 리퀘스트 열거나](/docs/contribute/new-content/new-content/#changes-using-github) GitHub에서의 이슈 제기에 대해 자세히 알아봅니다.
|
||||
- 정확성과 언어에 대해 다른 쿠버네티스 커뮤니티 맴버의 [풀 리퀘스트 검토](/docs/contribute/review/reviewing-prs/)를 합니다.
|
||||
- 쿠버네티스 [컨텐츠](/docs/contribute/style/content-guide/)와 [스타일 가이드](/docs/contribute/style/style-guide/)를 읽고 정보에 대한 코멘트를 남길 수 있습니다.
|
||||
|
||||
@@ -206,6 +206,8 @@ egress | 이그레스, 송신(egress) |
|
||||
Endpoint | 엔드포인트 |
|
||||
entry point | 진입점 |
|
||||
Event | 이벤트 |
|
||||
evict | 축출하다 |
|
||||
eviction | 축출 |
|
||||
Exec | Exec |
|
||||
expose | 노출시키다 |
|
||||
extension | 익스텐션(extension) |
|
||||
@@ -273,7 +275,7 @@ Persistent Volume | 퍼시스턴트 볼륨 |
|
||||
Persistent Volume Claim | 퍼시스턴트 볼륨 클레임 |
|
||||
pipeline | 파이프라인 |
|
||||
placeholder pod | 플레이스홀더(placeholder) 파드 |
|
||||
Pod(파드) | 파드 |
|
||||
Pod | 파드 |
|
||||
Pod Preset | 파드 프리셋 |
|
||||
PodAntiAffinity | 파드안티어피니티(PodAntiAffinity) |
|
||||
PodDisruptionBudget | PodDisruptionBudget |
|
||||
@@ -325,6 +327,7 @@ Shell | 셸 |
|
||||
Sign In | 로그인 |
|
||||
Sign Out | 로그아웃 |
|
||||
skew | 차이(skew) |
|
||||
snippet | 스니펫(snippet) |
|
||||
spec | 명세, 스펙, 사양 |
|
||||
specification | 명세 |
|
||||
Stateful Set | 스테이트풀 셋 |
|
||||
|
||||
@@ -0,0 +1,4 @@
|
||||
---
|
||||
title: 새로운 콘텐츠 기여하기
|
||||
weight: 20
|
||||
---
|
||||
@@ -0,0 +1,484 @@
|
||||
---
|
||||
title: 풀 리퀘스트 열기
|
||||
slug: new-content
|
||||
content_template: templates/concept
|
||||
weight: 10
|
||||
card:
|
||||
name: contribute
|
||||
weight: 40
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< note >}}
|
||||
**코드 개발자**: 향후 쿠버네티스 릴리스의
|
||||
새로운 기능을 문서화하는 경우,
|
||||
[새 기능 문서화](/docs/contribute/new-content/new-features/)를 참고한다.
|
||||
{{< /note >}}
|
||||
|
||||
새 콘텐츠 페이지를 기여하거나 기존 콘텐츠 페이지를 개선하려면, 풀 리퀘스트(PR)를 연다. [시작하기 전에](/ko/docs/contribute/new-content/overview/#before-you-begin) 섹션의 모든 요구 사항을 준수해야 한다.
|
||||
|
||||
변경 사항이 작거나, git에 익숙하지 않은 경우, [GitHub을 사용하여 변경하기](#github을-사용하여-변경하기)를 읽고 페이지를 편집하는 방법을 알아보자.
|
||||
|
||||
변경 사항이 많으면, [로컬 포크에서 작업하기](#fork-the-repo)를 읽고 컴퓨터에서 로컬로 변경하는 방법을 배운다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## GitHub을 사용하여 변경하기
|
||||
|
||||
git 워크플로에 익숙하지 않은 경우, 풀 리퀘스트를
|
||||
여는 쉬운 방법이 있다.
|
||||
|
||||
1. 이슈가 있는 페이지에서, 오른쪽 상단에 있는 연필 아이콘을 선택한다.
|
||||
페이지 하단으로 스크롤 하여 **페이지 편집하기** 를 선택할 수도 있다.
|
||||
|
||||
2. GitHub 마크다운 편집기에서 수정한다.
|
||||
|
||||
3. 편집기 아래에서, **Propose file change** 양식을
|
||||
작성한다. 첫 번째 필드에서, 커밋 메시지 제목을 지정한다.
|
||||
두 번째 필드에는, 설명을 제공한다.
|
||||
|
||||
{{< note >}}
|
||||
커밋 메시지에 [GitHub 키워드](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword)를 사용하지 않는다. 나중에 풀 리퀘스트 설명에
|
||||
추가할 수 있다.
|
||||
{{< /note >}}
|
||||
|
||||
4. **Propose file change** 를 선택한다.
|
||||
|
||||
5. **Create pull requests** 를 선택한다.
|
||||
|
||||
6. **Open a pull request** 화면이 나타난다. 양식을 작성한다.
|
||||
|
||||
- 풀 리퀘스트의 **Subject** 필드는 기본적으로 커밋의 요약으로 설정한다.
|
||||
필요한 경우 변경할 수 있다.
|
||||
- **Body** 는 만약 내용이 있다면, 확장된 커밋 메시지를 포함한다.
|
||||
그리고 일부 템플릿 텍스트를 포함한다.
|
||||
템플릿 텍스트에 필요한 세부 정보를 추가한 다음, 추가 템플릿 텍스트를 삭제한다.
|
||||
- **Allow edits from maintainers** 체크박스는 선택된 상태로 둔다.
|
||||
|
||||
{{< note >}}
|
||||
PR 설명은 리뷰어가 변경 사항을 이해하는 데 유용한 방법이다. 자세한 내용은 [PR 열기](#open-a-pr)를 참고한다.
|
||||
{{</ note >}}
|
||||
|
||||
7. **Create pull request** 를 선택한다.
|
||||
|
||||
### GitHub에서 피드백 해결
|
||||
|
||||
풀 리퀘스트를 병합하기 전에, 쿠버네티스 커뮤니티 회원은 이를 리뷰하고
|
||||
승인한다. `k8s-ci-robot` 은 이 페이지에 나와있는 가까운
|
||||
멤버에게 리뷰를 제안한다. 특정한 사람을 염두에 두고 있다면,
|
||||
GitHub 사용자 이름을 코멘트로 남긴다.
|
||||
|
||||
리뷰어가 변경을 요청하는 경우, 다음과 같이 한다.
|
||||
|
||||
1. **Files changed** 탭으로 이동 한다.
|
||||
2. 풀 리퀘스트에 의해 변경된 파일에서 연필(편집) 아이콘을
|
||||
선택한다.
|
||||
3. 요청된 변경에 대한 수정을 한다.
|
||||
4. 변경 사항을 커밋한다.
|
||||
|
||||
리뷰어를 기다리고 있는 경우, 7일마다 한 번씩 연락한다. 슬랙 채널 `#sig-docs` 에 메시지를 게시할 수도 있다.
|
||||
|
||||
리뷰가 완료되면, 리뷰어가 PR을 병합하고 몇 분 후에 변경 사항이 적용된다.
|
||||
|
||||
## 로컬 포크에서 작업하기 {#fork-the-repo}
|
||||
|
||||
git에 익숙하거나, 변경 사항이 몇 줄보다 클 경우,
|
||||
로컬 포크로 작업한다.
|
||||
|
||||
컴퓨터에 [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)이 설치되어 있는지 확인한다. git UI 애플리케이션을 사용할 수도 있다.
|
||||
|
||||
### kubernetes/website 리포지터리 포크하기
|
||||
|
||||
1. [`kubernetes/website`](https://github.com/kubernetes/website/) 리포지터리로 이동한다.
|
||||
2. **Fork** 를 선택한다.
|
||||
|
||||
### 로컬 클론 생성 및 업스트림 설정
|
||||
|
||||
3. 터미널 창에서, 포크를 클론한다.
|
||||
|
||||
```bash
|
||||
git clone git@github.com/<github_username>/website
|
||||
```
|
||||
|
||||
4. 새 `website` 디렉터리로 이동한다. `kubernetes/website` 리포지터리를 `upstream` 원격으로 설정한다.
|
||||
|
||||
```bash
|
||||
cd website
|
||||
|
||||
git remote add upstream https://github.com/kubernetes/website.git
|
||||
```
|
||||
|
||||
5. `origin` 과 `upstream` 리포지터리를 확인한다.
|
||||
|
||||
```bash
|
||||
git remote -v
|
||||
```
|
||||
|
||||
출력은 다음과 비슷하다.
|
||||
|
||||
```bash
|
||||
origin git@github.com:<github_username>/website.git (fetch)
|
||||
origin git@github.com:<github_username>/website.git (push)
|
||||
upstream https://github.com/kubernetes/website (fetch)
|
||||
upstream https://github.com/kubernetes/website (push)
|
||||
```
|
||||
|
||||
6. 포크의 `origin/master` 와 `kubernetes/website` 의 `upstream/master` 에서 커밋을 가져온다.
|
||||
|
||||
```bash
|
||||
git fetch origin
|
||||
git fetch upstream
|
||||
```
|
||||
|
||||
이를 통해 변경을 시작하기 전에 로컬 리포지터리가 최신 상태인지 확인한다.
|
||||
|
||||
{{< note >}}
|
||||
이 워크플로는 [쿠버네티스 커뮤니티 GitHub 워크플로](https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md)와 다르다. 포크에 업데이트를 푸시하기 전에 로컬의 `master` 복사본을 `upstream/master` 와 병합할 필요가 없다.
|
||||
{{< /note >}}
|
||||
|
||||
### 브랜치 만들기
|
||||
|
||||
1. 작업할 브랜치 기반을 결정한다.
|
||||
|
||||
- 기존 콘텐츠를 개선하려면, `upstream/master` 를 사용한다.
|
||||
- 기존 기능에 대한 새로운 콘텐츠를 작성하려면, `upstream/master` 를 사용한다.
|
||||
- 현지화된 콘텐츠의 경우, 현지화 규칙을 사용한다. 자세한 내용은 [쿠버네티스 문서 현지화](/ko/docs/contribute/localization_ko/)를 참고한다.
|
||||
- 다가오는 쿠버네티스 릴리스의 새로운 기능에 대해서는 기능 브랜치(feature branch)를 사용한다. 자세한 정보는 [릴리스 문서화](/docs/contribute/new-content/new-features/)를 참고한다.
|
||||
- 콘텐츠 재구성과 같이 여러 SIG Docs 기여자들이 협업하는 장기적인 작업에는,
|
||||
해당 작업을 위해 작성된 특정 기능 브랜치를
|
||||
사용한다.
|
||||
|
||||
브랜치 선택에 도움이 필요하면, 슬랙 채널 `#sig-docs` 에 문의한다.
|
||||
|
||||
2. 1단계에서 식별된 브랜치를 기반으로 새 브랜치를 작성한다. 이 예에서는 기본 브랜치가 `upstream/master` 라고 가정한다.
|
||||
|
||||
```bash
|
||||
git checkout -b <my_new_branch> upstream/master
|
||||
```
|
||||
|
||||
3. 텍스트 편집기를 사용하여 변경한다.
|
||||
|
||||
언제든지, `git status` 명령을 사용하여 변경한 파일을 본다.
|
||||
|
||||
### 변경 사항 커밋
|
||||
|
||||
풀 리퀘스트를 제출할 준비가 되면, 변경 사항을 커밋한다.
|
||||
|
||||
1. 로컬 리포지터리에서 커밋해야 할 파일을 확인한다.
|
||||
|
||||
```bash
|
||||
git status
|
||||
```
|
||||
|
||||
출력은 다음과 비슷하다.
|
||||
|
||||
```bash
|
||||
On branch <my_new_branch>
|
||||
Your branch is up to date with 'origin/<my_new_branch>'.
|
||||
|
||||
Changes not staged for commit:
|
||||
(use "git add <file>..." to update what will be committed)
|
||||
(use "git checkout -- <file>..." to discard changes in working directory)
|
||||
|
||||
modified: content/en/docs/contribute/new-content/contributing-content.md
|
||||
|
||||
no changes added to commit (use "git add" and/or "git commit -a")
|
||||
```
|
||||
|
||||
2. **Changes not staged for commit** 에 나열된 파일을 커밋에 추가한다.
|
||||
|
||||
```bash
|
||||
git add <your_file_name>
|
||||
```
|
||||
|
||||
각 파일에 대해 이 작업을 반복한다.
|
||||
|
||||
3. 모든 파일을 추가한 후, 커밋을 생성한다.
|
||||
|
||||
```bash
|
||||
git commit -m "Your commit message"
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
커밋 메시지에 [GitHub 키워드](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword)를 사용하지 말자. 나중에 풀 리퀘스트 설명에 추가할
|
||||
수 있다.
|
||||
{{< /note >}}
|
||||
|
||||
4. 로컬 브랜치와 새로운 커밋을 원격 포크로 푸시한다.
|
||||
|
||||
```bash
|
||||
git push origin <my_new_branch>
|
||||
```
|
||||
|
||||
### 로컬에서 변경 사항 미리보기 {#preview-locally}
|
||||
|
||||
변경 사항을 푸시하거나 풀 리퀘스트를 열기 전에 변경 사항을 로컬에서 미리 보는 것이 좋다. 미리보기를 사용하면 빌드 오류나 마크다운 형식 문제를 알아낼 수 있다.
|
||||
|
||||
website의 도커 이미지를 만들거나 Hugo를 로컬에서 실행할 수 있다. 도커 이미지 빌드는 느리지만 [Hugo 단축코드](/docs/contribute/style/hugo-shortcodes/)를 표시하므로, 디버깅에 유용할 수 있다.
|
||||
|
||||
{{< tabs name="tab_with_hugo" >}}
|
||||
{{% tab name="Hugo 컨테이너" %}}
|
||||
|
||||
1. 로컬에서 이미지를 빌드한다.
|
||||
|
||||
```bash
|
||||
make docker-image
|
||||
```
|
||||
|
||||
2. 로컬에서 `kubernetes-hugo` 이미지를 빌드한 후, 사이트를 빌드하고 서비스한다.
|
||||
|
||||
```bash
|
||||
make docker-serve
|
||||
```
|
||||
|
||||
3. 웹 브라우저에서 `https://localhost:1313` 로 이동한다. Hugo는
|
||||
변경 사항을 보고 필요에 따라 사이트를 다시 구축한다.
|
||||
|
||||
4. 로컬의 Hugo 인스턴스를 중지하려면, 터미널로 돌아가서 `Ctrl+C` 를 입력하거나,
|
||||
터미널 창을 닫는다.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="Hugo 커맨드 라인" %}}
|
||||
|
||||
또는, 컴퓨터에 `hugo` 명령을 설치하여 사용한다.
|
||||
|
||||
5. [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/master/netlify.toml)에 지정된 [Hugo](https://gohugo.io/getting-started/installing/) 버전을 설치한다.
|
||||
|
||||
6. 터미널에서, 쿠버네티스 website 리포지터리로 이동하여 Hugo 서버를 시작한다.
|
||||
|
||||
```bash
|
||||
cd <path_to_your_repo>/website
|
||||
hugo server
|
||||
```
|
||||
|
||||
7. 브라우저의 주소 표시줄에 `https://localhost:1313` 을 입력한다.
|
||||
|
||||
8. 로컬의 Hugo 인스턴스를 중지하려면, 터미널로 돌아가서 `Ctrl+C` 를 입력하거나,
|
||||
터미널 창을 닫는다.
|
||||
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
### 포크에서 kubernetes/website로 풀 리퀘스트 열기 {#open-a-pr}
|
||||
|
||||
1. 웹 브라우저에서 [`kubernetes/website`](https://github.com/kubernetes/website/) 리포지터리로 이동한다.
|
||||
2. **New Pull Request** 를 선택한다.
|
||||
3. **compare across forks** 를 선택한다.
|
||||
4. **head repository** 드롭다운 메뉴에서, 포크를 선택한다.
|
||||
5. **compare** 드롭다운 메뉴에서, 브랜치를 선택한다.
|
||||
6. **Create Pull Request** 를 선택한다.
|
||||
7. 풀 리퀘스트에 대한 설명을 추가한다.
|
||||
- **Title**(50자 이하): 변경 사항에 대한 의도를 요약한다.
|
||||
- **Description**: 변경 사항을 자세히 설명한다.
|
||||
- 관련된 GitHub 이슈가 있는 경우, `Fixes #12345` 또는 `Closes #12345` 를 설명에 포함한다. 이렇게 하면 GitHub의 자동화 기능이 PR을 병합한 후 언급된 이슈를 닫는다. 다른 관련된 PR이 있는 경우, 이들 PR도 연결한다.
|
||||
- 구체적인 내용에 대한 조언이 필요한 경우, 원하는 질문을 리뷰어가 생각해볼 수 있도록 설명에 포함한다.
|
||||
|
||||
8. **Create pull request** 버튼을 선택한다.
|
||||
|
||||
축하한다! 여러분의 풀 리퀘스트가 [풀 리퀘스트](https://github.com/kubernetes/website/pulls)에 열렸다.
|
||||
|
||||
|
||||
PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www.netlify.com/)를 사용하여 미리보기를 배포하려고 시도한다.
|
||||
|
||||
- Netlify 빌드가 실패하면, 자세한 정보를 위해 **Details** 를 선택한다.
|
||||
- Netlify 빌드가 성공하면, **Details** 를 선택하면 변경 사항이 적용된 쿠버네티스 website의 커밋하기 직전의 버전(staged version)이 열린다. 리뷰어가 변경 사항을 확인하는 방법이다.
|
||||
|
||||
또한 GitHub는 리뷰어에게 도움을 주기 위해 PR에 레이블을 자동으로 할당한다. 필요한 경우 직접 추가할 수도 있다. 자세한 내용은 [이슈 레이블 추가와 제거](/docs/contribute/review/for-approvers/#adding-and-removing-issue-labels)를 참고한다.
|
||||
|
||||
### 로컬에서 피드백 해결
|
||||
|
||||
1. 변경한 후, 이전 커밋을 수정한다.
|
||||
|
||||
```bash
|
||||
git commit -a --amend
|
||||
```
|
||||
|
||||
- `-a`: 모든 변경 사항을 커밋
|
||||
- `--amend`: 새로운 커밋을 만들지 않고, 이전 커밋을 수정한다.
|
||||
|
||||
2. 필요한 경우 커밋 메시지를 업데이트한다.
|
||||
|
||||
3. `git push origin <my_new_branch>` 를 사용해서 변경 사항을 푸시하고 Netlify 테스트를 다시 실행한다.
|
||||
|
||||
{{< note >}}
|
||||
수정하는 대신 `git commit -m` 을 사용하는 경우, 병합하기 전에 [커밋을 스쿼시](#커밋-스쿼시하기)해야 한다.
|
||||
{{< /note >}}
|
||||
|
||||
#### 리뷰어의 변경
|
||||
|
||||
때때로 리뷰어가 여러분의 풀 리퀘스트를 커밋한다. 다른 변경을 하기 전에, 커밋을 가져온다.
|
||||
|
||||
1. 원격 포크에서 커밋을 가져오고 작업 브랜치를 리베이스한다.
|
||||
|
||||
```bash
|
||||
git fetch origin
|
||||
git rebase origin/<your-branch-name>
|
||||
```
|
||||
|
||||
2. 리베이스한 후, 포크에 새로운 변경 사항을 강제로 푸시한다.
|
||||
|
||||
```bash
|
||||
git push --force-with-lease origin <your-branch-name>
|
||||
```
|
||||
|
||||
#### 충돌 병합 및 리베이스
|
||||
|
||||
{{< note >}}
|
||||
자세한 내용은 [Git 브랜치 - 기본 브랜치와 병합](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging#_basic_merge_conflicts), [고급 병합](https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging)을 참조하거나, 슬랙 채널 `#sig-docs` 에서 도움을 요청한다.
|
||||
{{< /note >}}
|
||||
|
||||
다른 기여자가 다른 PR에서 동일한 파일에 대한 변경 사항을 커밋하면, 병합 충돌이 발생할 수 있다. PR의 모든 병합 충돌을 해결해야 한다.
|
||||
|
||||
1. 포크를 업데이트하고 로컬 브랜치를 리베이스한다.
|
||||
|
||||
```bash
|
||||
git fetch origin
|
||||
git rebase origin/<your-branch-name>
|
||||
```
|
||||
|
||||
그런 다음 포크에 변경 사항을 강제로 푸시한다.
|
||||
|
||||
```bash
|
||||
git push --force-with-lease origin <your-branch-name>
|
||||
```
|
||||
|
||||
2. `kubernetes/website` 의 `upstream/master` 에 대한 변경 사항을 가져오고 브랜치를 리베이스한다.
|
||||
|
||||
```bash
|
||||
git fetch upstream
|
||||
git rebase upstream/master
|
||||
```
|
||||
|
||||
3. 리베이스의 결과를 검사한다.
|
||||
|
||||
```bash
|
||||
git status
|
||||
```
|
||||
|
||||
이 명령의 결과에 여러 파일이 충돌된 것으로 표시된다.
|
||||
|
||||
4. 충돌하는 각 파일을 열고 충돌 마커(`>>>`,`<<<` 그리고 `===`)를 찾는다. 충돌을 해결하고 충돌 마커를 삭제한다.
|
||||
|
||||
{{< note >}}
|
||||
자세한 내용은 [충돌이 표시되는 방법](https://git-scm.com/docs/git-merge#_how_conflicts_are_presented)을 참고한다.
|
||||
{{< /note >}}
|
||||
|
||||
5. 변경 세트에 파일을 추가한다.
|
||||
|
||||
```bash
|
||||
git add <filename>
|
||||
```
|
||||
6. 리베이스를 계속한다.
|
||||
|
||||
```bash
|
||||
git rebase --continue
|
||||
```
|
||||
|
||||
7. 필요에 따라 2단계에서 5단계를 반복한다.
|
||||
|
||||
모든 커밋을 적용한 후, `git status` 명령은 리베이스가 완료되었음을 나타낸다.
|
||||
|
||||
8. 브랜치를 포크에 강제로 푸시한다.
|
||||
|
||||
```bash
|
||||
git push --force-with-lease origin <your-branch-name>
|
||||
```
|
||||
|
||||
풀 리퀘스트에 더 이상 충돌이 표시되지 않는다.
|
||||
|
||||
|
||||
### 커밋 스쿼시하기
|
||||
|
||||
{{< note >}}
|
||||
자세한 내용은 [Git 도구 - 히스토리 다시 쓰기](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History)를 참고하거나, 슬랙 채널 `#sig-docs` 에서 도움을 요청한다.
|
||||
{{< /note >}}
|
||||
|
||||
PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을 단일 커밋으로 스쿼시해야 한다. PR의 **Commits** 탭에서 또는 `git log` 명령을 로컬에서 실행하여 커밋 수를 확인할 수 있다.
|
||||
|
||||
{{< note >}}
|
||||
여기서는 `vim` 을 커맨드 라인 텍스트 편집기로 사용하는 것을 가정한다.
|
||||
{{< /note >}}
|
||||
|
||||
1. 대화식 리베이스를 시작한다.
|
||||
|
||||
```bash
|
||||
git rebase -i HEAD~<number_of_commits_in_branch>
|
||||
```
|
||||
|
||||
커밋을 스쿼시하는 것은 일종의 리베이스이다. git의 `-i` 스위치는 리베이스를 대화형으로 할 수 있게 한다. `HEAD~<number_of_commits_in_branch` 는 리베이스를 위해 살펴볼 커밋 수를 나타낸다.
|
||||
|
||||
출력은 다음과 비슷하다.
|
||||
|
||||
```bash
|
||||
pick d875112ca Original commit
|
||||
pick 4fa167b80 Address feedback 1
|
||||
pick 7d54e15ee Address feedback 2
|
||||
|
||||
# 3d18sf680..7d54e15ee 를 3d183f680 으로 리베이스한다 (3개 명령)
|
||||
|
||||
...
|
||||
|
||||
# 이 행들은 순서를 바꿀 수 있다. 이들은 위에서 아래로 실행된다.
|
||||
```
|
||||
|
||||
출력의 첫 번째 섹션에는 리베이스의 커밋이 나열된다. 두 번째 섹션에는 각 커밋에 대한 옵션이 나열되어 있다. `pick` 단어를 바꾸면 리베이스가 완료되었을 때 커밋 상태가 변경된다.
|
||||
|
||||
리베이스를 하는 목적인 `squash` 와 `pick` 에 집중한다.
|
||||
|
||||
{{< note >}}
|
||||
자세한 내용은 [대화식 모드](https://git-scm.com/docs/git-rebase#_interactive_mode)를 참고한다.
|
||||
{{< /note >}}
|
||||
|
||||
2. 파일 편집을 시작한다.
|
||||
|
||||
다음의 원본 텍스트를 변경한다.
|
||||
|
||||
```bash
|
||||
pick d875112ca Original commit
|
||||
pick 4fa167b80 Address feedback 1
|
||||
pick 7d54e15ee Address feedback 2
|
||||
```
|
||||
|
||||
아래와 같이 변경한다.
|
||||
|
||||
```bash
|
||||
pick d875112ca Original commit
|
||||
squash 4fa167b80 Address feedback 1
|
||||
squash 7d54e15ee Address feedback 2
|
||||
```
|
||||
|
||||
이것은 커밋 `4fa167b80 Address feedback 1` 과 `7d54e15ee Address feedback 2` 를 `d875112ca Original commit` 으로 스쿼시한다. 타임라인의 일부로 `d875112ca Original commit` 만 남긴다.
|
||||
|
||||
3. 파일을 저장하고 종료한다.
|
||||
|
||||
4. 스쿼시된 커밋을 푸시한다.
|
||||
|
||||
```bash
|
||||
git push --force-with-lease origin <branch_name>
|
||||
```
|
||||
|
||||
## 다른 리포지터리에 기여하기
|
||||
|
||||
[쿠버네티스 프로젝트](https://github.com/kubernetes)에는 50개 이상의 리포지터리가 포함되어 있다. 이러한 리포지터리에는 사용자용 도움말 텍스트, 오류 메시지, API 레퍼런스 또는 코드 주석과 같은 문서가 포함되어 있다.
|
||||
|
||||
개선하려는 텍스트가 보이면, GitHub을 사용하여 쿠버네티스 조직의 모든 리포지터리를 검색한다.
|
||||
이를 통해 어디에 이슈나 PR을 제출할지를 파악할 수 있다.
|
||||
|
||||
각 리포지터리에는 고유한 프로세스와 절차가 있다. 여러분이 이슈를
|
||||
제기하거나 PR을 제출하기 전에, 그 리포지터리의 `README.md`, `CONTRIBUTING.md` 그리고
|
||||
`code-of-conduct.md`(만약 이들 문서가 있다면)를 읽어본다.
|
||||
|
||||
대부분의 리포지터리에는 이슈와 PR 템플릿이 사용된다. 팀의 프로세스에 대한
|
||||
느낌을 얻으려면 열린 이슈와 PR을 살펴보자. 이슈나 PR을 제출할 때
|
||||
가능한 한 상세하게 템플릿의 내용을 작성한다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
- 리뷰 프로세스에 대한 자세한 내용은 [리뷰하기](/ko/docs/contribute/reviewing/revewing-prs)를 읽어본다.
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,58 @@
|
||||
---
|
||||
title: 새로운 콘텐츠 기여하기에 대한 개요
|
||||
linktitle: 개요
|
||||
content_template: templates/concept
|
||||
main_menu: true
|
||||
weight: 5
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
이 섹션에는 새로운 콘텐츠를 기여하기 전에 알아야 할 정보가 있다.
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## 기여하기에 대한 기본
|
||||
|
||||
- 마크다운(Markdown)으로 쿠버네티스 문서를 작성하고 [Hugo](https://gohugo.io/)를 사용하여 쿠버네티스 사이트를 구축한다.
|
||||
- 소스는 [GitHub](https://github.com/kubernetes/website)에 있다. 쿠버네티스 문서는 `/content/ko/docs/` 에서 찾을 수 있다. 일부 참조 문서는 `update-imported-docs/` 디렉터리의 스크립트에서 자동으로 생성된다.
|
||||
- [페이지 템플릿](/docs/contribute/style/page-templates/)은 Hugo에서 문서 콘텐츠의 프리젠테이션을 제어한다.
|
||||
- 표준 Hugo 단축코드(shortcode) 이외에도 설명서에서 여러 [사용자 정의 Hugo 단축코드](/docs/contribute/style/hugo-shortcodes/)를 사용하여 콘텐츠 표시를 제어한다.
|
||||
- 문서 소스는 `/content/` 에서 여러 언어로 제공된다. 각 언어는 [ISO 639-1 표준](https://www.loc.gov/standards/iso639-2/php/code_list.php)에 의해 결정된 2문자 코드가 있는 자체 폴더가 있다. 예를 들어, 한글 문서의 소스는 `/content/ko/docs/` 에 저장된다.
|
||||
- 여러 언어로 문서화에 기여하거나 새로운 번역을 시작하는 방법에 대한 자세한 내용은 [현지화](/ko/docs/contribute/localization_ko/)를 참고한다.
|
||||
|
||||
## 시작하기 전에 {#before-you-begin}
|
||||
|
||||
### CNCF CLA 서명 {#sign-the-cla}
|
||||
|
||||
모든 쿠버네티스 기여자는 **반드시** [기여자 가이드](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md)를 읽고 [기여자 라이선스 계약(CLA)에 서명](https://github.com/kubernetes/community/blob/master/CLA.md)해야 한다.
|
||||
|
||||
CLA에 서명하지 않은 기여자의 풀 리퀘스트(pull request)는 자동 테스트에 실패한다. 제공한 이름과 이메일은 `git config` 에 있는 것과 일치해야 하며, git 이름과 이메일은 CNCF CLA에 사용된 것과 일치해야 한다.
|
||||
|
||||
### 사용할 Git 브랜치를 선택한다
|
||||
|
||||
풀 리퀘스트를 열 때는, 작업의 기반이 되는 브랜치를 미리 알아야 한다.
|
||||
|
||||
시나리오 | 브랜치
|
||||
:---------|:------------
|
||||
현재 릴리스의 기존 또는 새로운 영어 콘텐츠 | `master`
|
||||
기능 변경 릴리스의 콘텐츠 | `dev-release-<version>` 패턴을 사용하여 기능 변경이 있는 주 버전과 부 버전에 해당하는 브랜치. 예를 들어, `{{< latest-version >}}` 에서 기능이 변경된 경우, ``dev-{{< release-branch >}}`` 에 문서 변경을 추가한다.
|
||||
다른 언어로된 콘텐츠(현지화) | 현지화 규칙을 사용. 자세한 내용은 [현지화 브랜치 전략](/docs/contribute/localization/#branching-strategy)을 참고한다.
|
||||
|
||||
|
||||
어떤 브랜치를 선택해야 할지 잘 모르는 경우 슬랙의 `#sig-docs` 에 문의한다.
|
||||
|
||||
{{< note >}}
|
||||
풀 리퀘스트를 이미 제출했는데 기본 브랜치가 잘못되었다는 것을 알게 되면,
|
||||
제출자(제출자인 여러분만)가 이를 변경할 수 있다.
|
||||
{{< /note >}}
|
||||
|
||||
### PR 당 언어
|
||||
|
||||
PR 당 하나의 언어로 풀 리퀘스트를 제한한다. 여러 언어로 동일한 코드 샘플을 동일하게 변경해야 하는 경우 각 언어마다 별도의 PR을 연다.
|
||||
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -0,0 +1,14 @@
|
||||
---
|
||||
title: 변경 사항 리뷰하기
|
||||
weight: 30
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
이 섹션은 콘텐츠를 리뷰하는 방법에 대해 설명한다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -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 %}}
|
||||
@@ -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 %}}
|
||||
@@ -0,0 +1,9 @@
|
||||
---
|
||||
title: 문서 스타일 개요
|
||||
main_menu: true
|
||||
weight: 80
|
||||
---
|
||||
|
||||
이 섹션의 주제는 문서 작성 스타일, 컨텐츠 형식과
|
||||
구성, 쿠버네티스 문서화에 적합하게 사용자 정의된 Hugo 사용 방법에 대한
|
||||
가이드를 제공한다.
|
||||
Reference in New Issue
Block a user