지원해야 할 구절 선택하기
기사에서 언급하기 전에 자신의 프로젝트 공개 README에 있는 설치 설명을 확인한다고 가정해 봅시다. 정확한 구절과 그 주변 조건을 찾으세요. 저장소 제목이나 프로필 약력은 해당 진술이 포함된 파일을 대체하지 않습니다.
작업을 문서로 제한하세요. 프로젝트를 실행하거나 개인 연락처 정보를 조사하거나 기여자의 계정을 사적 신원의 증거로 취급할 필요는 없습니다.
변하는 브랜치 보기를 버전 링크로 바꾸기
GitHub는 일반적인 파일 보기가 보통 브랜치의 현재 헤드를 보여주므로 커밋이 도착함에 따라 내용이 변경될 수 있다고 설명합니다. 파일을 보는 동안 y를 누르면 브랜치 이름 대신 특정 커밋을 사용하는 고유 링크로 URL이 변경됩니다. 출처
해당 작업 후 실제로 표시된 URL을 복사하세요. 다시 열어 동일한 파일과 구절을 보여주는지 확인하세요. 커밋 식별자를 만들어내거나 열어보지 않은 검색 미리보기에서 인용을 구성하지 마세요.
현재 브랜치 주소도 원한다면 별도로 기록하세요. 버전 링크는 “내가 어떤 문구를 검토했는가?”에 답하고, 브랜치 보기는 프로젝트가 현재 무엇을 제시하는지 확인할 수 있게 합니다.
다른 독자를 위해 충분한 맥락 기록하기
| 필드 | 검토에서 기록할 내용 | 목적 |
|---|---|---|
| 저장소 및 파일 | 실제 프로젝트와 파일 경로 | 인용되는 문서 식별 |
| 커밋 식별자 | 복사한 고유 링크에 있는 버전 | 이 스냅샷을 이후 편집과 구분 |
| 근거 구절 | 짧은 발췌 또는 충실한 요약 | 주장을 검토한 문구로 제한 |
| 주변 조건 | 버전, 환경 또는 기능 제한 | 조건을 누락하지 않도록 |
| 접근 날짜 | 소스를 연 시점 | 검토 시점을 게시 이력과 분리 |
내보내기 기능이 실험적이라고 명시한 예시 README의 경우, 지원되는 진술은 “실험적”을 유지합니다. 안정적인 URL이 이를 테스트된 보장으로 재작성하는 것을 정당화하지 않습니다. 이 예시는 인용 관행을 보여주며 실제 저장소에 대한 보고서가 아닙니다.
오래된 진술이 여전히 관련 있는지 판단하기
현재 브랜치가 다르다면 두 관찰을 모두 유지하세요: 인용한 이전 버전과 실제로 연 현재 문구. 동일한 검토라고 계속 설명하면서 오래된 인용을 조용히 교체하지 마세요.
파일에는 계획, 예시 또는 오래된 지침이 포함될 수 있습니다. 해당 진술을 프로젝트에 귀속시키고 구현을 독립적으로 테스트했다고 주장하지 마세요. 나중에 접근이 실패하면 그 한계를 기록하세요. 버전 식별자는 영구 호스팅이나 허가에 대한 약속이 아닙니다.
이는 서명된 커밋 배지와도 별개입니다. GitHub Verified 배지 가이드는 그 다른 신호를 다룹니다. 공개 문서에 대한 더 넓은 종합은 AI 소스 검토 체크리스트를 사용하고 각 중요한 주장이 의존하는 정확한 버전을 유지하세요.