<aside> 💡 프로젝트 진행 시 Github issue 사용 규칙에 관하여 설명한다.
</aside>
프로젝트 완성을 위해 작업을 추적하고 구성하는 행위의 기본 단위가 된다.
이슈는 크게 다음 5가지로 분류할 수 있으며 추가적인 정보를 포함할 수 있다.
[ Template: Feature request ]
새로운 기능을 만들거나 기존 기능을 수정할 때 발행한다.
신규 기능의 추가 이슈에는 다음 내용이 포함되어야 한다.
[ Template: Bug report ]
완성 또는 제작중인 기능에 예상치 못한 버그가 있는 경우 발행한다.
버그 리포트에는 다음 내용이 포함되어야 한다.
[ Template: Refactoring ]
이미 구현된 기능에 대해 외부 노출되는 호출 방식은 유지하고 내부 구조만 개선할 때 발행한다.
리팩토링 에는 다음 내용이 포함되어야 한다.
[ Template: Test ]
특정 파트에서 하는 작업으로는 테스트가 불가능 하여 다른 파트의 도움이 필요한 경우 발행한다. 테스트가 필요한 부분에 대한 1차적인 구현이 완료되어 있어야 한다.
[ Template: Etc ]
위의 내용에 포함되지 않는 모든 내용에 해당한다. 대표적으로 빌드 스크립트 수정, 배포 환경설정, 문서 작성 등이있다.
다음은 Github Issue 를 이용할 때 모든 이슈에 공통으로 표현할 수 있는 내용들로 이슈에 추가적인 정보를 나타내기 위해 사용한다. 이슈가 많아질 경우 필터링에 사용할 수 있다.
강제로 써야하는 값은 아니지만 해당 이슈에 적합한 추가정보가 있는 경우 사용하도록 한다.
이슈에 태그 처럼 달아 두는 것으로 다음의 라벨 중 알맞는 것을 사용한다. 한 이슈에 여러개를 사용할 수 있다.
bounded: backend → 백엔드와 관련 있는 경우 사용
bounded: frontend → 프론트엔드와 관련 있는 경우 사용
type: 🐞bug → 버그엔 대한 보고일 경우 사용
type: 🤔discussion → 의논할 주제 또는 해당 내용에 팀원들의 의견이 필요한 경우 사용
type: 📃docs → 개발 문서와 관련 있는 경우 사용
type: 🔨feature → 기능 개발(구현, 수정 등)과 관련이 있는 경우 사용
type: ❓question → 질문거리인 경우 사용
type: 🛠refactoring → 리팩토링인 경우 사용
type: ✅test → 테스트 관련 도움이 필요한 경우 사용
해당 이슈를 해결할 사람을 명시한다. 필요에 따라 직접 작업하지 않더라도 관련이 있는 경우 함께 명시한다. 해당 작업(또는 의논거리)의 책임자를 결정한다.
해당 이슈가 특정 마일스톤 단위에 속하는 경우 명시한다. 이슈가 프로젝트의 어떤 부분에 영향을 주는지 파악하는 것과 마감 기한을 정하는데 도움을 준다.
프로젝트 진행시 다음 원칙을 가급적 준수한다.
type: 🤔discussion 라벨이 붙은 이슈는 회의 시에 다룰 수 있다.