기여하기

도큐사우루스 2 는 아직 개발중입니다. 하지만 많은 프로젝트 팀에서 이미 사용하고 있습니다. 우리는 도큐사우루스의 미래를 위해 함께 일할 수 있는 기여자를 언제나 환영합니다.

오픈 소스 가이드 웹사이트는 개인이나 커뮤니티, 기업에서 오픈 소스 프로젝트에 어떻게 참여하고 기여할 수 있는지에 대한 다양한 리소스를 제공합니다. 기여자 또는 오픈 소스를 처음 접하는 분들에게는 아래 가이드가 도움이 될 겁니다.

지켜야할 지침 #

페이스북은 프로젝트 참여자가 지켜야할 지침을 만들었습니다. 어떤 것을 할 수 있고 어떤 것은 제한된 행동인지 이해할 수 있도록 전체 지침을 먼저 읽어주세요.

함께 참여하세요!#

도큐사우루스에 기여하는 방법은 아주 많으며 코드를 작성하지 않고도 참여하는 방법도 다양합니다. 시작하는 데 도움이 되는 몇 가지 아이디어는 다음과 같습니다.

도큐사우루스 2 사용을 시작해보세요! 시작하기 가이드 문서를 따라해보세요. 여러분이 기대한 결과가 만들어졌나요? 그렇지 않다면 우리에게 필요한 개선 항목을 발견한 겁니다. 이슈를 등록해서 우리에게 문제를 알려주세요.
v2.0 관련 이슈를 살펴보세요. 여러분이 수정하고 싶은 이슈를 발견했다면 풀 리퀘스트를 요청해주세요. Good first issue 태그가 붙은 이슈는 기여를 시작하기 좋은 이슈를 가리킵니다.
더 좋은 문서를 만들 수 있도록 도와주세요. 내용이 잘 이해되지 않거나 개선할 부분을 발견했다면 이슈를 등록해주세요. 모든 v2 관련 문서의 계획과 작업에 대한 주요 이슈 목록을 확인해볼 수 있습니다. 목록 중에서 작업하고 싶은 문서를 찾아볼 수 있습니다.
커뮤니티 구성원들이 올린 기능 요구 사항을 살펴보고 작업할 수 있는 항목은 풀 리퀘스트를 요청할 수 있습니다.

다양한 기여는 언제나 환경합니다. 뭔가 참여하고 싶은데 도움이 필요하다면 트위터에서 @docusaurus를 언급해주시고 어떤 도움이 필요한지 알려주세요.

디스코드 채널에 참여하세요#

도큐사우루스 2 개발에 참여하고 싶다면 #docusaurus-2-dev 채널에 가입해주세요.

개발 프로세스#

도큐사우루스는 깃허브를 유일한 리소스로 사용합니다. 코어 개발팀은 깃허브와 직접 연결해서 작업을 진행합니다. 때문에 모든 변경 사항은 시작부터 공개되어 있습니다.

깃허브에서 변경된 사항이 승인되면 우리의 CI 시스템인 서클CI(CircleCI)에서 이를 확인합니다.

새로운 이슈 등록#

새로운 이슈를 작성할 때는 언제나 이슈 템플릿을 채워서 작성해주세요. 이 단계는 매우 중요합니다! 그렇게 하지 않으면 여러분의 이슈가 제때 적절하게 관리되지 않을 수 있습니다. 어렵게 생각할 필요는 없습니다. 새로운 이슈를 편하게 열어서 템플릿에 따라 필요한 정보를 수집하고 작성해주면 됩니다.

하나의 이슈, 하나의 버그: 하나의 이슈에서 하나의 버그만 다루도록 등록해주세요.
어떻게 이슈를 재현할 수 있는지 알려주세요: 이슈를 재현하기 위한 모든 순서를 나열해서 설명해주어야 합니다. 여러분이 남기신 버그 보고서를 읽는 개발자가 순서에 따라 최소한의 노력으로 이슈를 재현할 수 있어야 합니다.

버그 등록#

공개된 버그를 처리하기 위해 깃허브 이슈를 사용합니다. 문제를 발견하고 등록하기 전에 이슈 목록을 살펴보고 누군가 이미 등록한 이슈가 아닌지 확인해보세요. 아직 보고되지 않는 버그라고 생각된다면 버그 등록을 할 수 있습니다.

