GitHub에서 일하는 Keavy McMinn씨의 블로그 보도 "How to write the perfect pull request"에 대한 소개를 봤는데, 이게 좋다고 생각해서 번역을 해 봤어요.
제 생각에도 착오가 있을 것 같습니다. 지적해 주시면 기쁘겠습니다.

완벽한 팟캐스트 방법

회사가 발전함에 따라 직원과 프로젝트도 변화할 것이다.GiitHub에 필요한 문화를 유지하기 위해 교류할 때 이 목적이 중요하다는 것을 깨달았다.따라서 집단 팟캐스트의 공동 작업 중 최고의 자신이 될 수 있도록 최근 몇 년 동안 다음과 같은 가이드라인을 도입했다.

요청 작성 안내서

요청의 목적을 적으세요.예:

～を調査する技術検証
～の表示の簡素化
～の取り回しの修正

왜 현재 작업의 개요를 썼는지 확인(참고 링크 첨부);지금까지의 경과가 널리 알려졌다고 가정할 수 없다.

모든 직원이 요구를 볼 수 있다는 것을 기억해라.내용과 분위기는 지금 참석하지 않은 사람들에게도 좋다.

있다면 원하는 피드백을 명확하게 기입해 주십시오. 코드를 통과하기를 원합니다.나는 기술 방법을 토론하고 싶다.디자인에 대한 비평을 원합니다.초안 평론.

요청이 중도 단계라면 피드백이 언제 필요한지 알려주세요.제목에'[WIP]'접두사를 붙이는 것은 이를 나타내기 위한 단순하고 일반적인 패턴이다.(번역문: Work In Progress의 줄임말로 반제품을 뜻함)

토론하고 싶은 사람을 지정하려면 개인@mention을 대상으로 뒤에 논점을 써야 한다.("/cc@jesseplusplus이 논리를 명확히 하고 싶다"

토론하고 싶은 팀@mention에게도 뒤에 논점을 기술했다.("/cc@github/security, 이 방법은 걱정되는 점이 있으니 한번 시도해 보세요 63;")

피드백 제공

과제의 배경과 제약, 그리고 이 청구가 버려진 이유를 잘 알고 있죠.

명확하게 이해할 수 없을 때 대답하기 전에 몇 분 동안 자세히 고려한다.말하기 전에 잘 생각해봐.

일방적으로 말하지 말고 물어봐.신지현: "아니..."보다는 "...해보는 게 어때?"

코드를 변경해야 하는 이유를 설명한다.안 따라왔죠?개인적인 취향인가요?

코드를 간소화하거나 개선하는 방법을 제공한다.

다른 사람의 일을 인용할 때'어리석다'등 경멸적인 용어를 쓰지 않는다.

겸손해야 한다.(확실하지 않으니 해 보세요...)

과장은 피하세요.(죽어도 싫어...)

팀의 리뷰를 통해 전문 기술 육성, 지식 집합과 제품의 질을 목표로 하자.

온라인 교류 시 소극적인 편압에 주의하세요.(내용이 중립적일 때 우리는 소극적인 분위기를 가정한다.)중립적이지 않게, 긍정적인 언어를 써볼까?

도화문자로 분위기를 명확히 하세요." 괜찮아 보인다"와 "괜찮아 보인다"를 비교해 보세요.

대응 피드백

감사한 마음을 전하면서 진행하자.특히 피드백이 백열화될 때 중요하다.

명확히 하세요.송이경(신지현): 이해가 안 가요.

명확한 요구가 있으면 문제를 해결하기 전에 당신의 판단을 설명해 주세요.

모든 평론에 반응해 보세요.

원래 제출 또는 제출 요청에 연결하십시오.(너무 좋아요.

불이 났을 때 지금 평론을 계속하는 교류 형식이 적합한지 고려해 보세요.(가상이라도) 얼굴로 얼굴을 향해 말하고 오프라인에서 토론의 후속 내용을 총괄해 보세요.(기고는 나중에 읽는 사람에게 유익하다)

이러한 지도 방침의 일부는 Thoughtbot의스타일 가이드에 의해 촉발되었다.
우리의 지도 방침은 자신의 업무 방식과 키우고 싶은 문화에 적응하는 것이다.여러분을 도울 수 있다면 다행입니다.
즐거운 교류!

오리지널

"How to write the perfect pull request", Keavy McMinn, January 22, 2015. 코드 검사 가이드