풀 리퀘스트 검토 받기¶

풀 리퀘스트가 제출되었으며 CI를 통과했습니다. 이제 검토할 준비가 되었습니다.

tl;dr - 검토 과정¶

검토 절차의 간략한 요약:

검토를 기다리십시오.
피드백에 응답하십시오.
변경 요청 시:
요청된 변경 사항을 완료하도록 진행하십시오.
요청된 모든 변경 사항을 제출하십시오.
요청한 모든 변경 사항이 제출된 후 재검토를 요청하십시오.
더 이상 변경할 사항이 없을 때까지 세 번째 단계를 반복하십시오.
풀 리퀘스트가 승인되고 병합될 때까지 기다리세요.

축하합니다! 방금 BeeWare에 기여하셨습니다!

풀 리퀘스트를 제출했는데, 다음 단계는 무엇인가요?¶

풀 리퀘스트를 제출한 후에는 기여 내용에 대한 검토를 기다려야 합니다. 검토 과정에는 두 가지 측면이 있습니다: 검토를 제공하는 것과 검토를 받는 것입니다.

기대 검토

귀하의 제출물을 검토하는 모든 사람이 이 지침을 따를 것으로 예상해야 합니다. 핵심 팀 구성원의 검토도 포함됩니다. 또한 다른 사람의 제출물을 검토할 때에도 이 지침을 따라야 합니다.

리뷰어가 이러한 기대치에서 벗어났다고 느끼시고, 풀 리퀘스트에서 직접 문제를 제기하는 것이 불편하지 않으시다면 그렇게 하셔도 됩니다. 만약 불편하시다면 BeeWare 행동 강령 대응팀에 연락해 주십시오. 저희가 신고 내용을 검토한 후 해당 리뷰어와 후속 조치를 진행할 것입니다. 후속 조치는 신고된 행동의 심각성에 따라 달라집니다. 경미한 위반은 논의로 이어질 수 있으며, 중대한 위반은 더 심각한 조치가 취해질 수 있습니다.

검토 제공¶

모든 분들은 어떤 풀 리퀘스트에 대해서도 리뷰를 제공하실 수 있습니다. 이 가이드라인은 핵심 팀 구성원이든 커뮤니티 구성원이든 관계없이 리뷰에 대한 우리의 기대 사항을 설명합니다.

핵심 팀 구성원이 항상 최종 검토를 수행해야 하지만, 커뮤니티 구성원의 검토는 프로세스를 효율화하는 데 도움이 될 수 있습니다. 이상적으로는 커뮤니티 검토를 통해 주요 문제점이 모두 확인된 후 핵심 팀의 검토는 형식적인 절차로 이루어져야 합니다.

리뷰 받기¶

검토를 받는 과정은 세 가지 기본 단계로 이루어집니다:

초기 피드백 및 질문.
변경 요청.
승인 및 병합.

각 단계는 아래에 상세히 설명되어 있습니다. 과정 중 언제든지 궁금한 점이 있으시면 주저하지 마시고 문의해 주세요! 기꺼이 도와드리겠습니다.

타임라인 및 초기 피드백¶

핵심 팀은 모든 풀 리퀘스트가 영업일 기준 10일 이내에 검토를 받도록 노력합니다. 그러나 제출 내용이 복잡하거나 팀 일부가 휴가 중인 시기에 풀 리퀘스트가 제출될 경우 해당 일정이 연장될 수 있습니다.

일반적으로 각 풀 리퀘스트에 대해 검토자와의 연속성을 유지합니다. 즉, 전체 검토 과정 동안 동일한 검토자와 협업하게 될 가능성이 높습니다. 이는 검토자가 전 과정에 걸쳐 맥락을 파악할 수 있으며, 응답 빈도와 검토 스타일에 대해 예상할 수 있는 점을 학습할 수 있음을 의미합니다. 초기 검토자가 풀 리퀘스트 검토에 필요한 전문 지식이 부족하다고 판단하거나, 어떤 이유로든 검토가 불가능할 경우, 해당 풀 리퀘스트의 검토 책임을 다른 팀원에게 넘길 수 있습니다.

각 문의 사항에 대해 영업일 기준 10일 이내에 답변을 드릴 예정입니다. 피드백과 질문에 대한 답변은 검토 과정의 필수적인 부분입니다. 다음 단계로 진행하기 전에 귀하의 답변을 기다릴 것입니다.

