서론
지금까지 프로젝트를 할 때 Issue나 PR을 쓸 일이 있으면 이것을 읽는 사람들이 부가적인 질문을 하지 않아도 되게끔 자세하게 적으려고 신경을 썼었습니다. 신경을 쓴 것이 효과가 있었는지 팀 프로젝트를 함께 하는 사람들에게도, 심지어는 함께 프로젝트를 하지 않는 사람에게도 “지나가다 봤는데 PR을 되게 자세하게 적어주시더라구요.” 라는 말을 들어서 내심 “나 제법 배려심 있는 팀원 같다…” 라는 생각을 하고 있었는데요. (이제 와서 생각해보니 좀,,, 웃기네요.)
예전에 Issue나 PR을 어떻게 썼는지 문득 궁금해져서 예전에 프로젝트를 하며 썼던 Issue와 PR링크를 들고왔는데,, 어떻게 칭찬을 받았었지? 하는 허접한 글인 것 같네요…
아무튼 이런 묘한 자신감을 가지고 이번에 githru-vscode-ext 엔진 성능 개선 작업을 하면서 Issue와 PR을 작성했는데 (개인적으로는 충격적이게도) Issue와 PR Description의 내용이 불충분해 작업의 의도와 결과를 잘 이해하기 힘들다는 리뷰를 받았습니다. (이슈는 리뷰를 받은 이후에 좀 보완했습니다..ㅎㅎ)
이렇게 적으니까 이 사람 좀 기분 나빴나? 하는 느낌이 들 수도 있을 것 같은데 절대 아니고 “내가 너무 우물 안 개구리였구나..” 하는 생각에 뒤통수가 좀 얼얼했던,, 그런 느낌이었습니다.
지금까지는 작은 팀 단위로만 작업을 했었기 때문에 모든 의사 결정들이 전체 회의를 통해서 이루어졌고, 그렇기 때문에 제가 남기는 Issue의 의도나, PR의 전반적인 작업 내용을 리뷰에 참여하는 모든 팀원들이 아는 환경이었는데요. 생각해보니 이번 오픈소스 컨트리뷰션처럼 회의에 참여하지 않은 사람들에게 Issue나 PR을 보일 상황은 한번도 경험해보지 못했던 것 같습니다. 다른 분들이 다 이해하기 충분하다고 말씀해주셨던 Description들도 회의 참여자이기 때문에 충분하다고 느끼셨던 것이지 사실은 여전히 부족한 내용 이었을수도 있겠지요??
이렇게 리뷰를 받고 다음에 다시 PR을 올릴 상황이 되니 좀 긴장되더라고요. ㅋㅋㅋ 그래서 main 브랜치에 올리기 위한 최종 PR을 올리기 전에 다시 PR을 처음 올리던 시절로 돌아가,,, 좋은 PR Description에 대해 생각해 보기로 했습니다.
PR Description 잘 쓰기
사실 원래 목표는 실제 PR들 중에서 성능 최적화 관련된 PR들에 어떤 내용이 있는지를 확인해보고 참고하려고 했었는데,,, 생각보다 공개되어 있는 레포지토리 중에서 성능 최적화 관련된 PR이 많이 없거나,,, 생각보다 내용이 빈약한 PR들이 많더라구요..
그래서 실제 사례들 외에도 좋은 PR에 대한 글들도 함께 찾아보았습니다.
새삼스럽게도 너무 당연한
•
관련 이슈
•
작업 내용
•
필요한 후속 논의 사항
•
(필요하다면) 스크린샷
이런 내용은 살짝 생략하고, 위의 링크한 글들과 PR을 보고 PR Description에 챙겨 적으면 좋겠다고 생각했던 항목은
•
(변경점이 있다면) 과거에는 어땠는지, 작업 결과 현재는 어떻게 변했는지 설명하기 (AS-IS, TO-BE)
•
왜 이 PR을 올리게 되었는지.
이 두가지 항목입니다.
과거에 작성했던 PR을 되돌아보니 가장 중요한데 왜 빼먹었지? 하는 생각이 드는 것이 “왜 이 PR을 올리게 되었는지.” 인 것 같습니다. 위에 링크했던 medium의 글에서 표현했던 것 처럼 저도 Pull Request가 단순히 코드 병합을 위한 절차라기보다는 저의 작업 결과를 다른 사람에게 설명하고, 이 작업이 main에 올라가야 한다고 설득하는 단계라고도 할 수 있겠다는 생각이 들었습니다. 그렇기 때문에 왜 이 작업을 시작했고, 이 작업에 어떤 효과가 있어서 main 브랜치에 올라가야 하는지 설명하는 부분이 필요하구요. 뭔가… 이렇게 생각하니 당연한 것 같고 지금까지 올렸던 PR들이 죄다 ‘나 이러이러한것 작업했다! 올려라!’ 이런 통보의 느낌(ㅋㅋㅋ) 인 것 같아 좀 민망하네요..
## Related issue
<!-- 현재 올리는 PR과 관련된 이슈를 링크 -->
<!-- 이 PR을 통해 Close할 이슈는 키워드를 이용해 링크하면 편함 -->
## Result
<!-- 어떤 작업을 했는지 "간단히" 정리 -->
<!-- 이유는 ISSUE에 자세히 적었으므로 생략 -->
### AS-IS
<!-- 변경 전 상태에 대한 설명 -->
### TO-BE
<!-- 변경 후 변화된 결과에 대한 설명 -->
<!-- (저의 경우) 테스트코드를 추가했으므로 테스트 결과 스크린샷 추가 -->
## Work list
<!-- 어떤 작업을 했는지 설명 -->
## Discussion
<!-- 의논이 필요한 내용 정리 -->
Plain Text
복사
결과! (추가)
위에서 정한 형식을 정리해서 PR을 남겼는데, 너무나도 뿌듯한 리뷰를 받아 공유합니다. (얏~~~호~~~~
)