Skip to content

Latest commit

 

History

History
269 lines (209 loc) · 16.5 KB

CONTRIBUTING-ko.md

File metadata and controls

269 lines (209 loc) · 16.5 KB
Raw

기여 가이드라인

helm.sh 웹사이트 및 문서에 대한 기여 가이드입니다. 헬름의 기본 프로젝트는 helm/helm으로 이동하세요.

헬름은 GitHub 풀 리퀘스트를 통해 기여를 받습니다. 이 문서는 기여하는 데 도움이 되는 프로세스를 간략히 설명합니다.

보안 이슈 신고

대부분의 경우 헬름에서 버그를 발견하면 GitHub 이슈를 사용하여 신고해야 합니다. 그러나 보안 취약성 을 신고하는 경우 cncf-kubernetes-helm-security@lists.cncf.io 이메일로 신고해주세요. 이것은 이슈가 악용되기 전에 해결할 수 있는 기회를 줄 것입니다.

당신의 작업에 서명해주세요

서명(sign-off)은 커밋 메시지 끝에 있는 간단한 줄입니다. 모든 커밋은 서명이 있어야 합니다. 귀하의 서명은 패치를 작성했거나 자료를 기여할 권한이 있음을 증명합니다. 아래 개발자 증명서(developercertificate.org에서 발췌)에 동의하는 경우, 규칙은 매우 간단합니다.

원본 개발자 증명서
버전 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

모든 사용자는 이 라이센스 문서의 사본을 복사하여
배포할 수 있지만 변경할 수는 없습니다.

원본 개발자 증명서 1.1

본 프로젝트에 기여함으로써 저는 다음 사항을 보증합니다:

(a) 해당 기여의 전부 또는 일부를 제가 작성했으며,
    파일에 명시된 오픈 소스 라이센스에 따라
    제출할 권리가 있습니다. 또는

(b) 해당 기여는 제가 아는 한 적합한 오픈 소스
    라이센스에 따라 적용되었으며, 해당 라이센스에
    따라 (다른 라이센스로 제출할 수 있는 권한이
    없는 경우) 파일에 표시된 것과 동일한 오픈
    소스 라이센스로 제가 작성한 전부 또는 일부의
    수정 작업을 제출할 권리가 있습니다.
    또는

(c) 해당 기여는 (a), (b) 또는 (c)를 인증한
    다른 사람이 직접 제공했으며, 제가 수정하지
    않았습니다.

(d) 저는 해당 프로젝트와 기여를 공개하고 기여
    기록(본인의 서명과 함께 제출한 모든 개인
    정보 포함)이 무기한 유지되며 해당 프로젝트
    또는 관련 오픈 소스 라이센스와 일치하도록
    재배포될 수 있음을 이해하고 동의합니다.

모든 git 커밋 메시지에 한 줄을 추가하기만 하면 됩니다.

Signed-off-by: Joe Smith <joe.smith@example.com>

실명을 사용해주세요. (죄송하지만, 가명 또는 익명의 기여는 허용되지 않습니다.)

user.name 과 user.email git config를 설정하면 git commit -s 로 자동으로 커밋에 서명할 수 있습니다.

참고: git 설정 정보가 올바르게 지정된 경우 git log 를 보면 커밋 정보가 다음과 같습니다.

Author: Joe Smith <joe.smith@example.com>
Date:   Thu Feb 2 11:41:15 2018 -0800

    Update README

    Signed-off-by: Joe Smith <joe.smith@example.com>

Author 와 Signed-off-by 줄이 일치하는 것에 주목해주세요. 만약 일치하지 않는다면 자동 DCO 검사에서 PR을 거부할 것입니다.

지원 채널

당신이 사용자 혹은 기여자라면 공식 지원 채널은 다음과 같습니다.

새로운 이슈를 열거나 새로운 풀 리퀘스트를 보내기 전에 해당 프로젝트를 검색하는 것이 도움이 됩니다. 사용자가 겪은 이슈를 다른 사용자가 이미 보고했거나 저희가 이미 알고 있는 이슈일 수 있습니다. 슬랙 채널에서 물어보는 것도 도움이 될 수 있습니다.

이슈

이슈는 헬름 프로젝트와 관련된 모든 항목을 추적하는 기본 방법으로 사용됩니다.

이슈 유형

