기여 기록하기

Gerrit에 CL을 올렸다면 기여 내역을 data/contributions/에 기록해 이 사이트에 반영합니다. 기록된 내역은 기여 목록과 통계, 기여자 페이지에 자동으로 집계됩니다.

저장소 fork·clone·upstream 설정이 아직이라면 CONTRIBUTING.md의 "공통" 섹션을 먼저 따라 하세요.

0. Gerrit 기본 설정 — 새 CL을 Work in Progress로 (최초 1회)

Gerrit 설정의 Preferences에서 Set new changes to "work in progress" by default를 체크하세요.

• 체크해 두면 git cl upload로 올린 CL이 리뷰어에게 바로 노출되지 않는 WIP(Work in Progress) 상태로 만들어집니다.
• 멘토에게 커밋 메시지와 변경 내용을 확인받은 뒤, Gerrit 화면에서 Start Review를 눌러 리뷰를 시작합니다.

1. 기록 파일 만들기

data/contributions/template.md를 {ChromiumReviewId}.md로 복사합니다.

cp data/contributions/template.md data/contributions/6520751.md

ChromiumReviewId는 Gerrit URL의 마지막 숫자입니다. 예: https://chromium-review.googlesource.com/c/chromium/src/+/6520751 → 6520751.md

frontmatter 작성 규칙

