이슈 워크플로우
이슈 생성
이슈를 제출하기 전에 이슈 트래커에서 검색 하여 유사한 항목을 찾으세요. 다른 사람이 이미 동일한 버그나 기능 제안을 한 경우가 있을 수 있습니다. 기존 이슈를 발견하면 이모지 반응으로 지원을 표시하고 토의에 참여하세요.
버그
버그를 제출하려면:
-
‘Bug’ 이슈 템플릿을 사용하세요.
코멘트 내의 (
<!-- ... -->) 텍스트가 포함해야 할 정보를 안내해줄 것입니다. - 의심되는 보안 취약점을 신고하려면 GitLab.com 웹사이트에서 공개 프로세스를 따르세요.
기능 제안
기능 제안을 생성하려면, 이슈 트래커에서 상세 기능 제안 이슈 템플릿을 열어주세요.
기능 제안을 추적하기 위해 우리는 ~"type::feature" 라벨을 사용합니다.
프로젝트 회원이 아닌 사용자는 UI를 통해 라벨을 추가할 수 없습니다.
대신 반응적인 라벨 명령어를 사용하세요.
기능 제안을 가능한 한 작고 간단하게 유지하며, 복잡한 것들은 작고 간단하게 편집될 수 있습니다.
사용자 인터페이스 (UI) 변경 사항에 대해서는 디자인 및 UI 가이드라인을 따르고,
시각적 예제(스크린샷, 와이어프레임 또는 모형)를 포함하세요. 해당 이슈에는 ~UX" 라벨을 부여하세요 (반응적인 라벨 명령어 사용) 제품 디자인 팀에서 의견과 안내를 제공할 수 있도록 합니다.
작업할 이슈 찾기
GitLab에는 작업할 수 있는 75,000개 이상의 이슈가 있습니다.
라벨을 사용하여 이슈를 필터링하고 찾을 수 있습니다.
새 기여자는 quick win 라벨이 붙은 이슈를 찾을 수 있습니다.
frontend 및 backend 라벨도 이슈 디렉터리을 정제하는 좋은 선택입니다.
이슈 명확화/검증
많은 이슈가 최근에 방문되거나 유효성이 검증되지 않았습니다. 이슈를 해결하기 전에 다음 단계를 거쳐야 합니다:
- 작성자에게 이슈가 여전히 관련이 있는지 물어보세요.
- 커뮤니티에게 이슈가 여전히 관련이 있는지 물어보세요.
- 다음을 검증하려고 노력해보세요:
- 이미 Merge Request이 생성되었는지 (관련 Merge Request 섹션 참조). 때로는 이슈가 닫히지 않거나 업데이트되지 않습니다.
-
type::bug가 여전히 존재하는지(재생성하여 확인). -
type::feature가 이미 구현되지 않았는지(시도하여 확인).
이슈 작업
작업하고자 하는 이슈에 대해 작업을 원한다는 것을 나타내고
할당될 것을 요청하는 메모를 남기세요 (작성자 및/또는 @gitlab-org/coaches를 언급하세요).
문제가 생긴 경우 또는 이슈를 제대로 이해하지 못한 경우 작성자나 커뮤니티에 도움을 요청할 수 있습니다.
이슈 트리지
우리의 이슈 트리지 정책은 핸드북에 설명되어 있습니다. 당신은 GitLab 팀이 이슈 트리지에 도움을 환영합니다.
가장 중요한 것은 유효한 이슈가 개발팀으로부터 피드백을 받는 것입니다. 따라서 최우선 순위는 해당 이슈에 도움을 줄 수 있는 개발자들을 언급하는 것입니다. 해당 분야의 경험이 있는 사람을 선택하세요 GitLab 팀에서. 해당 분야의 경험이 있는 사람이 없는 경우, 영향 받는 파일의 커밋 기록을 확인하여 찾아보세요.
우리는 또한 핸드북에서 설명된 트리지 자동화가 있습니다.(핸드북)
이슈에 적용할 라벨에 대한 정보는 라벨을 참조하세요.
이슈 가중치
이슈 가중치를 통해 하나 또는 여러 이슈를 해결하는 데 필요한 작업량에 대한 감을 얻을 수 있습니다. 이를 통해 작업을 더 정확하게 예약할 수 있습니다.
어떤 이슈에 대한 가중치를 설정하는 것을 권장합니다. 아래의 지침을 따르면 불필요한 부담 없이 이를 쉽게 관리할 수 있습니다.
- 가능한 빨리 모든 이슈에 가중치를 설정하세요
- 설정된 가중치에 동의하지 않는다면, 다른 개발자들과 논의하세요 해당 가중치에 대해 합의에 도달할 때까지
- 이슈 가중치는 이슈의 복잡성에 대한 추상적인 메트릭입니다. 이슈 가중치를 직접 시간과 관련시키지 마세요. 이것을 앵커링 이라고 하며 피해야 할 것입니다.
- 가중치가 1 (또는 가중치 없음)인 것은 정말 작고 간단한 것입니다. 9인 것은 GitLab의 큰 기본 부분을 다시 작성하는 것으로, 많은 어려운 문제를 해결해야 할 수 있습니다. GitLab의 텍스트를 변경하는 것은 아마 1일 것입니다, 새로운 Git Hook 추가는 아마 4 또는 5, 큰 기능은 7-9일 것입니다.
- 무언가가 매우 크다면, 여러 이슈나 청크로 분할되어야 할 수 있습니다. 부모 이슈의 가중치를 설정하고 자식 이슈에 가중치를 설정할 수는 없습니다.
회귀 이슈
매월 릴리스에는 해당 릴리스에서 손상된 기능 및 패치 릴리스에 포함해야 할 수정사항을 추적하는 CE 이슈 트래커에 해당하는 이슈가 있습니다(예시로 8.3 Regressions를 참조하세요).
이슈 설명에 명시된 대로, 의도된 워크플로우는 기능이 손상된 내용을 설명하는 이슈에 참조를 남기고, 해당 이슈를 수정하는 Merge Request이 사용 가능해질 때마다 해당 노트를 업데이트하는 것입니다.
다른 사용자의 노트를 업데이트할 권한이 없는 기여자라면, 해당 이슈와 Merge Request을 참조하는 새로운 노트를 게시하세요.
릴리스 매니저는 수정 사항이 주소화되는 대로 노트를 업데이트합니다.
후속 이슈에서의 기술 부채
새로운 기능을 개발하는 과정에서 기술 부채가 발견되는 것은 흔한 일입니다. “최소한의 변경” 정신에 따라 결정은 종종 후속 이슈로 연기됩니다. 그러나 이는 일반적으로 코드 리뷰를 통과하지 못할 부실한 품질의 코드를 Merge하는 변명이나 독립적으로 예약되지 않아도 되는 사소한 문제들을 무시하는 핑계로 사용될 수 없습니다. 오히려 이러한 문제들은 원본 Merge Request에서 해결하는 것이나 추적할 가치가 없는 문제로 해결하는 것이 더 나은 방안일 수 있습니다.
GitLab 코드베이스의 일정 및 변경 속도로 인해 사소한 기술 부채 문제의 비용은 빠르게 추적 가치를 초과할 수 있습니다. 이는 일반적으로 이러한 문제들을 원본 Merge Request에서 해결해야 하거나 후속 이슈를 생성하지 않아야 함을 의미합니다.
예를 들어, 파일 간에 복사되는 주석의 오타는 동일한 MR에서 수정할 가치는 있지만, 후속 이슈를 생성할 가치는 없을 수 있습니다. 여러 곳에서 사용되는 메소드의 이름을 조금 더 명확하게 만들기 위해 이름을 바꾸는 것은 수정할 가치가 있을 수 있지만, 동일한 MR에서 이루어지면 안 되며, 이러한 문제에 대한 별도의 관리 부담은 일반적으로 가치가 없을 수 있습니다. 이러한 문제들은 어쩌면 만약 생성한다면 ~P4 ~S4로 라벨이 지정될 것입니다.
보다 심각한 기술 부채는 개발 속도에 영향을 미칠 수 있습니다. 적기에 대응하지 않으면 코드베이스는 불필요하게 변경하기 어려워지고, 새로운 기능을 추가하기 어려워지며, 회귀가 증가할 수 있습니다.
이러한 유형의 기술 부채 발견은 심각하게 다뤄져야 하며, 후속 이슈에서의 결정이 적절한 경우에도 일반적으로 유지자는 원본 MR의 작성자 또는 해당 영역의 엔지니어 또는 제품 관리자로부터 예정에 대한 승인을 받아야 합니다. 이는 이슈에 적절한 우선순위/심각도 라벨 또는 구체적인 마일스톤 및 담당자 형태로 나타날 수 있습니다.
유지자는 항상 이러한 방식으로 미결된 토론이 해결되기 전에 합의해야 하며, 이는 이러한 이슈를 생성할 유지자가 될 것입니다. 제목과 설명은 일반적인 방식으로 작성된 것과 동일한 품질이어야 하며, 특히 이슈 제목은 Follow-up으로 시작하지 않아야 합니다! 이를 생성한 유지자는 후속 이슈에서의 작업이 시작될 때 어떤 식으로든 관여할 것으로 예상해야 합니다.
도움말