도큐사우루스 사용에 대한 질문은 도큐사우루스 트위터 계정 @docusaurus으로 문의해주시면 친절하게 답변해줄겁니다.

기능 요청이나 개선 사항도 이슈로 등록할 수 있습니다. 뭔가 구현되기를 바라는 것이 있다면 기능 요청 템플릿을 사용해 이슈를 등록해주세요.

보안 버그 등록#

페이스북은 보안 관련 버그에 대해서 안전한 처리를 위해 포상 프로그램을 운영하고 있습니다. 가능하다면 공개된 이슈로 등록하지는 말아주세요. 해당 페이지에서 설명한 프로세스에 따라 보안 버그를 처리합니다.

새로운 기능 테스트하기#

@canary npm 배포 태그를 사용하면 새로운 기능을 누구보다 먼저 테스트해볼 수 있습니다. 풀 리퀘스트가 병합되는 동시에 여러분의 사이트에 새로운 기능을 적용해볼 수 있습니다. 여러분의 참여는 공식적인 릴리스 전에 문제를 해결하는데 도움이 됩니다.

도큐사우루스 코드 작업#

설치#

Yarn이 설치되어 있는지 확인해주세요.
저장소를 복제한 후 저장소 루트에서 yarn install 명령을 실행합니다.
도큐사우루스 문서를 제공하는 로컬 개발 서버를 시작하려면 website 디렉터리로 이동해서 yarn start 명령을 실행합니다.

의미있는 커밋 메시지 작성하기#

여러분의 커밋 메시지 형식을 조금만 바꾸어주면 훨씬 좋은 프로그래머가 될 수 있습니다.

Format: <type>(<scope>): <subject>

<scope>는 옵션 항목입니다.

예

feat: allow overriding of webpack config^--^  ^------------^|     ||     +-> Summary in present tense.|+-------> Type: chore, docs, feat, fix, refactor, style, or test.

커밋 타입

feat: (사용자를 위한 새로운 기능. 빌드 스크립트를 위한 새로운 기능은 아닙니다)
fix: (사용자를 위한 버그 수정. 빌드 스크립트에 대한 수정은 아닙니다)
docs: (문서 내용 변경)
style: (코드 정렬, 빠진 세미콜론 채우기 등 기능에 영향을 주지 않는 코드 수정)
refactor: (변수 이름 변경같은 제품 코드 리팩토링)
test: (빠진 테스트를 추가하거나 테스트 리팩토링처럼 기능에 영향을 주지 않는 코드 수정)
chore: (그런트 태스크 업데이트처럼 기능에 영향을 주지 않는 코드 수정)

제목이 아니기 때문에 소문자로 작성해주세요!

코드 규칙#

스타일 가이드#

프리티어(Prettier)는 대부분의 코드 스타일 이슈를 미리 체크해줍니다. npm run prettier 명령으로 여러분의 코드 스타일 상태를 간단하게 체크해볼 수 있습니다.

하지만 프리티어가 처리하지 못하는 일부 스타일 문제가 남아있습니다.

일반 사항#

대단히 중요합니다: 다른 작업을 먼저 살펴보세요. 프로젝트에서 이미 사용하고 있는 스타일과 여러분의 스타일이 일치하는지 확인해보세요. 정렬 방식이나 파일명, 코드 네이밍, 문서 내 용어 등이 포함됩니다.
"Attractive"

문서#

80자마다 줄바꿈을 사용하지 마세요 - 문서 편집 시 사용하는 에디터에서 자동 줄바꿈(soft-wrap)을 설정해놓으세요.

풀 리퀘스트#

여러분의 첫 번째 풀 리퀘스트#

자 이제 여러분은 코드에 기여하기로 결심하고 작성한 코드에 대한 풀 리퀘스트를 요청합니다. 여러분이 많은 시간을 들여 진행한 작업에 대해 감사를 표합니다. 우리는 여러분과 협업하고 PR을 검토하기 위해 최선을 다할 겁니다.

풀 리퀘스트 요청이 처음이라면 아래 동영상에서 어떻게 할 수 있는지 배워볼 수 있습니다.

