# ZELLYY - Git 이슈 트래킹 시스템

## 개요

ZELLYY 프로젝트는 GitHub를 활용하여 이슈 트래킹 및 프로젝트 관리를 진행합니다. 이 문서는 개발팀이 일관된 방식으로 이슈를 생성, 관리, 해결하기 위한 가이드라인을 제공합니다.

## 이슈 유형 분류

ZELLYY 프로젝트에서는 다음과 같은 이슈 유형을 사용합니다:

### 1. 기능 요청 (Feature Request)
새로운 기능 개발이나 기존 기능 확장에 관한 이슈입니다.

### 2. 버그 리포트 (Bug Report)
애플리케이션의 오작동이나 예상치 못한 동작에 관한 이슈입니다.

### 3. 개선 사항 (Enhancement)
기존 기능의 사용성, 성능, 디자인 등을 개선하기 위한 이슈입니다.

### 4. 문서화 (Documentation)
코드, API, 사용자 가이드 등의 문서화에 관한 이슈입니다.

### 5. 기술 부채 (Technical Debt)
코드 리팩토링, 아키텍처 개선 등 기술적 부채 해소를 위한 이슈입니다.

### 6. 질문 (Question)
프로젝트에 관한 질문이나 논의가 필요한 사항에 대한 이슈입니다.

## 이슈 라벨 시스템

### 우선순위 라벨
- `priority:critical` - 즉시 해결해야 하는 중대한 이슈
- `priority:high` - 높은 우선순위로 다음 스프린트에서 처리해야 하는 이슈
- `priority:medium` - 중간 우선순위로 향후 스프린트에서 처리할 이슈
- `priority:low` - 낮은 우선순위로 여유가 있을 때 처리할 이슈

### 상태 라벨
- `status:backlog` - 아직 스프린트에 할당되지 않은 이슈
- `status:ready` - 개발 준비가 완료된 이슈
- `status:in-progress` - 현재 개발 중인 이슈
- `status:review` - 코드 리뷰 중인 이슈
- `status:blocked` - 다른 이슈나 외부 요인으로 인해 진행이 막힌 이슈

### 유형 라벨
- `type:feature` - 새로운 기능
- `type:bug` - 버그 수정
- `type:enhancement` - 기능 개선
- `type:documentation` - 문서화 작업
- `type:refactor` - 코드 리팩토링
- `type:test` - 테스트 관련 작업

### 컴포넌트 라벨
- `component:ui` - UI 관련 이슈
- `component:api` - API 관련 이슈
- `component:database` - 데이터베이스 관련 이슈
- `component:auth` - 인증 관련 이슈
- `component:editor` - 카드 에디터 관련 이슈
- `component:sharing` - 공유 기능 관련 이슈
- `component:storage` - 저장 및 동기화 관련 이슈

### 기타 라벨
- `good-first-issue` - 신규 기여자에게 적합한 이슈
- `help-wanted` - 외부 도움이 필요한 이슈
- `discussion` - 추가 논의가 필요한 이슈
- `wontfix` - 해결하지 않기로 결정된 이슈
- `duplicate` - 중복된 이슈

## 이슈 템플릿

### 기능 요청 템플릿

```markdown
## 기능 설명
[기능에 대한 간결한 설명]

## 사용자 스토리
[사용자 관점에서의 기능 설명, "사용자로서, ~할 수 있기를 원합니다. 그래서 ~할 수 있습니다." 형식]

## 상세 요구사항
- [요구사항 1]
- [요구사항 2]
- [요구사항 3]

## 수용 기준
- [ ] [기준 1]
- [ ] [기준 2]
- [ ] [기준 3]

## 디자인 참조
[관련 디자인 문서, 와이어프레임, 목업 등의 링크]

## 추가 컨텍스트
[기능 구현에 도움이 될 추가 정보]
```

### 버그 리포트 템플릿

```markdown
## 버그 설명
[버그에 대한 간결한 설명]

## 재현 단계
1. [단계 1]
2. [단계 2]
3. [단계 3]

## 예상 동작
[정상적으로 작동했을 때 예상되는 동작]

## 실제 동작
[실제로 발생한 동작]

## 스크린샷
[가능한 경우 스크린샷 첨부]

## 환경 정보
- 기기: [예: iPhone 13 Pro]
- OS: [예: iOS 16.2]
- 앱 버전: [예: 1.2.0]
- 기타 관련 정보

## 가능한 해결 방법
[알고 있는 경우, 가능한 해결 방법 제안]

## 추가 컨텍스트
[문제 해결에 도움이 될 추가 정보]
```

## 이슈 생성 가이드라인

### 이슈 제목 작성법
- 명확하고 간결하게 작성
- 행동 지향적인 동사로 시작 (예: "구현", "수정", "개선")
- 이슈의 핵심을 포함 (예: "카드 에디터에 텍스트 크기 조절 기능 구현")

### 이슈 설명 작성법
- 관련 템플릿 사용
- 충분한 컨텍스트 제공
- 명확한 요구사항 또는 문제점 설명
- 가능한 경우 시각적 자료 첨부 (스크린샷, 다이어그램 등)
- 관련 문서나 이슈 링크 제공

### 이슈 할당 및 마일스톤 설정
- 담당자가 명확한 경우 이슈 생성 시 할당
- 적절한 마일스톤에 이슈 연결 (스프린트 또는 릴리스 버전)
- 예상 완료 일자 설정 (가능한 경우)

## 이슈 관리 워크플로우

### 1. 이슈 생성
- 적절한 템플릿을 사용하여 이슈 생성
- 관련 라벨 적용
- 필요한 경우 담당자 할당