• module은 기여한 코드 영역 하나를, kind는 fix, feature, refactor, test, docs, cleanup 등 변경 유형 하나를 적습니다. 세부 주제는 keywords에 순서대로 적으세요. 기존 기록의 labels는 검색어 유지를 위해 같은 순서로 keywords에 옮겼습니다. 새 기록에는 labels를 쓰지 않습니다.
• 새 CL은 status: in review로 시작합니다. 결과가 확정되면 merged 또는 abandoned로 갱신합니다. CL을 중단했다면 본문에 시도한 접근과 중단 이유를 적으세요.
• resolvedDate는 Gerrit에서 정확한 merge 또는 abandon 날짜를 확인한 경우에만 추가하세요. date는 결과와 관계없이 최초 업로드 날짜로 유지합니다.
• 사이트에는 date를 Created, resolvedDate를 Closed로 표시합니다. 리뷰 중이거나 종료 날짜가 확인되지 않은 항목에는 Closed를 표시하지 않습니다.
• Gerrit의 최초 생성 시각 created를 date, 실제 제출 완료 시각 submitted를 머지된 CL의 resolvedDate로 기록합니다. Abandoned CL은 마지막 abandon 이벤트의 시각을 확인합니다. 댓글·patchset 변경에도 바뀌는 updated는 Created나 Closed 날짜로 사용하지 않습니다. 날짜는 모두 UTC의 YYYY-MM-DD입니다.
• 독립 GitHub PR은 최초 생성 시각 created_at과 머지 시각 merged_at을 같은 UTC 기준으로 사용합니다. 리뷰 중인 항목에는 결과 날짜를 적지 않습니다.
• date는 반드시 유효한 YYYY-MM-DD 형식이어야 합니다. 잘못된 날짜(예: 2025-05-D8)는 CI에서 걸리고, 통과하더라도 목록 정렬을 조용히 깨뜨립니다.
• author는 기여자 페이지 링크와 아바타에 그대로 사용되므로 정확한 GitHub ID를 적으세요.
• 템플릿의 안내 주석(# github.com/GitHubId, # Add XXXXX from ... 등)은 모두 지우세요.

모듈 분류 기준

module은 기여의 핵심 동작을 담당하는 상위 영역입니다. 세부 디렉터리, API 이름, 변경 유형을 새 모듈로 만들지 않습니다. 여러 영역을 수정한 경우 주된 동작이 바뀐 영역 하나를 선택하고, 보조 영역은 keywords에 기록합니다. AUTHORS, 공통 빌드 설정이나 테스트 baseline만으로 모듈을 결정하지 않습니다.

• net/dns는 network, components/viz는 graphics, chrome/browser/ash는 platform으로 기록합니다.
• 특정 기능을 설명하는 문서는 해당 영역을 선택합니다. 예를 들어 샌드박스 문서는 security, Views 예제 문서는 ui입니다. 공통 개발 가이드는 docs입니다.
• 저장소는 별도의 repo, 변경 유형은 kind, 세부 경로와 API 이름은 keywords로 구분합니다. 예를 들어 독립 CSS WPT도 모듈은 blink이고, 저장소는 web-platform-tests/wpt입니다.
• 기존 세부 모듈 값은 검색어를 잃지 않도록 keywords에 보존합니다. 허용 목록을 늘릴 때는 기존 영역으로 분류할 수 없는지 먼저 검토합니다.

본문 작성

• 문제 설명 / 해결 내용 / 테스트 방법 / 배운 점 / 참고 자료 — 각 섹션의 안내 문구를 실제 내용으로 교체합니다.
• 해당 사항이 없는 섹션(예: 문서 수정이라 테스트가 없는 경우)은 제거해도 됩니다.
• 템플릿에 있는 https://example.com 같은 placeholder 링크는 반드시 제거하세요.

필요한 데이터만 기록하기

• date와 resolvedDate는 최초 업로드와 결과 확정이라는 서로 다른 시점을 나타냅니다. 결과가 확인된 경우 두 날짜를 구분해 기록합니다.
• module은 기능 영역, kind는 변경 유형, keywords는 검색어입니다. 같은 내용을 별도의 labels 필드로 중복 입력하지 않습니다.
• repo, issue, crbug, related, externalLinks는 확인된 정보가 있을 때만 적습니다. 기본 저장소인 chromium/src와 비어 있는 선택 필드는 생략할 수 있습니다.
• 파생 이슈·PR은 원본 기여의 externalLinks로 연결합니다. 자동 WPT export와 후속 테스트 PR을 새 기여로 중복 집계하지 않습니다.
• 안내 주석·문구, 예시 제목과 placeholder 링크는 실제 기록에서 제거합니다. 테스트 코드 안에서 쓰는 example.com 같은 예시 값은 그대로 둡니다.

2. 로컬 검증

PR을 올리기 전에 CI 검사 중 데이터 관련 두 가지를 로컬에서 돌려봅니다. (CI는 이 외에 테스트·ESLint·빌드도 실행하지만, data/contributions/만 추가했다면 아래 두 가지가 통과하면 충분합니다.)

npm run validate:data   # frontmatter 검사
npm run lint:md         # 마크다운 린트

렌더링을 직접 확인하려면 npm run dev 실행 후 http://localhost:3000/contributions/patches/에서 본인 항목을 열어보세요.

3. PR 올리기

git checkout -b 250725-contribution-6520751   # 브랜치명: YYMMDD-주제
git add data/contributions/6520751.md
git commit -m "contributions: Add 6520751"
git push origin 250725-contribution-6520751

• 커밋 메시지: data/contributions/ 변경은 contributions: prefix를 사용합니다. 제목은 현재형 동사로 시작, 첫 글자 대문자, 마침표 없음.
• push 후 GitHub에서 본인 fork 페이지에 뜨는 Compare & pull request 버튼을 누르거나, fork의 해당 브랜치에서 Contribute → Open pull request로 PR을 생성합니다.
• base가 OSSCA-chromium/contributions의 main인지 확인하세요 (본인 fork의 main이 아닙니다).
• CI(테스트·린트·데이터 검증)가 통과하는지 확인하고, 실패하면 로그를 보고 수정 커밋을 추가합니다.
• PR이 merge되면 사이트에 자동 배포됩니다(수 분 소요).

4. CL 결과가 확정되면 — status 갱신

Gerrit에서 CL이 merge되거나 abandon되면 후속 PR로 status를 갱신합니다.

git checkout main && git pull
git checkout -b 250801-merged-6520751

data/contributions/6520751.md의 frontmatter에서 status: in review를 결과에 따라 status: merged 또는 status: abandoned로 수정합니다. Gerrit에서 정확한 결과 날짜를 확인했다면 resolvedDate: YYYY-MM-DD도 추가하세요. date는 업로드 날짜이므로 바꾸지 않습니다. 같은 방식으로 커밋·push·PR을 올립니다.

git commit -am "contributions: Mark 6520751 as merged"
git push origin 250801-merged-6520751

관리자 일괄 갱신

멘티는 위 절차로 기여 내용과 회고, 초기 module·kind·keywords를 기록합니다. 관리자는 별도의 일괄 갱신으로 외부 리뷰의 실제 날짜와 상태를 확인합니다. 갱신 플래그를 멘티의 frontmatter에 추가할 필요는 없습니다.

npm run sync:contributions -- --dry-run   # 변경 미리보기
npm run sync:contributions                # 날짜·상태 반영

• 공개 Gerrit·GitHub PR의 생성 시각과 실제 머지·중단 시각을 UTC 날짜로 반영합니다. 본문·회고·작성자·관련 링크와 초기 분류는 보존합니다.
• 확인을 완료한 Merged 항목은 별도 관리 파일 data/maintenance/contribution-sync.json의 finalized 플래그로 표시하고 다음 기본 실행에서 건너뜁니다. 날짜·상태·리뷰 URL을 수동으로 바꾸면 저장된 지문이 달라져 다시 확인합니다. Abandoned 항목은 복원될 수 있어 계속 확인합니다.
• 실제 날짜와 관리자가 확인한 시각은 다릅니다. 관리 파일의 verifiedAt은 확인 이력이며 사이트의 기여 날짜로 사용하지 않습니다.
• 미리보기와 실패한 조회는 갱신 완료 플래그를 기록하지 않습니다. 실행 결과는 .cache/contribution-sync/report.json에서 확인합니다.

분류 기준을 바꾸거나 기존 Merged 항목까지 다시 확인하려면 강제 실행합니다.

npm run sync:contributions -- --force --dry-run

스크립트는 날짜·상태를 확정하고, 저장소의 sync-contributions skill은 전체 기여 기록·변경 파일·현재 분포를 보고 module과 kind를 검토합니다. 검토한 분류 변경만 별도 JSON으로 전달해 적용합니다.

npm run sync:contributions -- --force --classification-file .cache/contribution-sync/classifications.json

분류 파일은 { "8300812": { "module": "blink", "kind": "fix" } }처럼 기여 ID별로 작성합니다. 생략한 값은 유지하고, 모듈이 바뀌면 이전 값은 검색어에 보존합니다. 스크립트의 --force만으로 분류를 자동 추정하지 않습니다. skill 절차는 저장소의 .agents/skills/sync-contributions/SKILL.md에 있습니다.

일괄 갱신은 멘티의 신규 기여 PR과 별도 관리 PR로 올립니다.

5. GitHub 이슈·프로젝트 보드

• 실습 이슈는 오른쪽 Assignees에 본인을 직접 지정(self-assign)해 시작합니다 (이슈당 1인, 선착순).
• 담당한 GitHub 이슈에 Gerrit CL 링크와 기여 기록 PR 링크를 코멘트로 남기세요.
• 진행 상태에 따라 프로젝트 보드(2026 Chromium Issues)의 Status를 직접 변경하세요: 멘티 작업 진행 중 → 멘토 리뷰 중 → gerrit 리뷰 중 → 반영 완료.
• 이슈 close는 멘토가 처리합니다.

자주 하는 실수

작년(2025) 기록에서 실제로 반복됐던 실수들입니다.

1. 템플릿 주석 잔재 — author: ppirabbang # github.com/GitHubId처럼 안내 주석을 지우지 않고 제출.
2. placeholder 링크 방치 — 참고 자료에 [관련 문서 링크](https://example.com)가 그대로 남음.
3. 섹션 내용 뒤바뀜 — "테스트 방법" 섹션에 배운 점을 작성하는 등 안내 문구와 내용이 어긋남.
4. status 미갱신 — CL은 merge됐는데 기록은 계속 in review로 남아 통계가 틀어짐.
5. 커밋 메시지 형식 — Create 6619930.md, Update 6508290.md 같은 기본 메시지 사용. contributions: Add 6619930 형식을 지켜주세요.