깃허브에서 오픈 소스 프로젝트에 기여하는 방법

여러분이 도큐사우루스 코드에 익숙해지고 기여 프로세스에 친숙해지도록 우리가 제공하는 기여를 시작하기 좋은 이슈 목록을 살펴보세요. 시작하는데 큰 도움이 될 겁니다.

변경 제안하기#

새로운 기능이나 개선 사항을 요청하고 싶은데 풀 리퀘스트를 요청하기에 애매하다면 기능 요청 템플릿을 사용해 이슈를 등록할 수 있습니다.

공개 API(docusaurus.config.js 설정 항목 같은)나 전체 구현에 영향을 미칠 수 있는 변경은 제안 템플릿을 사용하고 제목에 [Proposal]을 포함해서 이슈로 등록해줄 것을 요청드립니다. 이렇게 하면 여러분이 다른 노력을 기울이지 않아도 우리가 여러분의 제안을 확인할 수 있습니다. 이런 타입의 이슈는 흔하게 들어오지 않거든요.

버그만 수정하는 것이라면 풀 리퀘스트를 바로 제출하는 것이 좋습니다. 하지만 여러분이 수정한 내용에 대한 자세한 설명은 작성되어야 합니다. 작성된 내용은 수정한 사항이 받아들여지지 않더라도 이슈를 추적하는데 도움이 됩니다.

풀 리퀘스트 보내기#

작은 크기의 풀 리퀘스트는 바로 검토하고 머지에 반영될 수 있습니다. 풀 리퀘스트에 한 가지 이슈만 담고 있는지 확인하세요. 그렇지 않다면 분리하는 것이 좋습니다. 그리고 커밋 메시지 스타일을 지켜주어야 합니다.

풀 리퀘스트를 보낼 때는 다음 항목을 먼저 체크해주세요.

저장소를 포크하고 master에서 여러분의 브랜치를 만듭니다.
풀 리퀘스트 설명에 테스트 계획을 작성해주세요. 그리고 여러분이 변경한 코드를 테스트해주세요!
여러분의 코드를 체크해주세요(yarn prettier && yarn lint).
제스트(Jest) 테스크를 통과하는지 확인해주세요(yarn test).
아직 하지 않았다면 CLA에 서명해주세요.

모든 풀 리퀘스트는 master 브랜치에 대해 요청되어야 합니다.

테스트 계획#

좋은 테스트 계획은 실행한 정확한 명령과 출력 결과가 있어야 합니다. 스크린샷이나 풀 리쉐스트로 변경될 UI를 담은 비디오를 제출할 수 있습니다.

API를 변경한 경우에는 관련 문서도 업데이트되어야 합니다.

주요 변경사항#

주요 변경 사항에 대해서는 풀 리퀘스트 요청 시 아래 템플릿에 따라 작성해야 합니다.

### New breaking change here
- **Who does this affect**:- **How to migrate**:- **Why make this breaking change**:- **Severity (number of people affected x effort)**:

새로운 파일 상단에 아래 내용을 복사해 붙여넣어주세요.

/** * Copyright (c) Facebook, Inc. and its affiliates. * * This source code is licensed under the MIT license found in the * LICENSE file in the root directory of this source tree. */

기여자 라이선스 동의(CLA)#

여러분의 풀 리퀘스트가 처리되기 위해서는 먼저 CLA를 제출해야 합니다. 한번만 제출하면 되며 다른 페이스북 오픈 소스 프로젝트에도 적용되므로 추가 제출은 필요없습니다. 처음 풀 리퀘스트 요청을 하게 되면 페이스북 깃허브 봇이 CLA 작성 양식 링크를 보내줍니다. CLA 양식을 채워주기만 하면 됩니다.

그리고 나면#

코어 도큐사우루스 팀에서 여러분의 풀 리퀘스트를 검토합니다. 위에서 설명한 가이드에 따라 풀 리퀘스트 요청 양식을 작성해주시면 큰 도움이 됩니다.

라이선스#

도큐사우루스에 기여하는 것은 MIT 라이선스에 따라 라이선스가 부여되는 것에 동의한 것입니다.

지켜야할 지침#