이 프로젝트에 관심을 가져주셔서 감사합니다. 기여는 언제나 환영입니다! 🎉

본 프로젝트는 GitHub의 풀 리퀘스트(PR) 기반으로 기여를 관리하고 있습니다.
먼저 프로젝트를 포크하고 PR을 보내는 방법을 참고해 주세요.

1. Bun 설치하기
2. 프로젝트를 포크하고 PR을 보내는 방법을 참고해서 리포지토리를 자신의 계정에 포크하고, 클론합니다.
   1. 이 때 클론한 리포지토리를 업스트림 리포지토리와 동기화하는 설정을 함께 적용하면 기여에 용이합니다.
3. 터미널에서 아래 명령어를 실행합니다:

cd path/to/daleui
# 의존성 설치
bun install
# Storybook 실행 (디자인 시스템 기여 시)
bun run sb # or bun run storybook
# 마케팅 웹사이트 실행 (마케팅 웹사이트 기여 시)
bun run dev

• Figma: 디자인, 회고
• React: UI renderer
• Panda: Styling engine
• Ark UI: Headless UI components
• Storybook: 컴포넌트 시연, 문서화
• Chromatic: UI Preview/Tests/Reviews
• Vite: Bundler
• Vitest: Test Runner, Test Matcher
• TestingLibrary: UI Testing
• HappyDom: Testing DOM
• ESLint: Linter
• Prettier: Formatter
• GitHub Actions: CI/CD
• Bun: JS Runtime

• 무료 프로젝트 관리 기능인 깃허브 프로젝트를 통해 이슈(Jira 티켓과 같은 개념)를 관리해 주세요.
• 이슈를 생성할 때 유형(Type)을 반드시 선택해주시고, 프로젝트에 추가 후 우선순위(Priority)와 예상 소요 시간(Est)도 함께 넣어주세요.
• 이슈를 생성할 때 스프린트(Sprint)와 상태(Status)는 비워두어 일단 백로그(Backlog)에 두도록 해 주세요.
• 이슈는 팀 회의 때 Grooming, Triage, Planning 과정을 거친 후에 스프린트에 추가해 주세요.
• 긴급 이슈가 있거나 스프린트에 To Do 이슈가 소진되었을 때는 디스코드에서 소통 후에 현재 스프린트에 추가해주세요.
• 자율적인 협업과 자발적인 기여를 위해 특별한 사유가 없다면 이슈를 생성할 때 담당자를 설정하지 마세요.
• 이슈 상태는 스프린트에 추가되었을 때 부터 To Do로 설정해주세요.
• 작업을 시작하시면 이슈의 상태를 반드시 In Progress로 옮겨주세요. (많이 까먹는 부분이니 꼭 지켜 주세요.)
• 이슈가 연결된 Pull Request가 병합되면 이슈는 자동으로 Done 상태로 전환됩니다.
• 동시에 2개 이상 이슈를 할당하지 않도록 주의해주세요. WIP가 2보다 커지면 팀의 리뷰 부담이 커지니 참고해 주세요.
• 서브 이슈는 Spike 티켓에서 파생된 Action 티켓에 한해 사용해 주세요.
• 서브 이슈가 완료되지 않아도, 상위 Spike 티켓(Parent Issue)은 완료 처리해 주세요.
• 이슈가 스프린트 1회 이상 이관될 경우 spillover label을 추가해주세요.
• 이슈가 스프린트 2회 이상 이관될 경우 공론화하고 blocker 여부를 확인하여 해결 방향을 정리해주세요.

주간 Sprint 회의록 이슈는 GitHub Actions를 통해 자동으로 생성됩니다.

이 자동화는 현재 프로젝트의 Sprint 일정 기준으로 동작합니다. 평소에는 별도 Repository Variables 설정 없이 동작합니다. 비정규 스프린트나 쉬어가는 주 등으로 특정 주의 회의록 이슈 생성을 건너뛰어야 할 때만, 자동 실행 시간 전에 Repository Variables에 아래 값을 설정해 주세요.

건너뛰기 설정이 더 이상 필요하지 않은 경우, SKIP_NEXT_RUN 값을 비워두면 다음 자동 실행부터 다시 회의록 이슈가 생성됩니다. 수동으로 회의록 이슈를 생성해야 하는 경우에는 GitHub Actions 탭에서 Create Weekly Meeting Issue 워크플로를 선택한 뒤, Run workflow를 실행하면 됩니다.

1. 프로젝트 보드에서 To Do 상태의 티켓을 선택하고 본인에게 할당해 주세요.
2. 프로젝트 설정

• 먼저 프로젝트 설정 가이드를 완료해 주세요.

3. 브랜치 생성

• main 브랜치에서 새로운 feature 브랜치를 생성해 주세요.
• 브랜치 이름에는 -, _ 외의 특수문자를 사용하지 마세요.
  참고 이슈

4. 기능 구현 및 커밋

• 브랜치 내에서 소스 코드를 수정하고 커밋해 주세요.
• 변경이 모두 완료되면 포크받은 리포지토리 브랜치를 푸시해 주세요.

5. 테스트 작성

• 기여한 코드가 정상적으로 동작하는지 확인하는 테스트 코드를 작성해 주세요.

6. PR 생성

• Pull Requests 페이지에서 새로운 PR을 생성해 주세요.

• PR 제목과 설명은 가급적 한국어로 작성해주세요. 이슈 제목과 일치하도록 작성해 주세요.

