개발 프로세스

GitLab에 기여하기 위한 개발 프로세스에 대한 정보는 이 주제를 참조하세요.

프로세스

필독서:

보충자료:

개발 가이드라인 변경 시 경험이 풍부한 GitLab 팀원에게 리뷰 및 승인을 요청하세요.

예를 들어, 특정 그룹에서 독점적으로 사용하는 새로운 내부 API를 문서화하는 경우, 해당 그룹의 구성원 중 한 사람에게 엔지니어링 리뷰를 요청하세요.

오타와 같은 작은 수정은 최소한 유지 관리자 역할을 가진 사용자라면 누구나 병합할 수 있습니다.

일부 변경 사항은 둘 이상의 그룹에 영향을 미칠 수 있습니다. 예를 들어:

이 경우 다음 워크플로를 사용하세요:

팀원의 동료 리뷰를 요청합니다.
해당 분야의 책임자인 엔지니어링 매니저(EM) 또는 스태프 엔지니어에게 리뷰 및 승인을 요청합니다:
EM이나 해당 분야의 스태프 엔지니어가 작성한 MR의 경우 이 단계를 건너뛸 수 있습니다.

여러 그룹에 영향을 미치는 경우 각 영향을 받는 분야의 EM/스태프 엔지니어 수준에서 승인이 필요할 수 있습니다.
리뷰가 완료된 후, MR의 작성자/승인자인 EM/스태프 엔지니어와 상담하세요.

여러 분야에 걸쳐 중요한 변경 사항인 경우, 개발 가이드라인의 DRI인 개발 VP에게 최종 리뷰 및 승인을 요청하세요.

모든 유지 관리자는 MR을 병합할 수 있습니다.

기술 작가의 리뷰를 원하시면 #docs Slack 채널에 메시지를 게시하세요.

기술 작가가 내용을 리뷰할 필요는 없으며, MR 작성자를 제외한 모든 Maintainer는 병합할 수 있습니다.

리뷰어 또는 리뷰를 받는 사람으로서 GitLab에서 우리가 노력하는 리뷰어 가치를 숙지하세요.

또한, 모든 문서 내용은 문서 스타일 가이드를 따라야 합니다.

이슈 또는 병합 요청에 댓글을 작성하거나 다른 커뮤니케이션 모드를 사용할 때,

“MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”,

및 “OPTIONAL”과 같은 용어를 사용할 때 IETF 표준을 따라야 합니다.

이렇게 하면 서로 다른 문화의 다양한 팀원이 사용되는 용어를 명확히 이해할 수 있습니다.