작고 검토 가능한 단계로 작업합니다.

참여자 되기

저장소 README와 열린 이슈를 읽는 것부터 시작합니다. 첫 변경은 문서 수정, 작은 테스트, 좁은 버그 리포트, 또는 신규 참여자용 라벨이 붙은 이슈를 우선합니다.

복잡한 아키텍처, 공개 API, 릴리스, 보안, 또는 하드웨어에 민감한 작업을 시작하기 전에는 논의를 엽니다. 유지관리자가 해당 결정을 맡으며, 구현 전에 범위를 맞춰야 합니다.

저장소 선택

이슈와 Pull Request

기존 이슈와 Pull Request를 먼저 검색합니다. 이슈 하나에는 한 주제만 담고, 영향을 받는 저장소를 포함하며, 다른 참여자가 문제를 재현하거나 검토할 수 있는 충분한 맥락을 제공합니다.

Pull Request는 다음 브랜치를 대상으로 해야 합니다: main, stay focused, link the related issue or discussion, and describe motivation, approach, and verification. Avoid unrelated formatting, renames, generated output, or repository setting changes in the same diff.

보안 발견 사항은 공개 이슈에 보고하지 않습니다. 대신 조직 보안 정책을 사용합니다.

문서 작성 스타일

명확하게 씁니다. 구체적인 명사, 현재 프로젝트 상태, 명령 출력, 버전 식별자, 원본 자료 링크를 우선합니다. 구현된 것과 계획된 것을 분리합니다.

작업이 검토된 릴리스 경계에 도달하지 않았을 때는 development preview, pre-stable, early scaffold, host dry run 같은 신중한 라벨을 사용합니다. 홍보성 표현과 목표를 결과처럼 바꾸는 표현을 피합니다.

코드와 RTL 주석 스타일

주석은 의도, 불변조건, 인터페이스 경계, clock 및 reset 가정, 데이터 흐름 기대사항, 명확하지 않은 제약을 설명해야 합니다. 코드 각 줄을 서술하지 않습니다.

RTL 주석은 timing, handshake 동작, 폭, reset 상태, synthesis 가정 주변에서 특히 신중해야 합니다. 값이 임시라면 TODO 소유자나 이슈를 명시합니다. 경로가 생성된 것이라면 생성 원천을 분명히 합니다.

참여 기록과 검토 맥락

검토 노트에는 검토자에게 도움이 될 때 명령, 로그, 리포트, 스크린샷, 보드 설정, commit SHA, 모델 설정, 테스트 입력, CI 실행을 포함할 수 있습니다. 관련 기록은 이슈, Pull Request, 문서 페이지에서 연결합니다.

참여 노트는 소스 변경, 검증 기록, 문서화된 검토 단계에 집중합니다.