diff --git a/content/ko/docs/contribute/_index.md b/content/ko/docs/contribute/_index.md index 62b98b68d3..4676db9617 100644 --- a/content/ko/docs/contribute/_index.md +++ b/content/ko/docs/contribute/_index.md @@ -18,8 +18,15 @@ card: {{< note >}} 일반적인 쿠버네티스에 기여하는 방법에 대한 자세한 내용은 [기여자 문서](https://www.kubernetes.dev/docs/)를 참고한다. + +또한, 쿠버네티스 기여에 대한 내용은 +{{< glossary_tooltip text="CNCF" term_id="cncf" >}} +[문서](https://contribute.cncf.io/contributors/projects/#kubernetes) +를 참고한다. {{< /note >}} +--- + 이 웹사이트는 [쿠버네티스 SIG Docs](/ko/docs/contribute/#sig-docs에-참여)에 의해서 관리됩니다. 쿠버네티스 문서 기여자들은 diff --git a/content/ko/docs/contribute/advanced.md b/content/ko/docs/contribute/advanced.md index e40ebc71c1..047dfe37a8 100644 --- a/content/ko/docs/contribute/advanced.md +++ b/content/ko/docs/contribute/advanced.md @@ -136,7 +136,7 @@ SIG Docs의 공동 의장 역할을 할 수 있다. 다음과 같은 책임을 가진다. - SIG Docs가 우수한 문서화를 통해 개발자의 행복을 극대화하는 데 집중한다. -- 스스로가 [커뮤니티 행동 강령](https://github.com/cncf/foundation/blob/master/code-of-conduct-languages/ko.md)을 준수하여 예를 보이고, SIG 멤버들이 지킬 수 있도록 책임을 진다. +- 스스로가 [커뮤니티 행동 강령](https://github.com/cncf/foundation/blob/main/code-of-conduct-languages/ko.md)을 준수하여 예를 보이고, SIG 멤버들이 지킬 수 있도록 책임을 진다. - 기여에 대한 새로운 지침을 확인하여 SIG에 대한 모범 사례를 배우고 설정한다. - SIG 회의를 예약하고 진행한다. 주간 상태 업데이트, 브랜치별 회고/기획 세션과 필요에 따라 그 외 세션을 진행한다. - KubeCon 이벤트 및 기타 컨퍼런스에서 문서 스프린트를 스케줄링하고 진행한다. diff --git a/content/ko/docs/contribute/new-content/open-a-pr.md b/content/ko/docs/contribute/new-content/open-a-pr.md index 0871800715..daf6932a16 100644 --- a/content/ko/docs/contribute/new-content/open-a-pr.md +++ b/content/ko/docs/contribute/new-content/open-a-pr.md @@ -15,13 +15,15 @@ card: [새 기능 문서화](/docs/contribute/new-content/new-features/)를 참고한다. {{< /note >}} -새 콘텐츠 페이지를 기여하거나 기존 콘텐츠 페이지를 개선하려면, 풀 리퀘스트(PR)를 연다. [시작하기 전에](/ko/docs/contribute/new-content/#before-you-begin) 섹션의 모든 요구 사항을 준수해야 한다. - -변경 사항이 작거나, git에 익숙하지 않은 경우, [GitHub을 사용하여 변경하기](#github을-사용하여-변경하기)를 읽고 페이지를 편집하는 방법을 알아보자. - -변경 사항이 많으면, [로컬 포크에서 작업하기](#fork-the-repo)를 읽고 컴퓨터에서 로컬로 변경하는 방법을 배운다. +새 콘텐츠 페이지를 기여하거나 기존 콘텐츠 페이지를 개선하려면, 풀 리퀘스트(PR)를 연다. +[시작하기 전에](/ko/docs/contribute/new-content/#before-you-begin) 섹션의 +모든 요구 사항을 준수해야 한다. +변경 사항이 적거나, git에 익숙하지 않은 경우, +[GitHub을 사용하여 변경하기](#github을-사용하여-변경하기)를 읽고 페이지를 편집하는 방법을 알아보자. +변경 사항이 많으면, [로컬 포크에서 작업하기](#fork-the-repo)를 읽고 +컴퓨터에서 로컬로 변경하는 방법을 배운다. @@ -61,7 +63,7 @@ class tasks,tasks2 white class id1 k8s {{}} -***그림 - GitHub 상에서 PR을 여는 단계*** +그림 - GitHub 상에서 PR을 여는 단계 1. 이슈가 있는 페이지에서, 오른쪽 상단에 있는 연필 아이콘을 선택한다. 페이지 하단으로 스크롤 하여 **페이지 편집하기** 를 선택할 수도 있다. @@ -91,7 +93,8 @@ class id1 k8s - **Allow edits from maintainers** 체크박스는 선택된 상태로 둔다. {{< note >}} - PR 설명은 리뷰어가 변경 사항을 이해하는 데 유용한 방법이다. 자세한 내용은 [PR 열기](#open-a-pr)를 참고한다. + PR 설명은 리뷰어가 변경 사항을 이해하는 데 유용한 방법이다. + 자세한 내용은 [PR 열기](#open-a-pr)를 참고한다. {{}} 7. **Create pull request** 를 선택한다. @@ -120,7 +123,8 @@ GitHub 사용자 이름을 코멘트로 남긴다. git에 익숙하거나, 변경 사항이 몇 줄보다 클 경우, 로컬 포크로 작업한다. -컴퓨터에 [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)이 설치되어 있는지 확인한다. git UI 애플리케이션을 사용할 수도 있다. +컴퓨터에 [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)이 설치되어 있는지 확인한다. +git UI 애플리케이션을 사용할 수도 있다. 아래 그림은 로컬 포크에서 작업할 때의 단계를 나타낸다. 상세 사항도 소개되어 있다. @@ -151,7 +155,8 @@ class 1,2,3,3a,4,5,6 grey class S,T spacewhite class changes,changes2 white {{}} -***그림 - 로컬 포크에서 변경 사항 작업하기*** + +그림 - 로컬 포크에서 변경 사항 작업하기 ### kubernetes/website 리포지터리 포크하기 @@ -201,7 +206,10 @@ class changes,changes2 white 이를 통해 변경을 시작하기 전에 로컬 리포지터리가 최신 상태인지 확인한다. {{< note >}} - 이 워크플로는 [쿠버네티스 커뮤니티 GitHub 워크플로](https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md)와 다르다. 포크에 업데이트를 푸시하기 전에 로컬의 `main` 복사본을 `upstream/main` 와 병합할 필요가 없다. + 이 워크플로는 + [쿠버네티스 커뮤니티 GitHub 워크플로](https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md) + 와 다르다. + 포크에 업데이트를 푸시하기 전에 로컬의 `main` 복사본을 `upstream/main` 와 병합할 필요가 없다. {{< /note >}} ### 브랜치 만들기 @@ -211,14 +219,16 @@ class changes,changes2 white - 기존 콘텐츠를 개선하려면, `upstream/main` 를 사용한다. - 기존 기능에 대한 새로운 콘텐츠를 작성하려면, `upstream/main` 를 사용한다. - 현지화된 콘텐츠의 경우, 현지화 규칙을 사용한다. 자세한 내용은 [쿠버네티스 문서 현지화](/ko/docs/contribute/localization_ko/)를 참고한다. - - 다가오는 쿠버네티스 릴리스의 새로운 기능에 대해서는 기능 브랜치(feature branch)를 사용한다. 자세한 정보는 [릴리스 문서화](/docs/contribute/new-content/new-features/)를 참고한다. + - 다가오는 쿠버네티스 릴리스의 새로운 기능에 대해서는 기능 브랜치(feature branch)를 사용한다. + 자세한 정보는 [릴리스 문서화](/docs/contribute/new-content/new-features/)를 참고한다. - 콘텐츠 재구성과 같이 여러 SIG Docs 기여자들이 협업하는 장기적인 작업에는, 해당 작업을 위해 작성된 특정 기능 브랜치를 사용한다. 브랜치 선택에 도움이 필요하면, 슬랙 채널 `#sig-docs` 에 문의한다. -2. 1단계에서 식별된 브랜치를 기반으로 새 브랜치를 작성한다. 이 예에서는 기본 브랜치가 `upstream/main` 라고 가정한다. +2. 1단계에서 식별된 브랜치를 기반으로 새 브랜치를 작성한다. + 이 예에서는 기본 브랜치가 `upstream/main` 라고 가정한다. ```bash git checkout -b upstream/main @@ -268,7 +278,8 @@ class changes,changes2 white ``` {{< 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)를 사용하지 말자. 나중에 풀 리퀘스트 설명에 추가할 + 커밋 메시지에 [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 >}} @@ -280,39 +291,34 @@ class changes,changes2 white ### 로컬에서 변경 사항 미리보기 {#preview-locally} -변경 사항을 푸시하거나 풀 리퀘스트를 열기 전에 변경 사항을 로컬에서 미리 보는 것이 좋다. 미리보기를 사용하면 빌드 오류나 마크다운 형식 문제를 알아낼 수 있다. +변경 사항을 푸시하거나 풀 리퀘스트를 열기 전에 변경 사항을 로컬에서 미리 보는 것이 좋다. +미리보기를 사용하면 빌드 오류나 마크다운 형식 문제를 알아낼 수 있다. -website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할 수 있다. 도커 이미지 빌드는 느리지만 [Hugo 단축코드](/docs/contribute/style/hugo-shortcodes/)를 표시하므로, 디버깅에 유용할 수 있다. +website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할 수 있다. +도커 이미지 빌드는 느리지만 [Hugo 단축코드](/docs/contribute/style/hugo-shortcodes/)를 표시하므로, +디버깅에 유용할 수 있다. {{< tabs name="tab_with_hugo" >}} {{% tab name="Hugo 컨테이너" %}} {{< note >}} -아래 명령은 도커를 기본 컨테이너 엔진으로 사용한다. 이 동작을 무시하려면 `CONTAINER_ENGINE` 환경 변수를 설정한다. +아래 명령은 도커를 기본 컨테이너 엔진으로 사용한다. +이 동작을 무시하려면 `CONTAINER_ENGINE` 환경 변수를 설정한다. {{< /note >}} 1. 로컬에서 이미지를 빌드한다. + _Hugo 도구 자체에 대한 변경을 테스트하는 경우에만 이 단계가 필요하다._ - ```bash - # docker 사용(기본값) - make container-image - - ### 또는 ### - - # podman 사용 - CONTAINER_ENGINE=podman make container-image + ```shell + # 터미널에서 명령 실행 (필요에 따라) + make container-serve ``` -2. 로컬에서 `kubernetes-hugo` 이미지를 빌드한 후, 사이트를 빌드하고 서비스한다. +2. 컨테이너에서 Hugo를 시작한다. - ```bash - # docker 사용(기본값) + ```shell + # 터미널에서 실행 make container-serve - - ### 또는 ### - - # podman 사용 - CONTAINER_ENGINE=podman make container-serve ``` 3. 웹 브라우저에서 `https://localhost:1313` 로 이동한다. Hugo는 @@ -326,18 +332,19 @@ website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할 또는, 컴퓨터에 `hugo` 명령을 설치하여 사용한다. -1. [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/main/netlify.toml)에 지정된 [Hugo](https://gohugo.io/getting-started/installing/) 버전을 설치한다. +1. [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/main/netlify.toml)에 지정된 + [Hugo](https://gohugo.io/getting-started/installing/) 버전을 설치한다. 2. website 리포지터리를 업데이트하지 않았다면, `website/themes/docsy` 디렉터리가 비어 있다. -테마의 로컬 복제본이 없으면 사이트를 빌드할 수 없다. website 테마를 업데이트하려면, 다음을 실행한다. + 테마의 로컬 복제본이 없으면 사이트를 빌드할 수 없다. website 테마를 업데이트하려면, 다음을 실행한다. - ```bash + ```shell git submodule update --init --recursive --depth 1 ``` 3. 터미널에서, 쿠버네티스 website 리포지터리로 이동하여 Hugo 서버를 시작한다. - ```bash + ```shell cd /website hugo server --buildFuture ``` @@ -354,6 +361,7 @@ website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할 ### 포크에서 kubernetes/website로 풀 리퀘스트 열기 {#open-a-pr} 아래 그림은 당신의 포크에서 K8s/website 저장소로 PR을 여는 단계를 보여 준다. 상세 사항은 아래에 등장한다. + @@ -379,7 +387,8 @@ classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:b class 1,2,3,4,5,6,7,8 grey class first,second white {{}} -***그림 - 당신의 포크에서 K8s/website 저장소로 PR을 여는 단계*** + +그림 - 당신의 포크에서 K8s/website 저장소로 PR을 여는 단계 1. 웹 브라우저에서 [`kubernetes/website`](https://github.com/kubernetes/website/) 리포지터리로 이동한다. 2. **New Pull Request** 를 선택한다. @@ -387,29 +396,36 @@ class first,second white 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** 버튼을 선택한다. + - 관련된 GitHub 이슈가 있는 경우, `Fixes #12345` 또는 `Closes #12345` 를 설명에 포함한다. + 이렇게 하면 GitHub의 자동화 기능이 PR을 병합한 후 언급된 이슈를 닫는다. + 다른 관련된 PR이 있는 경우, 이들 PR도 연결한다. + - 구체적인 내용에 대한 조언이 필요한 경우, + 원하는 질문을 리뷰어가 생각해볼 수 있도록 설명에 포함한다. + +7. **Create pull request** 버튼을 선택한다. 축하한다! 여러분의 풀 리퀘스트가 [풀 리퀘스트](https://github.com/kubernetes/website/pulls)에 열렸다. - -PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www.netlify.com/)를 사용하여 미리보기를 배포하려고 시도한다. +PR을 연 후, GitHub는 자동 테스트를 실행하고 +[Netlify](https://www.netlify.com/)를 사용하여 미리보기를 배포하려고 시도한다. - Netlify 빌드가 실패하면, 자세한 정보를 위해 **Details** 를 선택한다. - - Netlify 빌드가 성공하면, **Details** 를 선택하면 변경 사항이 적용된 쿠버네티스 website의 커밋하기 직전의 버전(staged version)이 열린다. 리뷰어가 변경 사항을 확인하는 방법이다. + - Netlify 빌드가 성공하면, **Details** 를 선택하면 변경 사항이 적용된 쿠버네티스 website의 커밋하기 + 직전의 버전(staged version)이 열린다. 리뷰어가 변경 사항을 확인하는 방법이다. -또한 GitHub는 리뷰어에게 도움을 주기 위해 PR에 레이블을 자동으로 할당한다. 필요한 경우 직접 추가할 수도 있다. 자세한 내용은 [이슈 레이블 추가와 제거](/ko/docs/contribute/review/for-approvers/#이슈-레이블-추가와-제거)를 참고한다. +또한 GitHub는 리뷰어에게 도움을 주기 위해 PR에 레이블을 자동으로 할당한다. 필요한 경우 직접 추가할 수도 있다. +자세한 내용은 [이슈 레이블 추가와 제거](/ko/docs/contribute/review/for-approvers/#이슈-레이블-추가와-제거)를 참고한다. ### 로컬에서 피드백 해결 1. 변경한 후, 이전 커밋을 수정한다. - ```bash + ```shell git commit -a --amend ``` @@ -421,7 +437,8 @@ PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www. 3. `git push origin ` 를 사용해서 변경 사항을 푸시하고 Netlify 테스트를 다시 실행한다. {{< note >}} - 수정하는 대신 `git commit -m` 을 사용하는 경우, 병합하기 전에 [커밋을 스쿼시](#커밋-스쿼시하기)해야 한다. + 수정하는 대신 `git commit -m` 을 사용하는 경우, + 병합하기 전에 [커밋을 스쿼시](#커밋-스쿼시하기)해야 한다. {{< /note >}} #### 리뷰어의 변경 @@ -430,35 +447,38 @@ PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www. 1. 원격 포크에서 커밋을 가져오고 작업 브랜치를 리베이스한다. - ```bash + ```shell git fetch origin git rebase origin/ ``` 2. 리베이스한 후, 포크에 새로운 변경 사항을 강제로 푸시한다. - ```bash + ```shell git push --force-with-lease origin ``` #### 충돌 병합 및 리베이스 {{< 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` 에서 도움을 요청한다. +자세한 내용은 [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의 모든 병합 충돌을 해결해야 한다. +다른 기여자가 다른 PR에서 동일한 파일에 대한 변경 사항을 커밋하면, 병합 충돌이 발생할 수 있다. +PR의 모든 병합 충돌을 해결해야 한다. 1. 포크를 업데이트하고 로컬 브랜치를 리베이스한다. - ```bash + ```shell git fetch origin git rebase origin/ ``` 그런 다음 포크에 변경 사항을 강제로 푸시한다. - ```bash + ```shell git push --force-with-lease origin ``` @@ -477,7 +497,8 @@ PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www. 이 명령의 결과에 여러 파일이 충돌된 것으로 표시된다. -4. 충돌하는 각 파일을 열고 충돌 마커(`>>>`,`<<<` 그리고 `===`)를 찾는다. 충돌을 해결하고 충돌 마커를 삭제한다. +4. 충돌한 각 파일을 열고 충돌 마커(`>>>`,`<<<` 그리고 `===`)를 찾는다. + 충돌을 해결하고 충돌 마커를 삭제한다. {{< note >}} 자세한 내용은 [충돌이 표시되는 방법](https://git-scm.com/docs/git-merge#_how_conflicts_are_presented)을 참고한다. @@ -485,12 +506,13 @@ PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www. 5. 변경 세트에 파일을 추가한다. - ```bash + ```shell git add ``` + 6. 리베이스를 계속한다. - ```bash + ```shell git rebase --continue ``` @@ -500,7 +522,7 @@ PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www. 8. 브랜치를 포크에 강제로 푸시한다. - ```bash + ```shell git push --force-with-lease origin ``` @@ -509,10 +531,13 @@ PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www. ### 커밋 스쿼시하기 {{< note >}} -자세한 내용은 [Git 도구 - 히스토리 다시 쓰기](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History)를 참고하거나, 슬랙 채널 `#sig-docs` 에서 도움을 요청한다. +자세한 내용은 [Git 도구 - 히스토리 다시 쓰기](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History)를 참고하거나, +슬랙 채널 `#sig-docs` 에서 도움을 요청한다. {{< /note >}} -PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을 단일 커밋으로 스쿼시해야 한다. PR의 **Commits** 탭에서 또는 `git log` 명령을 로컬에서 실행하여 커밋 수를 확인할 수 있다. +PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을 단일 커밋으로 스쿼시해야 한다. +PR의 **Commits** 탭에서 또는 `git log` 명령을 로컬에서 실행하여 +커밋 수를 확인할 수 있다. {{< note >}} 여기서는 `vim` 을 커맨드 라인 텍스트 편집기로 사용하는 것을 가정한다. @@ -520,15 +545,16 @@ PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을 1. 대화식 리베이스를 시작한다. - ```bash + ```shell git rebase -i HEAD~ ``` - 커밋을 스쿼시하는 것은 일종의 리베이스이다. git의 `-i` 스위치는 리베이스를 대화형으로 할 수 있게 한다. `HEAD~` 는 리베이스를 위해 살펴볼 커밋 수를 나타낸다. + 커밋을 스쿼시하는 것은 일종의 리베이스이다. git의 `-i` 스위치는 리베이스를 대화형으로 할 수 있게 한다. + `HEAD~` 는 리베이스를 위해 살펴볼 커밋 수를 나타낸다. 출력은 다음과 비슷하다. - ```bash + ```none pick d875112ca Original commit pick 4fa167b80 Address feedback 1 pick 7d54e15ee Address feedback 2 @@ -540,7 +566,9 @@ PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을 # 이 행들은 순서를 바꿀 수 있다. 이들은 위에서 아래로 실행된다. ``` - 출력의 첫 번째 섹션에는 리베이스의 커밋이 나열된다. 두 번째 섹션에는 각 커밋에 대한 옵션이 나열되어 있다. `pick` 단어를 바꾸면 리베이스가 완료되었을 때 커밋 상태가 변경된다. + 출력의 첫 번째 섹션에는 리베이스의 커밋이 나열된다. + 두 번째 섹션에는 각 커밋에 대한 옵션이 나열되어 있다. + `pick` 단어를 바꾸면 리베이스가 완료되었을 때 커밋 상태가 변경된다. 리베이스를 하는 목적인 `squash` 와 `pick` 에 집중한다. @@ -552,7 +580,7 @@ PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을 다음의 원본 텍스트를 변경한다. - ```bash + ```none pick d875112ca Original commit pick 4fa167b80 Address feedback 1 pick 7d54e15ee Address feedback 2 @@ -560,13 +588,14 @@ PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을 아래와 같이 변경한다. - ```bash + ```none 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` 만 남긴다. + 이것은 커밋 `4fa167b80 Address feedback 1` 과 `7d54e15ee Address feedback 2` 를 `d875112ca Original commit` 으로 스쿼시한다. + 타임라인의 일부로 `d875112ca Original commit` 만 남긴다. 3. 파일을 저장하고 종료한다. @@ -578,14 +607,15 @@ PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을 ## 다른 리포지터리에 기여하기 -[쿠버네티스 프로젝트](https://github.com/kubernetes)에는 50개 이상의 리포지터리가 포함되어 있다. 이러한 리포지터리에는 사용자용 도움말 텍스트, 오류 메시지, API 레퍼런스 또는 코드 주석과 같은 문서가 포함되어 있다. +[쿠버네티스 프로젝트](https://github.com/kubernetes)에는 50개 이상의 리포지터리가 포함되어 있다. +이러한 리포지터리에는 사용자용 도움말 텍스트, 오류 메시지, API 레퍼런스 +또는 코드 주석과 같은 문서가 포함되어 있다. 개선하려는 텍스트가 보이면, GitHub을 사용하여 쿠버네티스 조직의 모든 리포지터리를 검색한다. 이를 통해 어디에 이슈나 PR을 제출할지를 파악할 수 있다. -각 리포지터리에는 고유한 프로세스와 절차가 있다. 여러분이 이슈를 -제기하거나 PR을 제출하기 전에, 그 리포지터리의 `README.md`, `CONTRIBUTING.md` 그리고 -`code-of-conduct.md`(만약 이들 문서가 있다면)를 읽어본다. +각 리포지터리에는 고유한 프로세스와 절차가 있다. 여러분이 이슈를 제기하거나 PR을 제출하기 전에, +그 리포지터리의 `README.md`, `CONTRIBUTING.md` 그리고 `code-of-conduct.md`(만약 이들 문서가 있다면)를 읽어본다. 대부분의 리포지터리에는 이슈와 PR 템플릿이 사용된다. 팀의 프로세스에 대한 느낌을 얻으려면 열린 이슈와 PR을 살펴보자. 이슈나 PR을 제출할 때 diff --git a/content/ko/docs/contribute/participate/_index.md b/content/ko/docs/contribute/participate/_index.md index 9f874351b0..80983b9215 100644 --- a/content/ko/docs/contribute/participate/_index.md +++ b/content/ko/docs/contribute/participate/_index.md @@ -93,9 +93,8 @@ PR 소유자에게 조언하는데 활용된다. ## 병합 작업 방식 -풀 리퀘스트 요청이 콘텐츠를 발행하는데 사용하는 -브랜치에 병합되면, 해당 콘텐츠는 https://kubernetes.io 에 공개된다. 게시된 콘텐츠의 -품질을 높히기 위해 SIG Docs 승인자가 풀 리퀘스트를 병합하는 것을 제한한다. +풀 리퀘스트 요청이 콘텐츠를 발행하는데 사용하는 브랜치에 병합되면, 해당 콘텐츠는 https://kubernetes.io 에 공개된다. +게시된 콘텐츠의 품질을 높히기 위해 SIG Docs 승인자가 풀 리퀘스트를 병합하는 것을 제한한다. 작동 방식은 다음과 같다. - 풀 리퀘스트에 `lgtm` 과 `approve` 레이블이 있고, `hold` 레이블이 없고, diff --git a/content/ko/docs/contribute/participate/roles-and-responsibilities.md b/content/ko/docs/contribute/participate/roles-and-responsibilities.md index 091dac7059..f816a12191 100644 --- a/content/ko/docs/contribute/participate/roles-and-responsibilities.md +++ b/content/ko/docs/contribute/participate/roles-and-responsibilities.md @@ -32,7 +32,7 @@ GitHub 계정을 가진 누구나 쿠버네티스에 기여할 수 있다. SIG D - [슬랙](https://slack.k8s.io/) 또는 [SIG docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에 개선을 제안한다. -[CLA에 서명](/ko/docs/contribute/new-content/#sign-the-cla) 후에 누구나 다음을 할 수 있다. +[CLA에 서명](https://github.com/kubernetes/community/blob/master/CLA.md) 후에 누구나 다음을 할 수 있다. - 기존 콘텐츠를 개선하거나, 새 콘텐츠를 추가하거나, 블로그 게시물 또는 사례연구 작성을 위해 풀 리퀘스트를 연다. - 다이어그램, 그래픽 자산 그리고 포함할 수 있는 스크린캐스트와 비디오를 제작한다. diff --git a/content/ko/docs/contribute/review/for-approvers.md b/content/ko/docs/contribute/review/for-approvers.md index 5b99cd02a6..3ded883231 100644 --- a/content/ko/docs/contribute/review/for-approvers.md +++ b/content/ko/docs/contribute/review/for-approvers.md @@ -181,7 +181,7 @@ SIG Docs가 처리 방법을 문서화할 정도로 다음과 같은 유형의 ### 블로그 이슈 -[쿠버네티스 블로그](https://kubernetes.io/blog/) 항목은 시간이 지남에 따라 +[쿠버네티스 블로그](/blog/) 항목은 시간이 지남에 따라 구식이 될 것으로 예상한다. 따라서, 1년 미만의 블로그 항목만 유지 관리한다. 1년이 지난 블로그 항목과 관련된 이슈일 경우, 수정하지 않고 이슈를 닫는다. @@ -221,3 +221,5 @@ https://github.com/kubernetes/kubernetes 에서 문서에 대한 이슈인 경우 이 이슈를 다시 여십시오. ``` + +