이슈 워크플로우

이슈 생성

이슈를 제출하기 전에 이슈 트래커에서 검색 하여 유사한 항목을 찾으세요. 다른 사람이 이미 동일한 버그 또는 기능 제안을 했을 수 있습니다. 기존 이슈를 찾으면 이모지 반응으로 지원을 표현하고 토론에 노트를 추가하세요.

버그

버그를 제출하려면:

‘버그’ 이슈 템플릿을 사용하세요. 주석 내의 텍스트()는 포함해야 할 정보에 대해 도와줄 것입니다.
의심스러운 보안 취약점을 보고하려면 GitLab.com 웹사이트의 공개 공개 프로세스를 따르세요.

경고: 의심되는 보안 취약점에 대해 공개적으로 볼 수 있는 이슈를 생성하지 마세요.

기능 제안

기능 제안을 생성하려면, 이슈 트래커에서 **자세한 기능 제안 - (Feature Proposal - detailed) 이슈 템플릿을 사용하세요.

기능 제안을 추적하기 위해 ~"type::feature" 라벨을 사용합니다. 프로젝트의 멤버가 아닌 사용자는 UI를 통해 라벨을 추가할 수 없습니다. 대신, 리액티브 라벨 명령을 사용하세요.

기능 제안을 가능한 한 작고 간단하게 유지하세요. 복잡한 것은 편집하여 작고 간단하게 만들 수 있습니다.

사용자 인터페이스(UI) 변경 사항에 대해서는 디자인 및 UI 지침을 따르고 시각적 예제(스크린샷, 와이어프레임 또는 모킹)를 포함하세요. 해당 이슈에는 ~UX 라벨을 지정해야 합니다(리액티브 라벨 명령을 사용) 제품 설계 팀이 의견을 제공하고 안내를 할 수 있습니다.

작업할 이슈 찾기

GitLab에는 작업할 수 있는 75,000개 이상의 이슈가 있습니다. 라벨을 사용하여 이슈를 필터링하고 찾을 수 있습니다. 새로운 기여자는 quick win 라벨이 있는 이슈를 찾을 수 있습니다.

frontend와 backend 라벨도 이슈 목록을 정제하는 좋은 선택입니다.

이슈 명시/검증

많은 이슈들이 최근에 방문되거나 검증되지 않은 상태입니다. 이슈를 해결하기 전에 다음 단계를 수행하세요:

작성자에게 이슈가 여전히 관련이 있는지 묻습니다.
커뮤니티에 이슈가 여전히 관련이 있는지 묻습니다.
다음을 검증하려고 노력하세요:
- 이미 병합 요청이 생성되었는지(관련 병합 요청 섹션 참조). 때로는 이슈가 닫히거나 업데이트되지 않습니다.
- type::bug가 여전히 존재하는지(재생성으로 확인).
- type::feature가 이미 구현되지 않았는지(시도로 확인).

이슈 처리

