[Hyperledger Fabric v1.0] 7. CONTRIBUTING(기여): Contributions Welcome!(기부를 환영합니다.)

해당 글은 Hyperledger Fabric 페이지의 게시글을 번역 및 정리한 자료입니다.

원본 사이트 : http://hyperledger-fabric.readthedocs.io/en/release/CONTRIBUTING.html

 Contributions Welcome!(기부를 환영합니다.)

우리는 Hyperledger 프로젝트에 대한 여러 가지 기부를 환영하며 언제나 할 일이 많습니다!

먼저 참여하기 전에 Hyperledger 프로젝트의 행동 강령을 검토하십시오. 우리가 일을 민사 소중히하는 것이 중요합니다.

Install prerequisites(필수 구성요소 설치)

시작하기 전에 아직 수행하지 않은 경우, 블록 체인 응용 프로그램을 개발하거나 Hyperledger Fabric을 운영 할 플랫폼에 모든 필수 구성 요소가 설치되어 있는지 확인하고 싶을 수 있습니다.

Getting a Linux Foundation account(Linux Foundation 계정 얻기)

Hyperledger Fabric 프로젝트의 개발에 참여하려면 Linux Foundation 계정이 필요합니다. Gerrit, Jira 및 Wiki를 포함한 모든 Hyperledger 커뮤니티 개발 도구에 액세스하려면 LF ID를 사용해야합니다 (편집 전용).

Setting up your SSH key(SSH 키 설정하기)

Gerrit의 경우 검토를 위해 변경 세트를 제출하기 전에 공개 SSH 키를 등록해야합니다. LFID로 Gerrit에 로그인하고 브라우저 창의 오른쪽 상단에있는 이름을 클릭 한 다음 '설정'을 클릭하십시오. 왼쪽 여백에는 'SSH Public Keys'에 대한 링크가 표시됩니다. 공개 SSH 키를 복사하여 붙여 넣기하고 '추가'를 누르십시오.

Getting help(도움 받기)