• PR이 등록된 이슈와 연관된다면, PR 생성 후 오른쪽 사이드바 Development 항목에서 해당 이슈를 선택해 연결해주세요.

  PR 이슈 연결 예시

7. PR 리뷰 및 병합

• 최소 한 명 이상의 관리자에게 PR 검토와 코멘트를 받아 주세요.
• 변경 요청이 있을 경우, 수정을 반영한 후 다시 푸시하고 리뷰를 요청해 주세요.
• 디자인 변경이 있을 경우, PR에 ui 태그를 달아서 Chromatic을 실행해 주세요.
• UI Review 체크에서 해당 디자인을 담당한 디자이너에게 리뷰를 요청해 주세요. (생성된 PR의 하단 Merge 부분에서 확인할 수 있음) [画像:image]

UI Review: 작업 내역을 디자인 담당자에게 확인 요청하는 작업

UI Tests: 코드 변경이 의도치 않은 UI 변화를 일으키지 않았는지, Chromatic 스냅샷을 하나씩 비교하며 개발자가 직접 확인하는 작업

• 최소 1개의 승인을 받은 후 main 브랜치에 병합해 주세요.
• 이후 릴리즈를 통해 기여한 내용이 배포됩니다.

• PR 병합을 하기 위해서는 최소 1명의 동료 개발자로부터 승인을 받아야 하지만, 품질 향상을 위해서 긴급 건이 아니라면 2개의 승인을 받는 것이 권장됩니다.
• [Proposed] "Resolve conversation" 버튼은 코드 검토자가 피드백이 본인이 의도한 대로 조치되었는지 확인하는 차원에서 누릅니다. 코드 작성자가 임의로 Resolved 표시할 시 오해가 생길 수 있습니다.

• 항상 의존성을 최신 상태로 유지하도록 Dependabot을 코드 저장소에 설정해놓았습니다.
• Dependabot이 올린 PR을 늦지 않게 검토 및 병합하고 새로운 버전이 일으키는 breaking changes를 대응하는 작업은 팀 개발자 모두의 공동 책임입니다.
• Dependabot이 올린 PR을 반드시 PR 코멘트를 통해서 Dependabot에게 원하시는 작업을 시켜주세요. 직접 수정하시면 Dependabot은 해당 PR을 더 이상 자동으로 관리해주지 않습니다.

main 브랜치에 품질 기준에 미달하는 코드가 유입이 되지 않도록 PR을 올리시면 자동으로 품질 검사가 진행되고 실패할 경우 병합이 불가능합니다. 각 품질 검사는 개발자가 로컬 환경에서 직접 진행하실 수도 있습니다.

Prettier를 통해서 일관적인 코드 포멧팅을 유지하고 있습니다. VSCode 사용자 분들은 Prettier 익스텐션을 쓰시면 코드를 작성하면서 자동으로 코드를 포멧팅할 수 있어서 편하니 추천드립니다.

Prettier options 는 기본 설정값으로 해주시길 바랍니다.

ESLint를 통해서 잠재적인 문제를 발견하고 모범 사례를 따르고 있습니다. 린팅 규칙을 위반하고 있는 코드가 있는지 확인하려면 다음 명령어를 실행합니다.

# 전체 검사
bun run lint
# 특정 파일 검사
bun run lint src/components/TextInput/TextInput.tsx

TypeScript를 통해서 정적 타입 검사를 하고 있습니다. 타입 오류가 있는지 확인하려면 다음 명령어를 실행합니다.

bunx tsc

flowchart TD
 RELEASE_PR["1. GitHub UI > Actions에서<br/>Release PR 생성<br/>(개발자)"]
 TAG["3. 자동으로 태그 & GitHub Release Draft 생성됨<br/>(GitHub Action)"]
 PUBLISH["4. npm publish 실행<br/>(GitHub Action)"]
 RELEASE_PR --> |"2. Release PR Approve & Merge<br/>(개발자)"| TAG
 TAG --> PUBLISH

1. Release PR 생성: GitHub UI에서 Actions탭 > 좌측 사이드바 Workflow 목록 중, 'Release PR ⬆️' 클릭 > Run workflow 클릭 > Branch는 main, Version bump type은 patch/minor/major 중 선택 > 'Run workflow'버튼 클릭

• patch: 하위 호환성을 유지하면서 버그를 수정했을 때
  • 기능 추가 없이 오타를 고치거나 성능을 개선하는 등 사소한 수정일 때
• minor: 하위 호환성을 유지하면서 새로운 기능을 추가했을 때
  • 새로운 컴포넌트나 함수가 생겼지만, 기존 기능도 그대로 쓸 수 있을 때
• major: 호환되지 않는 API 변경 사항이 생겼을 때 (이전 버전과 호환 안 됨)
  • 기능이 완전히 바뀌거나 삭제되어, 사용자가 코드를 고쳐야 할 때 (Breaking Changes)

3. Release PR이 Merge되면 자동으로 태그 & GitHub Release Draft 생성됨

4. GitHub의 Code 탭 클릭 > 화면 오른쪽 중간부분의 Release 부분 클릭

-> 생성된 Release Draft의 Edit모드 > Release notes 등 수정 후 'Publish release'버튼 클릭

5. npm사이트에서 버전 update 확인

코드 스타일, 네이밍 규칙, PR 작성 규칙 등을 이해하기 위해 먼저 컨벤션 문서를 읽어주세요.