문제를 해결하고 싶다는 표시를 남겨주세요. 작업을 하고 싶고 지정되었으면 (작성자 및/또는 @gitlab-org/coaches를 언급.

문제가 발생하거나 문제를 제대로 이해하지 못했다면 작성자 또는 커뮤니티에 도움을 요청하세요.

이슈 분류

우리의 이슈 분류 정책은 핸드북에 설명되어 있습니다. GitLab 팀이 이슈 분류에 도움을 환영합니다.

가장 중요한 것은 유효한 이슈가 개발 팀으로부터 피드백을 받는 것입니다. 따라서 우선순위는 해당 이슈에 도움이 필요한 개발자를 언급하는 것입니다. 해당 전문 분야에 관한 경험이 있는 사람을 선택하세요 GitLab 팀. 해당 전문 분야에 관한 사람이 언급되어 있지 않다면, 영향을 받는 파일에 대한 커밋 이력을 확인하여 누군가를 찾으세요.

우리는 분류 자동화도 있습니다. 핸드북을 참조하여 설명되어 있습니다.

이슈에 적용해야 할 라벨에 대한 정보는 라벨을 참조하세요.

이슈 가중치

이슈 가중치는 하나 이상의 이슈를 해결하는 데 필요한 작업량을 파악하는 데 도움이 됩니다. 이를 통해 작업을 더 정확하게 일정화할 수 있습니다.

어떤 이슈의 가중치를 설정하는 것을 권장합니다. 아래 가이드라인을 따르면 불필요한 오버헤드 없이 쉽게 관리할 수 있습니다.

가능한 빨리 모든 이슈에 대해 가중치를 설정하세요.
설정된 가중치에 동의하지 않는다면, 다른 개발자들과 논의하여 합의를 이끌어내세요.
이슈 가중치는 이슈의 복잡성에 대한 추상적인 측정입니다. 직접 시간과 관련 지어서는 안 됩니다. 이를 앵커링이라고 하며 피해야 하는 것입니다.
가중치가 1(또는 가중치가 없음)인 것은 실제로 매우 작고 간단합니다. 9인 것은 GitLab의 큰 기본 부분을 다시 작성하는 것이며, 이는 해결해야 할 어려운 문제가 많을 것입니다. GitLab의 일부 텍스트를 변경하는 것은 아마도 1, 새로운 Git Hook을 추가하는 것은 아마도 4 또는 5, 큰 기능은 7-9일 것입니다.
아주 큰 것인 경우, 여러 이슈나 청크로 나뉘어야 할 수 있습니다. 부모 이슈의 가중치를 설정하고 하위 이슈에 가중치를 설정할 수 없습니다.

회귀 이슈

매월 릴리스마다 해당 릴리스에 의해 깨진 기능과 포함해야 할 패치 릴리스에 대한 대응하는 CE 이슈 트래커에 대응하는 이슈가 있습니다 (8.3 Regressions를 참조하세요).

이슈 설명에 기술된 대로, 의도한 워크플로우는 이슈에 대한 참조 노트를 게시하고 이를 수정 가능한 해당 노트를 사용 가능해 질 때 해당 병합 요청에 대한 참조로 업데이트하는 것입니다.

다른 사용자의 노트를 업데이트할 필요 권한이 없는 기여자이고, 이슈와 병합 요청에 대한 참조를 포함한 새로운 노트를 게시하세요.

릴리스 관리자는 회귀 이슈에서 노트를 업데이트합니다는 것으로 해결될 때마다.

Follow-up 이슈에서의 기술 부채

새로운 기능을 개발하는 과정에서 기술 부채를 발견하는 것은 흔한 일입니다. “최소한의 변경으로 시작하기”를 지향하므로 결정은 종종 추후 이슈로 미루어집니다. 그러나 이것은 나쁜 품질의 코드를 병합하는 핑계로 사용되어서는 안 되며, 독립적으로 예약되지 않아도 되는 사소한 문제를 간과하는 핑계로 사용해서도 안 됩니다. 또한, 병합 요청을 통하지 못하는 품질의 코드를 무시해서도 안 됩니다! 이러한 문제는 처음 병합 요청을 통해 해결하거나 전혀 추적하지 않는 것이 가장 좋습니다.

GitLab 코드베이스에서의 예약과 변경 비율은 사소한 기술 부채 문제의 비용이 빠르게 증가하여 그 가치를 초과하게 만듭니다. 이는 일반적으로 이러한 문제를 처음 병합 요청에서 해결해야 하거나 추 후 이슈를 전혀 만들지 않아야 함을 의미합니다.

예를 들어, 파일 간에 복사되는 코멘트의 오타는 동일한 MR에서 수정할 가치가 있지만, 추 후 이슈를 만들 가치는 없습니다. 여러 곳에서 사용되는 메서드의 이름을 약간 더 명확하게 만들기 위해 이름을 변경하는 것은 수정할 가치가 있을 수 있지만, 이것은 동일한 MR에서 발생해서는 안 되며, 일반적으로 별도의 이슈를 생성하는 데 들이는 노력의 가치가 없습니다. 만약 이러한 문제를 만들어야 한다면, 일반적으로 이러한 문제들은 ~P4 ~S4로 레이블이 지정될 것입니다.

더 심각한 기술 부채는 개발 속도에 영향을 미칠 수 있습니다. 적시에 처리되지 않으면 코드베이스는 불필요하게 변경하기 어려워지며, 새로운 기능을 추가하기도 어려워지고, 회귀가 빈번해집니다.

이러한 종류의 기술 부채 발견은 심각하게 다뤄져야 하며, 추후 이슈에서 결정을 내릴 수 있어도 유지자는 원본 MR의 저자나 관련 영역의 엔지니어 또는 제품 매니저로부터 예약하는 공약을 일반적으로 받아야 합니다. 이는 이슈에 적절한 우선순위 / 심각도 레이블이나 명시적인 마일스톤과 담당자로 구체화될 수 있습니다.

유지자는 항상 동의해야 하며, 이 방식으로 논의가 해결되기 전에 이슈를 만드는 담당자가 될 것입니다. 제목과 설명은 보통의 방식으로 생성된 것과 동일한 품질이어야 하며 특히 이슈 제목은 반드시 Follow-up으로 시작해서는 안 됩니다! 이슈를 만드는 유지자는 또한 추 후 이슈에 대해 일정 상의 관여를 기대해야 합니다.