오픈소스 참여 조건
- 본인이 관심 있고, 흥미 있는 프로젝트 선택.
- 사용할 줄 아는 언어.
- 프로젝트 활성화 정도. (기여자 수, issue, PR의 개수)
- 컴파일, 테스트가 가능해야 한다.
오픈소스 프로젝트 특징
- 오픈소스 프로젝트는 모두 git으로 관리한다.
- CONTRIBUTING.md에 협업의 모든 규칙들이 있다.
오픈소스의 본질은 인기도, 사용성, 가치창출도 중요하지만 리뷰와 토론이 활성화되어 있고 협업하는 사람이 많고 잘 되어있는 프로젝트가 좋은 오픈소스이다.
Commit Message
'update' or 'Add hello.c'와 같이 작성하면 안 된다. 협업에 도움 되지 않고 다른 사람이 어떤 의미로 commit 한 건지 알아 볼 수 없기 때문이다.
첫단어
- Fix : 잘못된 것을 수정할 때.
- Add : 함수, 파일, 클래스 추가할 때. (없던 기능, 없던 옵션 추가할 때)
- Imporove : 원래 잘 되던 것을 추가할 때. (10초->5초)
- Support : 윈도우에서 되던걸 리눅스. (x86->ARM)
- Refactor : 코드 재배치.
filter 기능을 사용하면 협업, 구체화 하는데 도움이 된다.
Commit 크기를 쪼개는 방법은 : 협업을 하기 유리하게 목적에 따라서 간소화해서 commit 한다. 보통 기능을 추가할 때마다 commit 한다.
PR -> Merge VS PR -> Reject
한 번에 거절당하지 않고 Merge 하면 물론 좋지만, 거절당해도 꼭 나쁜 것은 아니다.
PR -> Reject -> v2 -> v3 -> Merge 될 수도 있기 때문이다.
오픈소스 컨트리뷰션 전략
- 오픈소스를 파악한다. (목적, 취지 / 구조, 폴더, 파일 / 개발환경 구축)
- 프로젝트 개발환경 파악한다. (기존 commit 분석, issue, PR 등)
- 특정 소항목(서브 파트) 선택한다. (문서, 예제코드, 테스트 코드 등)
컨트리뷰션 방법 9가지
- Issue : 작업하기 적당한 이슈 찾기.
- Build problem : 최신 소스코드 빌드 및 세팅중에 생기는 문제 찾기.
- Question : 프로젝트의 특정기능을 이해하면서 생기는 질문을 issue글로 남기기.
- Doc : 다양한 기능을 테스트하고 메뉴얼 페이지나 문서에 빠져 있는 설명 또는 예제 채워 넣기.
4-1. Test : 프로젝트 내부 test script, unit test등 다양한 기능 테스트 살펴보고 새로운거 추가.
(문서 추가 / 개선) => read가 많아야 write가 가능하다.
4-2. Example : 프로젝트를 활용한 다양한 example을 실행해보고, 추가 example 넣기.
(예제 코드 추가 / 개선) => 있으면 있을 수록 좋다 (초보자를 위한 것) - Suggestion : 프로젝트에 대한 다양한 제안을 issue 게시글로 남겨본다.
- Refectoring : 특정 기능 테스트 후 그 기능에 대한 함수들만 소스리딩하고 리팩토링시도.
- Review : 기존 pull-request 를 분석하면서 생기는 의문이나 질문을 댓글로 남기기.
- Discussion : 다른사람의 issue 에 필요한 답글 남기기.
- Feature : 필요하다고 생각이드는 기능을 개발해본다.
