PR 규칙과 정책

PR 규칙

• 우리는 작은 PR을 선호합니다.
• 쓰기 권한이 있고 변경이 크다면 graphite로 스택 PR을 시도해 보세요. 꾸준히 기여하면 권한이 부여됩니다.
• 아키텍처 변경이 포함되면 이슈나 discussion을 먼저 열어 주세요.

개발 정책

• 데이터 지향 설계를 지향합니다.
• API는 단순하고 문서화가 잘 되어 있어야 합니다.
• 다른 프로젝트 구현을 가져온 경우 항상 출처를 명시합니다.

성능

• 런타임·컴파일 성능 문제는 모두 버그로 봅니다.
  • Rust performance book 가이드를 따릅니다.
  • regex 크레이트 사용은 최소화하고, Rust 이터레이터와 문자열 메서드를 선호합니다.
• 개발 워크플로와 다운스트림 도구에 미치는 영향을 줄이기 위해 컴파일 시간을 최소화합니다.
  • 컴파일 속도와 복잡도를 줄이기 위해 서드파티 의존성을 최소화합니다.
  • 컴파일을 느리게 하거나 바이너리를 키우는 무거운 매크로·제네릭 등은 피합니다.
  • CI 실행은 약 3분 안에 끝나야 하며, 악화되면 고쳐야 합니다.

유지보수 정책

• 코드 커버리지로 미사용 코드를 감시합니다. 커버리지 99%를 목표로 합니다.
• PR 병합을 빠르게 하기 위해 CI 시간을 줄이는 데 적극적으로 나섭니다. 현재 GitHub Actions CI는 약 3분입니다.
• 문서 우선 — 문서가 진실의 원천이 되어야 합니다. 문서를 최신으로 유지하고, 같은 질문에 반복 답하기보다 링크를 공유합니다. GitLab의 handbook-first 접근을 참고합니다.
• import 순서는 "멀리 있는 것"에서 "가까운 것" 순입니다.
  • std
  • 외부 크레이트
  • Oxc 크레이트
  • 로컬 크레이트(crate)
  • super
  • mod

Conventional Commits

Conventional Commits를 따릅니다.

커밋은 소비자에게 의도를 전달하는 구조를 갖습니다.

• fix: 버그 수정
• feat: 새 기능
• BREAKING CHANGE: 타입/스코프 뒤에 !를 붙여 호환을 깨는 API 변경을 나타냅니다. 예: feat(parser)!: new feature
• 스코프는 크레이트 이름입니다.
• 타입은 feat:, fix:, chore:, ci:, docs:, style:, refactor:, perf:, test: 입니다.

행동 원칙(Action Policy)

Astral의 가치관에서 발췌:

우리는 불확실함 속에서도 행동을 택합니다. 긴 토론보다 실용적인 실행을, 허가보다 용서 구하기를 선호합니다. 결단력을 중시합니다. 특히 결정이 애매할 때, 그리고 되돌릴 수 있는 결정일 때 더욱 그렇습니다.

행동 지향은 무분별함과 같지 않습니다. 오히려 책임 있는 결정을 내리고 애매함이나 알려지지 않은 미지수가 남아 있어도 긴박하게 실행하는 쪽으로 기운다는 뜻입니다.