작업 할 무언가를 찾고 있거나 문제를 디버깅하거나 문제 해결을 위해 전문가의 도움이 필요하다면 커뮤니티는 항상 도움을 청합니다. 우리는 채팅, IRC (freenode.net의 #hyperledger) 및 메일 링리스트에서 행 아웃을합니다. 우리 대부분은 물지 않습니다. 미소를 지으면 도움이 될 것입니다. 바보 같은 질문은 당신이 묻지 않는 질문입니다. 실제로 질문은 프로젝트를 개선하는 데 도움이되는 훌륭한 방법입니다.

Requirements and Use Cases(요구사항 및 사용 사례)

We have a Requirements WG that is documenting use cases and from those use cases deriving requirements. If you are interested in contributing to this effort, please feel free to join the discussion in chat.

Reporting bugs(버그 보고)

사용자이고 버그를 발견하면 JIRA를 사용하여 문제를 제출하십시오. 문제를 재현하기 위해 다른 사람에게 충분한 정보를 제공하십시오. 프로젝트 관리자 중 한 명이 24 시간 내에 문제에 응답해야합니다. 그렇지 않은 경우 댓글에 문제를 표시하고 검토를 요청하십시오. 채팅에서 # fabric-maintainers 채널에 게시 할 수도 있습니다.

Fixing issues and working stories(문제 해결 및 실무 사례)

문제점 목록을 검토하고 관심있는 것을 찾으십시오. "도움이 필요한"목록을 확인할 수도 있습니다. 상대적으로 솔직하고 성취 가능한 것으로부터 시작하는 것이 현명하며, 아무도 이미 배정되지는 않았습니다. 아무도 할당되지 않은 경우 문제를 자신에게 할당하십시오. 합리적인 시간에 끝내지 못하면 배정을 철저히하거나 철회하거나 조금 더 시간이 필요할 경우 적극적으로 문제를 해결하고 있다고 말하는 의견을 추가하십시오.

Making Feature/Enhancement Proposals(기능 / 향상 제안 만들기)

JIRA를 검토하십시오. 동일한 기능에 대해 아직 공개되지 않은 (또는 최근에 닫힌) 제안이 없는지 확인하십시오. JIRA Epic, Story, Improvement 중 가장 적합한 것으로 보이는 쪽을 열어서 기능이 무엇을 할 것인지를 명시한 제안서의 "한 페이저"를 링크하거나 인라인 할 것을 제안합니다. 가능한 경우 구현 방법을 설명합니다. 기능이 필요한 특정 유스 케이스 (들)을 식별하는 것과 같은 기능을 추가해야하는 이유와 기능을 구현할 때 어떤 이점이 있는지에 대한 사례를 작성하는 것도 도움이 될 것입니다. JIRA 이슈가 생성되고 "하나의 호출기"가 첨부되거나, 설명 필드에 인라인되거나, 공개적으로 액세스 가능한 문서에 대한 링크가 설명에 추가되면, hyperledger-fabric@lists.hyperledger로 소개 이메일을 보냅니다. JIRA 이슈를 링크하는 org 메일 링리스트, 그리고 피드백 요청하기.

제안 된 기능에 대한 토론은 JIRA 이슈 자체에서 수행되어야합니다. 그래서 우리는 디자인 토론을 어디서 찾을 수 있는지에 대해 지역 사회 내에서 일관된 패턴을 유지해야합니다.

새로운 기능에 대해 세 명 이상의 Fabric 관리자가 지원을 받으면 기능의 관련 CR이 병합 될 가능성이 크게 높아집니다.

Working with a local clone and Gerrit(로컬 클론 및 Gerrit 작업)

우리는 코드 기여를 관리하기 위해 Gerrit를 사용하고 있습니다. 익숙하지 않은 경우 계속하기 전에이 문서를 검토하십시오.

Gerrit에 익숙해지고 lf-sandbox 프로젝트로 놀아 봤다면 로컬 개발 환경을 설정할 준비가되었습니다.

그런 다음 로컬 개발 환경에서 프로젝트를 빌드하여 모든 것이 올바르게 설정되었는지 확인하십시오.

로깅 제어 문서에서는 Fabric 내의 다양한 구성 요소의 로깅 수준을 조정하는 방법에 대해 설명합니다. 마지막으로 모든 소스 파일에는 라이센스 헤더가 포함되어야합니다. 원칙 작성자의 저작권 선언문을 포함하도록 수정되었습니다.

What makes a good change request?(좋은 변경 요청은 무엇입니까?)

• 한 번에 하나씩 변경하십시오. 5가 아니라 3이 아니라 10이 아닙니다. 오직 하나뿐입니다. 왜? 변화의 폭발 영역을 제한하기 때문입니다. 회귀 분석을 통해 더 많은 코드에 영향을 미치는 복합 변경이있는 경우보다 범인 커밋을 식별하는 것이 훨씬 쉽습니다.
• 변경 사항에 대한 JIRA 이야기에 대한 링크를 포함하십시오. 왜? 왜냐하면 a) 우리는 우리가 전달할 수 있다고 생각하는 것을 더 잘 판단하기 위해 속도를 추적하기를 원하기 때문입니다. 왜냐하면 우리는 변화를보다 효과적으로 정당화 할 수 있기 때문입니다. 많은 경우 제안 된 변경 사항에 대해 몇 가지 논의가 있어야하며 변경 자체의 문제와 다시 연결하려고합니다.
• 모든 변경 사항에 대해 단위 테스트 및 통합 테스트 (또는 기존 테스트 변경)를 포함하십시오. 이것은 단지 행복한 경로 테스트 중 하나를 의미하지 않습니다. 또한 모든 방어 코드의 부정 테스트를 통해 입력 오류를 정확하게 잡아낼 수 있음을 의미합니다. 코드를 작성할 때 코드를 테스트하고 변경 내용이 주장하는 바를 증명하는 테스트를 제공해야합니다. 왜? 왜냐하면 이것 없이는 현재 코드베이스가 실제로 작동하는지 아무런 단서도 없기 때문입니다.
• 단위 테스트에는 외부 종속성이 없어야합니다. 언어에 대한 테스트 또는 동등한 테스트를 통해 단위 테스트를 실행할 수 있어야합니다. 외부 의존성이 필요한 테스트 (예 : 다른 구성 요소를 실행하기 위해 스크립팅해야 함)에는 적절한 조롱이 필요합니다. 다른 것은 단위 테스트가 아니며 정의에 의한 통합 테스트입니다. 왜? 많은 오픈 소스 개발자가 테스트 주도 개발을하기 때문에. 그들은 코드가 변경되면 자동으로 테스트를 호출하는 디렉토리에 시계를 배치합니다. 이것은 코드 변경 사이에 전체 빌드를 실행하는 것보다 훨씬 효율적입니다. 효과적인 단위 테스트를 작성하는 데 유의해야 할 좋은 기준 집합에 대해서는 단위 테스트의 정의를 참조하십시오.
• CR 당 코드 줄을 최소화하십시오. 왜? 관리자는 낮에도 일할 수 있습니다. 1,000 또는 2,000 개의 LOC 변경을 보내면 해당 코드를 모두 검토하는 데 얼마나 걸릴 것으로 생각하십니까? 가능한 경우 <200-300 LOC로 변경하십시오. 더 큰 변화가 있다면, 그것을 여러 독립적 인 변화로 분해하십시오. 새로운 기능의 요구 사항을 충족시키기 위해 새로운 기능을 추가하는 경우 테스트와 함께 별도로 추가 한 다음이를 사용하여 기능을 제공하는 코드를 작성하십시오. 물론 항상 예외가 있습니다. 작은 변화를 추가하고 300 LOC 테스트를 추가하면 광범위한 영향을 미치는 변경이나 생성 된 코드 묶음 (protobufs 등)을 변경해야하는 경우 용서받을 수 있습니다. 다시 예외가있을 수 있습니다.
• 참고 : 큰 변경 요청 (예 : 300 명이 넘는 LOC가있는 사람들은 -2를받지 못하는 것보다 더 가능성이 높습니다.이 지침에 따라 변경 사항을 리팩터링하라는 메시지가 나타납니다.
• 관련이없는 한 변경 요청을 쌓아서는 안됩니다 (예 : 이전 CR과 동일한 지점에서 CR 제출). 이렇게하면 병합 충돌을 최소화하고 변경 내용을 더 빨리 병합 할 수 있습니다. 요청을 스택하면 이전 요구의 검토 주석으로 인해 후속 요청이 보류 될 수 있습니다.
• 의미있는 커밋 메시지를 작성하십시오. 의미있는 50 자 (또는 그 이하)의 문자 제목과 빈 줄을 추가하고 변경 사항에 대한보다 포괄적 인 설명을 추가하십시오. 각 변경 사항에는 변경 사항에 해당하는 JIRA 식별자가 포함되어야합니다 (예 : [FAB-1234]). 이것은 제목에있을 수 있지만 커밋 메시지의 본문에 있어야합니다. Gerrit는 자동으로 JIRA 항목에 대한 하이퍼 링크를 생성합니다.

e.g.

[FAB-1234] fix foobar() panic

Fix [FAB-1234] added a check to ensure that when foobar(foo string) is called,
that there is a non-empty string argument.

마지막으로, 응답하십시오. Rebase가 필요한 시점에 검토 주석이 포함 된 변경 요청을 fester에 보내지 마십시오. 병합을 가져 오는 데 더 많은 시간이 걸리고 병합 충돌을 수정하기 위해 더 많은 작업이 추가됩니다.

Communication(통신)

Google은 통신을 위해 RocketChat을 사용하고 개발자 간의 화면 공유를 위해 Google 행 아웃 ™을 사용합니다. 우리의 개발 계획과 우선 순위 결정은 JIRA에서 이루어지며, 우리는 더 긴 실행 토론 / 결정을 메일 링리스트로 가져갑니다.

Maintainers(유지 관리자)

프로젝트의 유지 관리자는 검토를 위해 제출 된 모든 패치를 검토 및 병합해야하며 Hyperledger 프로젝트의 기술 운영위원회 (TSC)에서 제정 한 지침에 따라 프로젝트의 전반적인 기술적 방향을 안내합니다.

Becoming a maintainer(유지 관리자 되기)

이 프로젝트는 우리 헌장에 설명 된 바와 같이 개방형 거버넌스 모델에 따라 관리됩니다. 프로젝트 또는 하위 프로젝트는 유지 보수 담당자에 의해 주도됩니다. 새 하위 프로젝트는 프로젝트가 처음 승인 될 때 최상위 프로젝트의 기존 유지 보수자가 승인 할 초기 관리자 세트를 지정할 수 있습니다. 프로젝트의 관리자는 가끔씩 관리자를 추가하거나 제거하는 것을 고려할 것입니다. 기존 관리자는 MAINTAINERS.rst 파일에 변경 집합을 제출할 수 있습니다. 관리자가 8 명 미만인 경우 해당 프로젝트의 기존 유지 관리자 대다수가 변경 세트를 병합해야합니다. 기존의 관리자가 8 명 이상인 경우, 5 명 이상의 관리자가 제안서에 동의하면 변경 세트가 병합되고 관리자는 관리자 그룹에 추가됩니다 (또는 대안으로 제거됩니다). 명백한 사임, 행동 규범의 일부 위반 또는 일관성없는 가난한 판단의 시연.

Legal stuff(법률 물건)

참고 : 각 소스 파일에는 Apache Software License 2.0에 대한 라이센스 헤더가 있어야합니다. 라이센스 헤더의 템플릿을 참조하십시오.

우리는 가능한 한 쉽게 기부하도록 노력했습니다. 이는 기여의 법적 측면을 어떻게 처리하는지에 적용됩니다. 우리는 Linux® Kernel 커뮤니티가 코드 기여를 관리하는 데 사용하는 개발자 기원 1.1 (DCO)과 동일한 접근 방식을 사용합니다.

검토를 위해 패치를 제출할 때 개발자는 커밋 메시지에 사인 오프 문을 포함시켜야합니다.

다음은 제출자가 DCO를 승인한다는 것을 나타내는 Signed-by-by 회선의 예입니다.

Signed-off-by: John Doe <john.doe@hisdomain.com>

git commit -s를 사용하는 저장소.-s