PR 규칙 및 정책

PR 규칙

• 우리는 작은 PR을 선호합니다.
• 쓰기 권한이 있는 경우, graphite를 사용하여 스택형 PR을 시도하세요. 많은 기여를 하면 쓰기 권한이 부여됩니다.
• 만약 PR에 아키텍처 변경 사항이 포함되어 있다면, 이슈나 논의를 생성해 주세요.

개발 정책

• 데이터 중심 설계를 수용하세요.
• API는 간단하고 잘 문서화된 상태로 유지하세요.
• 구현이 다른 프로젝트에서 온 경우, 반드시 원본 참조를 제공하세요.

성능

• 본 프로젝트에서는 모든 성능 문제를 버그로 간주합니다. 이는 실행 시간 및 컴파일 시간 성능 문제를 포함합니다.
  • 러스트 성능 책의 지침을 따르세요.
  • regex 크레이트의 사용을 최소화하세요. 더 나은 성능을 위해 러스트 반복자와 문자열 메서드를 사용하세요.
• 컴파일 시간은 개발 워크플로우 및 후속 도구에 미치는 영향을 최소화해야 합니다.
  • 제3자 종속성 사용을 줄여 컴파일 속도와 프로젝트 복잡성을 감소시키세요.
  • 무거운 매크로, 제네릭 또는 컴파일 속도를 늦추거나 바이너리 크기를 증가시키는 러스트 기법을 피하세요.
  • 우리의 CI 작업은 3분 내에 완료되며, 어떤 회귀도 즉시 수정되어야 합니다.

유지보수 정책

• 사용되지 않는 코드를 모니터링하기 위해 코드 커버리지를 점검하세요. 목표는 99% 코드 커버리지입니다.
• 활발히 CI 시간을 모니터링하고, 이를 단축하여 PR 머지 속도를 높이세요. 현재 GitHub Actions에서의 CI 시간은 약 3분 정도입니다.
• 문서 우선 — 문서는 진실의 근원이 되어야 합니다. 문서를 항상 최신으로 유지하고, 동일한 질문을 반복적으로 답변하는 대신 링크를 공유하세요. GitLab의 핸북 우선 접근 방식을 참고하세요.
• 일관된 임포트 순서: "가장 먼 곳"에서 "가까운 곳"으로.
  • std
  • 외부 크레이트
  • Oxc 크레이트
  • 로컬 크레이트 (crate)
  • super
  • mod

관례적인 커밋

우리는 관례적인 커밋을 따릅니다:

커밋에는 소비자에게 의도를 전달하기 위한 다음 구조적 요소가 포함되어 있습니다:

• fix: fix 유형의 커밋은 코드베이스의 버그를 수정합니다.
• feat: feat 유형의 커밋은 코드베이스에 새로운 기능을 도입합니다.
• BREAKING CHANGE: 타입/스코프 뒤에 !를 추가하면, 해로운 API 변경을 의미합니다. 예: feat(parser)!: 새로운 기능.
• 스코프는 크레이트 이름입니다.
• 타입은 feat:, fix:, chore:, ci:, docs:, style:, refactor:, perf: 및 test:입니다.

행동 정책

아스트랄의 가치에서 인용:

불확실성 앞에서도 행동에 치우는 경향을 가집니다. 긴 회의 논의보다는 실용적인 실행을 선호하며, 허락보다는 용서를 요청하는 것을 선호합니다. 결정이 명확하지 않은 경우, 특히 결정이 취소 가능한 경우, 결단력을 중요하게 여깁니다.

행동에 치우는 경향은 무모함과는 다릅니다. 오히려 책임감 있는 결정을 내리고, 그 결정을 즉각적으로 실행하는 경향이며, 여전히 남아 있는 모호성이나 알려지지 않은 정보가 있더라도 말입니다.