Project프로젝트

Contributing기여하기

Intent, then spec, then a failing test, then code.

의도, 사양, 실패하는 테스트, 그다음에 코드.

The workflow작업 흐름

Search the issues; open one if nothing covers your change, stating what, why, and which tests must pass.이슈를 검색하고, 없으면 무엇을·왜·어떤 테스트가 통과해야 하는지 적어 엽니다.
Work on a work/<topic> branch, push every commit, and open a pull request into develop that references the issue.work/<topic> 브랜치에서 작업하고 커밋마다 푸시한 뒤, 이슈를 가리키는 PR 을 develop 으로 엽니다.
Merge through the pull request, then close the issue with a comment naming it. Closes #N only fires on merges into main, so the comment is needed.PR 로 병합한 뒤 그 PR 을 적어 이슈를 닫습니다. Closes #N 은 main 으로의 병합에서만 동작하므로 댓글이 필요합니다.
main is generated from develop by CI and changes only through a pull request from release.main 은 CI 가 develop 에서 생성하며 release 에서 온 PR 로만 바뀝니다.

A test must be able to fail: break the implementation on purpose and watch it go red.테스트는 실패할 수 있어야 합니다: 구현을 일부러 깨고 빨개지는지 보십시오.
State the grade of every claim (builds, reaches or agrees) and derive tolerances from upstream rather than choosing them.모든 주장의 등급(빌드됨·도달함·일치함)을 밝히고, 허용오차는 고르지 말고 upstream 에서 유도하십시오.
An unsupported case refuses by name. Never invent a plausible answer, and never fall back silently.지원하지 않는 경우는 이름으로 거부합니다. 그럴듯한 답을 지어내거나 조용히 폴백하지 마십시오.
Report features, fixes, tests, documentation and deletions separately; a test count is not progress.기능·수정·테스트·문서·삭제를 나눠 보고하십시오. 테스트 수는 진척이 아닙니다.

bash tests/run.sh       # the gate: suites, golden self-test, DOCWATCH
python3 docs/guide/check_guide.py      # this site