### 2. 이슈 트라이아지 (분류)
- 주간 트라이아지 미팅에서 새 이슈 검토
- 우선순위 및 마일스톤 설정
- 필요한 추가 정보 요청

### 3. 이슈 처리
- 담당자는 이슈를 `status:in-progress`로 변경
- 관련 브랜치 생성 (명명 규칙: `issue/[이슈번호]-[간략한-설명]`)
- 작업 진행 및 커밋

### 4. 코드 리뷰
- 작업 완료 후 Pull Request 생성
- 이슈 상태를 `status:review`로 변경
- 코드 리뷰 진행 및 피드백 반영

### 5. 이슈 종료
- Pull Request가 승인되고 병합되면 이슈 종료
- 이슈에 해결 방법 간략히 기록
- 관련 문서 업데이트 필요 시 언급

## GitHub 프로젝트 보드 구성

ZELLYY 프로젝트는 GitHub 프로젝트 보드를 사용하여 이슈와 작업을 시각적으로 관리합니다.

### 보드 컬럼
1. **Backlog**: 아직 스프린트에 할당되지 않은 이슈
2. **To Do**: 현재 스프린트에 할당되었지만 아직 시작되지 않은 이슈
3. **In Progress**: 현재 작업 중인 이슈
4. **Review**: 코드 리뷰 중인 이슈
5. **Done**: 완료된 이슈

### 자동화 규칙
- 새 이슈는 자동으로 Backlog에 추가
- `status:in-progress` 라벨이 적용된 이슈는 In Progress로 이동
- `status:review` 라벨이 적용된 이슈는 Review로 이동
- 이슈가 종료되면 자동으로 Done으로 이동

## 브랜치 및 커밋 전략

### 브랜치 명명 규칙
- 기능 개발: `feature/[이슈번호]-[간략한-설명]`
- 버그 수정: `bugfix/[이슈번호]-[간략한-설명]`
- 문서 작업: `docs/[이슈번호]-[간략한-설명]`
- 리팩토링: `refactor/[이슈번호]-[간략한-설명]`

### 커밋 메시지 형식
```
[이슈번호] 유형: 간결한 설명

상세 설명 (필요한 경우)
```

예시:
```
[#42] feat: 카드 에디터에 텍스트 크기 조절 기능 추가

- 슬라이더를 사용하여 텍스트 크기 조절 가능
- 8pt에서 72pt까지 조절 가능
- 기본값은 16pt로 설정
```

### 커밋 유형
- `feat`: 새로운 기능 추가
- `fix`: 버그 수정
- `docs`: 문서 변경
- `style`: 코드 포맷팅, 세미콜론 누락 등 (코드 변경 없음)
- `refactor`: 코드 리팩토링
- `test`: 테스트 코드 추가 또는 수정
- `chore`: 빌드 프로세스, 도구 변경 등

## Pull Request 프로세스

### PR 템플릿

```markdown
## 관련 이슈
[관련 이슈 번호 및 링크]

## 변경 사항
[변경 사항에 대한 간결한 설명]

## 변경 유형
- [ ] 새로운 기능
- [ ] 버그 수정
- [ ] 성능 개선
- [ ] 코드 리팩토링
- [ ] 스타일 변경 (코드 기능에 영향 없음)
- [ ] 문서 업데이트
- [ ] 기타 (설명: )

## 테스트 방법
[변경 사항을 테스트하는 방법 설명]

## 스크린샷 (UI 변경의 경우)
[변경 전/후 스크린샷]

## 체크리스트
- [ ] 코드가 스타일 가이드를 준수합니다
- [ ] 자체 코드 리뷰를 수행했습니다
- [ ] 관련 문서를 업데이트했습니다
- [ ] 테스트를 추가/수정했습니다
- [ ] 모든 테스트가 통과합니다
```

### PR 리뷰 가이드라인
- 최소 1명의 승인이 필요
- 코드 품질, 테스트 커버리지, 문서화 확인
- 건설적인 피드백 제공
- 24시간 이내에 리뷰 완료 (가능한 경우)

### 병합 전략
- Squash and merge 사용 (여러 커밋을 하나로 압축)
- 병합 전 CI 파이프라인 통과 확인
- 병합 후 관련 이슈 자동 종료 (키워드 사용: "Closes #이슈번호")

## 릴리스 프로세스

### 버전 관리
ZELLYY는 [Semantic Versioning](https://semver.org/) 체계를 따릅니다:
- **Major 버전 (X.0.0)**: 이전 버전과 호환되지 않는 API 변경
- **Minor 버전 (0.X.0)**: 이전 버전과 호환되는 새로운 기능 추가
- **Patch 버전 (0.0.X)**: 버그 수정 및 작은 개선

### 릴리스 브랜치
- 릴리스 준비: `release/vX.Y.Z` 브랜치 생성
- 릴리스 후보 테스트 및 버그 수정
- 최종 릴리스: 메인 브랜치에 병합 및 태그 생성

### 릴리스 노트
- GitHub Releases 기능 활용
- 주요 기능, 개선 사항, 버그 수정 등 카테고리별 정리
- 사용자 관점에서 이해하기 쉬운 설명 제공
- 스크린샷 또는 GIF 포함 (UI 변경의 경우)

## 결론

이 Git 이슈 트래킹 시스템은 ZELLYY 프로젝트의 효율적인 개발 관리를 위한 가이드라인입니다. 모든 팀원은 이 가이드라인을 따라 일관된 방식으로 이슈를 생성하고 관리함으로써, 프로젝트의 투명성과 협업 효율성을 높일 수 있습니다.

이 문서는 프로젝트의 진행 상황과 팀의 필요에 따라 지속적으로 업데이트될 예정입니다.