# p5.js 웹 에디터에 기여하기 

안녕하세요! p5.js 웹 에디터에 다양한 형태로 기여해주실 분들을 환영합니다. 저희 커뮤니티에 대한 기여는 **코드 작성**에 국한되지 않으며, **버그 리포팅**, **새로운 기능 제안**, **UI/UX 디자인 제작**, **문서 업데이트** 등 여러가지 형태일 수 있습니다.

## 목차
- [p5.js 웹 에디터에 기여하기](#p5js-웹-에디터에-기여하기)
  - [목차](#목차)
  - [행동 수칙](#행동-수칙)
  - [어떻게 기여할 수 있을까요?](#어떻게-기여할-수-있을까요)
    - [첫 단계](#첫-단계)
    - [좋은 첫 이슈들](#좋은-첫-이슈들)
    - [좋은 중간 이슈들](#좋은-중간-이슈들)
    - [프로젝트 보드](#프로젝트-보드)
    - [프로젝트 아이디어](#프로젝트-아이디어)
    - [이슈 검색 및 태깅](#이슈-검색-및-태깅)
    - [작업 시작하기](#작업-시작하기)
    - [기여 가이드](#기여-가이드)
  - [커밋 메세지 쓰는 법](#커밋-메세지-쓰는-법)
  - [팁](#팁)
  
## 행동 수칙

[행동 수칙](https://github.com/processing/p5.js-web-editor/blob/develop/.github/CODE_OF_CONDUCT.md)에 있는 가이드라인을 따라주시기 바랍니다.

## 어떻게 기여할 수 있을까요?
만약 오픈 소스에 기여하는 게 처음이신 경우라면, [오픈 소스에 어떻게 기여할 수 있는지](https://opensource.guide/how-to-contribute/)를 읽어주시기 바랍니다.

### 첫 걸음
어디서 시작할지 모르시겠다구요? 시작점이 될 수 있을만한 몇 가지 제안들이 여기 있습니다:
* 오픈 소스 작업을 통해 무엇을 배우기를 희망하는지 생각해보시기 바랍니다. 웹 에디터는 풀스택 웹 애플리케이션이므로, 여러가지 분야가 있습니다:
- UI/UX 디자인
- 프로젝트 매니지먼트: 티켓, 풀 리퀘스트, 과업 정리
- 프런트엔드: 리액트/리덕스, CSS/사스(Sass), 코드 미러
- 백엔드: Node, Express, MongoDB, Jest, AWS
- 데브옵스: Travis CI, Jest, 도커, 쿠버네티스, AWS
* [p5.js 웹 에디터](https://editor.p5js.org)를 사용해보세요! 버그를 찾으셨나요? 이 프로젝트에 뭔가를 더하실 수 있을 것 같으신가요? 그렇다면 이슈를 열어주세요.
* 기존 이슈들을 확장시켜보세요. 가끔은 이슈들 중에 재현 과정이 미흡하거나, 솔루션 후보들이 필요한 경우들이 있습니다. 어쩔 땐 “이거 정말 중요해!” 하고 말해주는 목소리가 필요한 경우들도 있습니다.
* 여러분의 로컬 컴퓨터에서 [설치 단계](./installation.md)를 따라 프로젝트를 실행해보세요.
* [개발자 문서 디렉토리](./../../developer_docs/) 안의 문서들을 읽어보세요. 더 확장될 수 있는 뭔가가 있나요? 뭔가 빠진게 있나요?
* [개발 가이드](./development.md)를 읽어보세요.

### 좋은 첫 이슈들
처음 기여를 해보시는 분들이나, 작은 과업으로 기여를 시작하고자 하는 분들이라면, [좋은 첫 이슈들](https://github.com/processing/p5.js-web-editor/labels/good%20first%20issue) 혹은 [재현 단계들을 문서화 해야 하는 이슈들](https://github.com/processing/p5.js-web-editor/issues?q=is%3Aissue+is%3Aopen+label%3A%22needs+steps+to+reproduce%22)을 확인해보시기 바랍니다. 만약 이슈가 누구에게도 할당되지 않았다면, 여러분이 그 작업을 하셔도 좋습니다! 어떻게 이슈를 해결해야 할지 모르셔도 괜찮고, 문제를 어떻게 접근해야 할지 질문해주셔도 좋습니다! 우리는 모두 배우기 위해서, 뭔가 멋진걸 만들기 위해서 여기 있는 거니까요. 커뮤니티 멤버 중 누군가가 여러분을 도와줄 수도 있을거고, 이 이슈들은 웹 에디터, 파일 구조, 개발 과정에 대해 배울 수 있게 해주는 훌륭한 이슈들입니다.

### 좋은 중간 이슈들
좀 더 큰 규모의 일을 하고 싶다면, [좋은 중간 이슈](https://github.com/processing/p5.js-web-editor/labels/good%20medium%20issue)로 태그 되어 있는 이슈들을 살펴보시기 바랍니다. 이 이슈들은 꽤 오랜 시간이 걸릴 수 있는 독자적인 프로젝트인데, 더 깊이 관여해 기여하고 싶다면 이런 이슈들이 적당할 것입니다!

### 프로젝트 보드
많은 이슈들은 서로 연관이 있으며 더 큰 프로젝트의 일부이기도 합니다. 더 큰 그림을 보기 위해서는 [모든 프로젝트](https://github.com/processing/p5.js-web-editor/projects/4) 보드를 살펴보시기 바랍니다.

### 프로젝트 아이디어
구글 서머 오브 코드 혹은 더 큰 프로젝트를 위한 아이디어를 찾고 있다면, 프로세싱 재단 위키에 있는 [프로젝트 리스트](https://github.com/processing/processing/wiki/Project-List#p5js-web-editor)를 확인하시기 바랍니다.

### 이슈 검색 및 태깅
작업할 이슈를 찾고 있다면, [높은 우선 순위](https://github.com/processing/p5.js-web-editor/labels/priority%3Ahigh) 표시가 된 티켓들부터 시작하는 걸 권장드립니다. [기능 개선](https://github.com/processing/p5.js-web-editor/labels/type%3Afeature), [버그 수정](https://github.com/processing/p5.js-web-editor/labels/type%3Abug) 등의 태그들이 있는 티켓을 살펴보시는 것도 좋은 방법입니다.

만약 어떤 이슈가 잘못된 태그를 달고 있는 것 같다면(예: 낮은 우선 순위로 표시되어 있지만 우선 순위가 높다고 생각할 때), 이슈를 업데이트 해주시기 바랍니다!

### 작업 시작하기

어떤 이슈를 위한 작업을 시작하고 싶다면, 해당 이슈에 댓글을 달아서 관리자들에게 이를 알려 이슈를 할당 받으시기 바랍니다. 만약 다른 사람이 이미 해당 이슈에 댓글을 달았고 작업을 하기로 되어 있다면, 불필요한 중복 문제를 피하기 위해 해당 이슈와 관련된 작업을 하거나 관리자에게 묻지 않은 채로 풀 리퀘스트를 제출하는 일은 삼가주시기 바랍니다.

이제 여러분의 컴퓨터에서 프로젝트를 빌드하고 작업을 하기 위해 [설치 가이드](https://github.com/processing/p5.js-web-editor/blob/develop/developer_docs/installation.md)를 따라 주시기 바랍니다.

### 기여 가이드

* [https://guides.github.com/activities/hello-world/](https://guides.github.com/activities/hello-world/)
* [https://guides.github.com/activities/forking/](https://guides.github.com/activities/forking/)

## 커밋 메세지 쓰는 법

좋은 커밋 메세지는 최소한 세 가지 중요한 목적을 충족시켜줍니다:

* 리뷰 절차의 속도를 높여줍니다.
* 좋은 릴리즈 노트를 작성하는 데에 도움을 줍니다.
* 관리자들이 어떤 변화가 왜 일어났는지 이해하기 쉽게 해줍니다.

커밋 메세지는 다음과 같은 구조로 작성해주시기 바랍니다:

 ```
 변경 사항(#이슈-번호 키워드 포함)에 대한 짧은 (50 문자 이하) 요약
 
 필요 시 더 자세한 설명을 담은 텍스트 추가.
 72 문자 이하로 작성.
 어떤 맥락에서는 첫 줄은 이메일의 제목으로,
 나머지는 본문으로 간주되기도 함.
 요약과 본문을 분리시키는 빈 줄은 중요함(본문이 아예 빠지지 않는 한);
 분리되지 않을 경우 리베이스 같은 툴은 혼란스러워 할 수 있음.

 추가 문단들은 빈 줄 이후에 온다.
 
    - 불릿 포인트도 허용됨
    
    - 불릿은 보통 스페이스 한 칸 다음에 하이픈이나 별표가 이용되며, 불릿 간에는 빈 줄이 있지만 이 관례는 상황에 따라 다르게 적용됨
    
 ```
 
* 요약과 설명의 경우 누군가에게 무언가를 명령하듯이 작성하시기 바랍니다. “Fixed”, “Added”, “Changed” 대신 “Fix”, “Add”, “Change”로 줄을 시작하십시오.
* 두 번째 줄은 항상 빈 줄로 남겨두십시오.
* 설명 란에선 최대한 자세히 서술해주십시오. 이는 커밋의 의도에 대해 더 잘 이해할 수 있게 해주고, 왜 이런 변경 사항이 있었는지 문맥을 제공해줍니다.

## 팁

* 여러분의 커밋이 무슨 일을 하는지 요약하기 어렵다면, 여러가지 논리적 변화나 버그 수정을 하나에 담고 있기 때문일 가능성이 있으며, 이런 경우에는  `git add -p `를 이용해 여러 개의 커밋으로 나누는 편이 낫습니다.