5가지 유형의 이슈가 있습니다(각 이슈마다 해당 레이블이 있음).

  • question/support: 향후 참조를 위해 기록하기를 원하는 지원 또는 기능 관련 문의가 있습니다. 일반적으로 슬랙 채널에 저장하기에 너무 복잡한 또는 큰 질문이거나 커뮤니티 전체에서 특별한 관심을 갖는 질문입니다. 논의에 따라 feature 또는 bug 이슈로 바뀔 수 있습니다.
  • proposal: 대규모 커뮤니티 논의가 필요한 새로운 아이디어 또는 기능을 제안하는 (이 글과 같은) 이슈에 사용됩니다. 이렇게 하면 기능이 실제로 개발되기 전에 커뮤니티의 다른 사용자로부터 피드백을 받을 수 있습니다. 해당 레이블은 작은 이슈에 필요하진 않습니다. 기능의 제안 필요 여부 결정은 핵심 관리자에게 달려 있습니다. 모든 제안 이슈는 해당 레이블과 "Proposal: [제목의 나머지 부분]" 이라는 제목이 있어야 합니다. 제안은 feature 가 될 수 있으며 마일스톤은 필요하지 않습니다.
  • feature: 이 이슈는 완료될 때까지 특정 기능 요청 및 아이디어를 추적합니다. proposal 에서 바뀔 수도 있고 이슈 사이즈에 따라 개별적으로 제출될 수 있습니다.
  • bug: 코드와 함께 버그를 추적하는 이슈입니다.
  • docs: 문서 관련 문제(예: 누락 또는 미완)를 추적합니다.

이슈 생명 주기

이슈 생명 주기는 주로 핵심 관리자에 의해 관리되지만, 헬름에 기여하는 사람들에게도 좋은 정보입니다. 모든 유형의 이슈는 동일한 생명 주기를 따릅니다. 차이점은 아래에 설명되어 있습니다.

  1. 이슈 생성
  2. 분류
    • 분류를 담당하는 관리자가 해당 이슈에 대한 적절한 레이블을 적용합니다. 여기에는 우선 순위, 유형, 메타데이터(예: good first issue) 레이블이 포함됩니다. 저희가 추적할 유일한 이슈 우선 순위는 이 이슈가 "중요한지" 여부입니다. 향후 추가 레이블이 필요하면 추가하겠습니다.
    • (필요한 경우) 간결하고 명확하게 이슈를 설명하기 위해 제목을 정리하세요. 또한 제안의 제목은 "Proposal: [제목의 나머지 부분]"으로 서두를 떼야 합니다.
    • 이슈를 올바른 마일스톤에 추가합니다. 질문 이슈일 경우, 질문에 답변할 때까지 이슈를 마일스톤 추가하는 것에 대해 염려하지 마세요.
    • 저희는 작업일에 적어도 한 번 이상 이 과정을 시도합니다.
  3. 논의
    • feature 또는 bug 로 레이블이 지정된 이슈는 이를 해결하는 PR에 연결해야 합니다.
    • feature 또는 bug 이슈를 작업하는 사람(관리자 또는 커뮤니티의 누군가)은 해당 이슈를 직접 자신에게 배정하거나 해당 이슈를 처리하고 있다는 내용의 코멘트를 작성해야 합니다.
    • proposal 및 support/question 이슈는 해결될 때까지 또는 30일 이상 활발하지 않은 경우에도 계속 열려 있어야 합니다. 이렇게 하면 이슈 대기열을 관리 가능한 크기로 유지하고 잡음을 줄일 수 있습니다. 이슈가 계속 열려 있어야 하는 경우 keep open 레이블을 추가할 수 있습니다.
  4. 이슈 종결

패치에 기여하는 방법

  1. 아직 서명하지 않은 경우 기여자 라이센스 계약에 서명하세요(위 세부 정보 참조).
  2. 원하는 저장소를 포크하여 코드 변경 사항을 개발하고 테스트하세요.
  3. 풀 리퀘스트를 보내주세요.

코딩 규약 및 표준은 공식 개발자 문서에 설명되어 있습니다.

풀 리퀘스트

모든 좋은 오픈 소스 프로젝트와 마찬가지로, 저희는 PR(풀 리퀘스트)을 사용하여 코드 수정을 추적합니다.