변경 요청¶

대부분의 경우, 검토자는 풀 리퀘스트에 대한 변경을 요청할 것입니다. 이는 반드시 여러분의 작업에 대한 평가가 아니라, 단순히 프로세스의 일부일 뿐입니다.

초기 검토에서 상당한 수의 문제가 발견될 경우, 첫 번째 검토는 포괄적이지 않을 수 있습니다. 대신, 풀 리퀘스트를 병합 가능한 상태로 만들기 위해 필요한 작업에 대한 고수준 지침을 제공하는 데 중점을 둘 것입니다. 검토 과정에는 시도된 작업의 목적과 범위를 명확히 하기 위한 질문이 포함될 수 있습니다.

요청된 변경 사항을 처리하십시오¶

검토자는 풀 리퀘스트에 코멘트를 게시합니다. 이러한 코멘트는 일반적인 내용, 특정 파일, 또는 특정 코드 줄에 대한 것일 수 있습니다. 때로는 GitHub UI를 통해 풀 리퀘스트에 적용할 수 있는 직접적인 수정 제안이 포함되기도 합니다. 일반적으로 질문, 설명 요청 또는 업데이트에 대한 지침 형태로 제공됩니다.

대화를 해결된 것으로 표시하기

피드백 과정의 논의 단계에서는 검토자가 시작한 대화를 절대 "해결됨"으로 표시해서는 안 됩니다. 대화의 해결 여부를 표시하는 것은 검토자의 책임입니다. 식별된 문제가 해결되었는지 여부를 판단하는 것은 검토자의 권한입니다.

검토 과정에서 체계적인 문제(예: 코드 내 존재하는 명명 불일치)가 발견되면, 검토자는 해당 문제의 모든 사례를 일일이 지적하지 않을 수 있습니다. 대신 문제의 몇 가지 사례를 선택하여 다른 사례들도 수정해야 함을 알릴 수 있습니다. 검토에서 한 곳의 문제가 지적되었고, 다른 곳에도 해당될 수 있다고 생각되면 문제가 발생하는 모든 곳에서 수정해야 합니다. 확실하지 않다면 검토자에게 명확히 설명을 요청하십시오.

요청된 모든 변경 사항을 제출하십시오¶

요청된 모든 변경 사항을 반영한 후에는 풀 리퀘스트에 업데이트를 푸시할 수 있습니다. 이렇게 하면 새로운 CI 실행이 트리거됩니다. CI가 여전히 통과하는지 확인한 후, 업데이트된 검토를 요청하는 댓글을 남기면 코어 팀이 풀 리퀘스트를 다시 검토할 것입니다.

강제로 밀어넣지 말고, 리베이스하지 마세요

리뷰 중에 풀 리퀘스트를 업데이트할 때는 커밋 기록을 그대로 유지하는 것이 중요합니다. 커밋 목록이 아무리 길어도 상관없습니다. 풀 리퀘스트를 병합할 때 모두 압축됩니다. 리뷰 도중에 풀 리퀘스트를 강제 푸시하거나 리베이스하면 리뷰어가 필요로 하는 중요한 맥락을 제거할 수 있습니다.

재검토 요청¶

주어진 리뷰에서 요청된 모든 변경 사항을 해결하고 CI가 다시 통과되면, 리뷰어에게 재검토를 요청할 수 있습니다. 문제가 특히 복잡하고 한 부분을 수정하면 다른 부분에 영향을 미치는 경우, 업데이트한 특정 부분에 대한 검토를 요청할 수 있습니다. 모든 검토 요청은 전체 검토 요청으로 간주됩니다. 전체 검토를 받을 준비가 되지 않았다면, 정확히 어떤 부분을 검토받길 원하는지 명시해야 합니다.

풀 리퀘스트 승인 및 병합¶

모든 변경 요청에 대한 응답이 완료되면 풀 리퀘스트가 승인됩니다. 대부분의 경우 풀 리퀘스트가 승인되면 즉시 병합합니다. 다만 다른 미병합 풀 리퀘스트에 의존하는 등 특별한 사정이 있을 경우 지연될 수 있습니다. 이러한 상황은 댓글로 안내드리므로 상황을 파악하실 수 있습니다.