개시하다

네, 그것도 좋아요.
How to write the perfect pull request - GitHub
화역
지적이 있으면 환영합니다!

좋은 요구 사항을 써야 한다

(원제: How to write the perfect pull request)
회사가 성장함에 따라 사람과 프로젝트에 변화가 생길 것이다.GiitHub에서 우리가 기대하는 문화를 키우기 위해 나는 우리가 자각적으로 교류해야 한다는 것을 깨달았다.우리 팀이 계속 최강할 수 있도록 최근 다음과 같은 요구 방침을 도입했다.

릭에 대한 평론

(원제: Approach to writing a Pull Request)

단체 요구에 명목으로 쓰세요.예를 들면...
이것은 조사의 원형이다
이것은 간소화할 것이다
이 수정~의 처리

초빙을 읽는 사람이 경위에 정통하다고 생각하지 말고 왜 이 일이 일어났는지 개요를 제공하도록 노력하세요.

회사의 누구나 요구를 읽을 수 있다는 것을 잊지 마세요.앞으로는 지금 참석하는 사람 외에도 내용과 분위기를 알아야 한다.

어떤 피드백을 원하는지 명확히 하세요.예를 들어'코드를 보십시오','기술적인 논의를 하고 싶다','디자인에 대한 비판을 원한다','문구 확인을 원한다'등

당김 요청 작업이 진행 중이라면 언제 피드백을 원하는지 명확히 하세요.제목의 첫머리에 [WIP]를 붙이는 것은 일을 하고 있다는 일반적인 방법이다.(번역문: WIP는 Work In Progress 작업 중 뜻)

토론에 참여하고 싶은 사람이 있으면 @hoge로 지정한다.그리고 왜 멘션까지.(예:/cc@jesseplusplus는 논리를 명확히 하기 위해

팀에 대해 멘션을 진행할 때도 마찬가지로 이유를 첨부해야 한다.(예:/cc@github/security 이렇게 해도 괜찮겠습니까?)

피드백 쓰기

(원제: Offering feedback)

문제의 내용과 왜 이런 요구가 생겼는지 미리 파악하세요.

전혀 동의하지 않는 상황에서 반응하기 전에 몇 분 동안 자신의 의견을 토론하자.

명령이 아니라 질문이죠.신지현: "하지 마세요..."보다는 "네가...어떻게 생각하세요?"

코드 변경을 요구한 이유를 설명한다.따르지 않으셨습니까스타일 가이드?개인 취향?)

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

다른 사람이 하는 일을 참고할 때'바보'등 경멸하는 단어를 사용하지 마세요.

좀 겸손해라.(잘 모르겠지만 한번 해보자...)

과장을 피한다.("절대...")

팀의 평론을 통해 전문 기술, 팀 지식, 제품의 질을 발전시키는 것을 목표로 하자.

온라인 커뮤니케이션에서 부정적인 편차가 발생할 수 있으므로 주의하십시오.(내용이 중립적이라면 부정적인 발언이라고 생각하는 경우가 많다).중립이 아니라 긍정적으로 쓸 수 있는지 생각해 보세요.

분위기를 명확히 하기 위해 그림문자를 사용하세요!"좋잖아요"와 "가 좋잖아"를 비교해 보세요.

대응 피드백

(원제: Responding to feedback)

아무튼 먼저 감사의 뜻을 표합니다.특히 피드백이 정확한 경우!

명확히 하세요.("잘 모르겠는데 다시 한 번 설명해 주시겠어요?"

질문을 받은 후 왜 이런 설치가 이루어졌는지 설명하고 상대방이 충분히 이해하도록 하세요.

가능하면 모든 댓글에 답장해 주세요.

관련 제출 및 제출 요청에 링크를 붙여주세요("1682851 그거 좋은 생각이에요!")

논쟁의 여지가 있거나 혼란스러우면 더 좋은 언어로 그들과 대화할 수 있는지 자문해 보세요.머리를 맞대고 이야기를 나누는 마음으로 오프라인 토론의 후속 보도를 정리하고 서로 투고하면 되잖아요.(앞으로 읽는 사람에게 도움이 된다)

이 지침은 Thoughtbot의code review 지침의 계발 아래 제정된 것이다.
이 방침은 우리가 일하는 추진 방법과 우리가 키우고 싶은 문화에 적합하다.나 이거 읽었으면 좋겠어. 너희도 그랬어!
Happy communicating!