PR 생명 주기

  1. PR 생성
    • PR은 일반적으로 이슈를 해결하기 위해 생성되거나 특정 이슈를 해결하는 다른 PR의 하위 집합이 됩니다.
    • 저희는 현재 진행 중인 PR을 환영합니다. 아직 진행 중이지만 다른 사람들이 보기에 유용한 중요 작업을 추적할 수 있는 좋은 방법입니다. PR이 진행 중인 작업의 경우 반드시 "WIP: [제목]"으로 제목을 시작해야 합니다. PR을 리뷰할 준비가 되면 제목에서 "WIP"를 제거합니다.
    • 특정 이슈와 관련된 PR을 보내는 것이 바람직하지만 필수 사항은 아닙니다. 해당 PR이 급한 해결책이라면 이슈가 적절하지 않게 종결될 수 있는 상황이 있을 수 있습니다. 이 경우 PR 설명란에 세부 정보를 넣어주세요.
  2. 분류
    • 분류를 담당하는 관리자가 해당 이슈에 대한 적절한 레이블을 적용합니다. 모든 레이블이 적용된 후에는 최소한 사이즈 레이블, bug 또는 feature, awaiting review 가 포함되어야 합니다. 레이블 정의에 대한 자세한 내용은 레이블 섹션을 참조합니다.
    • PR을 올바른 마일스톤에 추가합니다. 이는 PR이 닫는 이슈와 동일해야 합니다.
  3. 리뷰 배정
    • 리뷰에 awaiting review 라는 레이블이 표시되면 관리자는 스케줄이 허용하는 대로 리뷰합니다. 이슈를 제기한 관리자는 리뷰에 대해 자체 요청(self-request)해야 합니다.
    • size/large 레이블이 있는 PR은 병합하기 전에 관리자로부터 2개의 리뷰 승인이 필요합니다. size/medium 또는 size/small 인 경우 관리자의 판단에 따릅니다.
  4. 리뷰/논의
    • 모든 리뷰는 GitHub 리뷰 도구를 사용하여 완료됩니다.
    • "Comment(주석)" 리뷰는 답변해야 하는 코드 관련 질문이 있을 때 사용해야 하지만 코드 변경은 포함되지 않습니다. 이러한 유형의 리뷰는 승인에 포함되지 않습니다.
    • "Changes Requested(변경 요청)" 리뷰는 코드를 병합하기 전에 수정해야 함을 나타냅니다.
    • 리뷰어는 필요에 따라 레이블을 갱신해야 합니다(예: needs rebase).
  5. 질문에 답변하거나 코드를 수정하여 의견을 반영합니다.
  6. LGTM (Looks good to me)
    • 리뷰어가 리뷰를 완료하고 코드가 병합될 준비가 된 것으로 보이면 "Approve(승인)" 리뷰는 기여자와 다른 관리자에게 코드를 리뷰한 후 병합 준비가 완료되었음을 알리는 데 사용됩니다.
  7. 병합(merge) 또는 종결(close)
    • PR은 병합될 때까지 또는 30일 이상 활발하지 않은 경우 열려 있어야 합니다. 이렇게 하면 PR 대기열을 관리 가능한 크기로 유지하고 잡음을 줄일 수 있습니다. PR이 계속 열려 있어야 하는 경우 (WIP의 경우처럼), keep open 레이블을 추가할 수 있습니다.
    • PR을 병합하기 전에 PR에 한 개 이상의 LGTM이 필요한지 여부를 결정하기 위해 아래 사이즈 레이블 항목을 참조하세요.
    • PR 소유자가 OWNERS 파일에 포함되어 있는 경우 해당 사용자는 반드시 자신의 PR을 병합하거나 다른 OWNER에게 명시적으로 요청해야 합니다.
    • PR의 소유자가 OWNERS에 포함되어 있지 않은 경우, 모든 핵심 관리자가 PR을 병합할 수 있습니다.

문서 PR

문서 PR은 다른 PR과 동일한 수명 주기를 따릅니다. 또한 docs 레이블로 레이블이 지정됩니다. 문서의 경우 철자, 문법, 명료성에 특히 주의를 기울여야 합니다(코드의 주석만큼 중요하지 않음).

분류자 (Triager)

매주 목요일 공개 스탠드업 회의를 시작으로 핵심 관리자 중 한 명이 "분류자" 역할을 하게 됩니다. 이 담당자는 일주일 내내 새로운 PR 및 이슈에 대한 분류를 담당하게 됩니다.

레이블

