관리자를 위한 가이드입니다. - 하나 이상의 코드 패턴 레퍼지토리에 기여하는 누구든.
이 레퍼지토리는 기존 관리주기가 없지만 대신 항상 유용하고, 유효하며, 정제된 레퍼런스로 관리되어야 합니다.
프로젝트 관리자들은 pull request 코멘트의 LGTM (Looks Good To Me)를 이용해 통합 전 승인을 표시합니다. 프로젝트관리자 2명의 LGTM이 있어야 수정이 이뤄집니다. 관리자가 코드를 작성했다면, LGTM 하나를 받았을 때 수정이 됩니다.
GitHub내에서 pull request를 검토하는 것이 좋습니다. 모든 유저에게 수정사항이 공개되므로 절차가 투명하게 진행되기 떄문입니다.
피드백을 남길 땐, 친절하게, 정중하게, 예의 있게 남겨주세요. 상대를 배려하며 이뤄지는 토론에서만 다른 의견은 허용됩니다.
무례하거나 모욕적인 코멘트를 남길 시, 기여에 대한 권한은 제한되며 프로젝트에서 제외됩니다.
검토 시에 아래 사항을 고려해주세요.
어떤 수정은 프로젝트에 긍정적이지 않을 수 있습니다. 작성자가 코드를 더 이해하기 쉽게 바꾸었는지, 그저 개인적 취향에 따라 수정했는지 따져보세요.
(bikeshedding를 참고하세요).
확실한 긍정적 변화가 없는 Pull request는 반려되어야 합니다.
수정사항이 무엇인지 모르겠다면 작성자에게 물어보세요. 추가 코멘트를 요청하거나, 의도를 명확히 하도록 testcase의 이름을 바꾸도록 하세요.
때때로 이런 과정은 작성자가 코드를 잘못 작성했거나, 자신이 필요한 기능을 알지 한다는 사실을 드러내줍니다.
pull request시, "새로운 기능이 있는지?" 자문해보세요. 그렇다면, 해당 pull request가(혹은 관련된 이슈가) 신기능에 대한 필요성을 충분히 설명하고 있는지 보아야 합니다. 그렇지 않다면 작성자에게 추가적인 설명을 요청하세요.
새로운 기능에 대한 테스트가 진행되고 있나요? 테스트가 완료될 때까진 통합하지 마세요! 새로운 기능에 대한 문서화가 되어 있나요? (문서 가이드라인을 참고하세요). 될 때까진 통합하면 안됩니다! 일반적인 용도에 필요한 기능인가요? 가능하면 되도록 요소 하나하나를 살펴봐주세요. 제안된 기능이 기준에 맞지 않는 경우엔, 요청을 반려하고 해당 기능을 직접 관리할 것을 작성자에게 말하세요. 또한 해당 기능이 다른 사용자 사이에서 호응이 있다면 다시 pull request할 것을 부탁하세요.