기여하기

도움이 되는 기여는 대개 누군가 자기 일을 하다가 무언가에 부딪히는 데서 시작합니다. 페이지가 예상과 다르게 동작했습니다. 매뉴얼에 적힌 대로 설정했는데 그렇게 되지 않았습니다. 문서의 한 문장이 두 가지로 읽혔습니다. 절차가 자신에게 없는 권한을 전제하고 있었습니다. 이런 것들은 더 나은 프로젝트의 재료이고, 그것을 분명히 적어 남기는 일 자체가 기여입니다.

고칠 필요는 없습니다. 기대한 것, 실제로 일어난 것, 따라가던 문서를 정확히 적은 신고는 수정의 내용 자체를 전달하기 때문에 변경 자체보다 더 도움이 될 때가 적지 않습니다.

많은 버그는 소프트웨어를 쓰는 사람이 찾습니다. 그리고 빨리 고쳐지는 신고에는 공통된 성질이 있습니다. 서식을 요구해서가 아니라, 분명한 신고일수록 수정까지 가는 길이 짧기 때문입니다.

기대한 것과 일어난 것을 적는다. 그 둘의 차이가 버그입니다. “언어를 바꿨는데 언어 전환이 영어로 남아 있었다”는 무언가를 전달하지만, “사이트가 깨졌다”는 아무것도 전달하지 않습니다.

어디에서 일어났는지 적는다. 사이트가 쓰는 Foundation 판, 관련된 페이지나 경로, 언어에 한정된 문제라면 그 언어입니다. 한 언어에서만 일어나는 버그는 모든 언어에서 일어나는 버그와 다른 작업입니다.

무엇을 바꿨는지 적는다. 새 Foundation 프로젝트인지, 손을 댄 사이트인지가 중요합니다. 플랫폼 쪽 버그와 그 위에 만든 사이트의 버그는 다른 작업이고, 둘 다 알릴 가치가 있습니다.

메시지는 그대로 인용한다. 오류 문구 자체가 원인으로 가는 가장 짧은 길인 경우가 많고, 말을 바꾸면 확인에 필요한 부분이 사라집니다.

이미 해 본 것을 적는다. 같은 작업을 반복하지 않아도 되고, 문서가 다른 곳으로 이끌었다는 사실이 드러나기도 합니다. 그것은 문서 쪽 버그입니다.

신고가 아니라 기술적인 작업을 제공하고 싶다면 저장소에 프로젝트의 기대가 적혀 있습니다. 시간을 쓰기 전에 읽을 가치가 있습니다. 코딩 에이전트를 위한 작업 규칙, 아키텍처 문서, 검증 매뉴얼이 함께 코드를 만드는 방식, 변경에 무엇을 포함할지, 검증 관문이 무엇을 증명하는지를 설명합니다. 구현과 테스트가 실제로 확인하는 것보다 큰 능력을 주장해서는 안 된다는 프로젝트의 규칙도 그 안에 있습니다.

이 문서들은 커뮤니티의 헌장이 아니라 프로젝트 유지의 규율입니다. 이 코드를 어떻게 일관되게 유지하는지를 적어 두었고, 동시에 여력에 대해서도 솔직합니다. 리뷰하는 유지관리자의 수는 많지 않습니다. 테스트를 갖추고, 푸는 문제가 분명하며, 무관한 변경을 포함하지 않는 제안이 이해 부담을 상대에게 넘기는 제안보다 훨씬 잘 받아들여집니다.