다음 표에서는 헬름에 사용되는 모든 레이블 유형을 정의합니다. 카테고리별로 나뉩니다.

공통 레이블

레이블 설명
bug 이슈를 버그 또는 PR을 버그 수정으로 표시합니다.
critical 이슈 또는 PR을 중요한 것으로 표시합니다. 이것은 PR이나 이슈를 다루는 것이 최우선이며 가능한 한 빨리 해결되어야 한다는 것을 의미합니다.
docs 이슈 또는 PR이 문서 변경임을 나타냅니다.
feature 이슈를 기능 요청으로 표시하거나 PR을 기능 구현으로 표시합니다.
keep open 이슈 또는 PR을 30일간 사용되지 않는 상태로 열어 둬야 함을 나타냅니다.
refactor 이슈가 코드 개선이며 버그를 고치거나 추가 기능을 추가하지 않음을 나타냅니다.

이슈용 레이블

레이블 설명
help wanted 이슈를 해결하기 위해 커뮤니티의 도움이 필요하다고 표시합니다.
proposal 이슈를 제안으로 표시합니다.
question/support 이슈를 요청이나 질문으로 표시합니다.
good first issue 이슈를 헬름을 처음 접하는 사용자에게 좋은 첫 이슈로 표시합니다.
wont fix 이슈가 논의되었으며 구현되지 않을 것임(또는 제안의 경우 받았음)을 나타냅니다.

PR용 레이블

레이블 설명
awaiting review PR이 분류되었으며 다른 사용자가 리뷰할 준비가 되었음을 나타냅니다
breaking PR이 코드를 변경한다는 것을 나타냅니다 (예: API 변경)
in progress 아직 리뷰되지 않았어도 관리자가 PR을 보고 있음을 나타냅니다
needs rebase PR이 병합되기 전 리베이스(rebase)할 필요가 있음을 나타냅니다
needs pick PR이 기능 브랜치(일반적으로 버그 수정 브랜치)로 체리픽(cherry-pick)할 필요가 있음을 나타냅니다. 체리픽했다면 picked 레이블을 적용하고 해당 레이블을 제거해야 합니다
picked 해당 PR은 기능 브랜치로 체리픽했다는 것을 나타냅니다

사이즈 레이블

사이즈 레이블은 PR이 얼마나 "위험"한지를 나타내는 데 사용됩니다. 아래 가이드라인은 레이블을 배정하는 데 사용되지만, 궁극적으로 관리자에 의해 변경 될 수 있습니다. 예를 들어 PR이 한 파일에서 30 줄만 변경하더라도 주요 기능이 바뀐다면 여러 명의 서명이 필요하므로 size/L 로 레이블이 지정될 가능성이 높습니다. 반대로 작은 기능을 추가하지만 모든 경우를 다루기 위해 150 줄의 테스트가 필요한 PR은 줄 수가 아래에 정의된 것보다 많더라도 size/S 로 레이블을 지정할 수 있습니다.

핵심 관리자에 의해 제출되는 PR은 사이즈에 상관없이 한 명의 추가 관리자 승인만 필요로 합니다. 이렇게 하면 코드베이스(codebase)에 도입된 중요한 PR을 알고 있는 관리자가 두 명 이상 있게 됩니다.

레이블 설명
size/XS 생성된 파일은 무시하고 0~9줄을 변경하는 PR을 나타냅니다. 변경 사항에 따라 테스트가 거의 필요하지 않을 수 있습니다.
size/S 생성된 파일은 무시하고 10-29줄을 변경하는 PR을 나타냅니다. 소량의 수동 테스트만 필요할 수 있습니다.
size/M 생성된 파일은 무시하고 30-99줄을 변경하는 PR을 나타냅니다. 수동 유효성 검사가 필요합니다.
size/L 생성된 파일은 무시하고 100-499줄을 변경하는 PR을 나타냅니다. 이 작업은 병합하기 전에 철저히 테스트해야 하며 항상 2개의 승인이 필요합니다.
size/XL 생성된 파일은 무시하고 500-999 줄을 변경하는 PR을 나타냅니다. 이 작업은 병합하기 전에 철저히 테스트해야 하며 항상 2개의 승인이 필요합니다.
size/XXL 생성된 파일은 무시하고 1000개 이상의 행을 변경하는 PR을 나타냅니다. 이 작업은 병합하기 전에 철저히 테스트해야 하며 항상 2개의 승인이 필요합니다.