이슈 워크플로우

이슈 생성하기

이슈를 제출하기 전에, 이슈 추적기 검색하기

유사한 항목이 있는지 확인하세요. 다른 사람이 이미 동일한 버그나 기능 제안을 했을 수도 있습니다.

기존 이슈를 찾으면, 이모지 반응으로 지지를 표시하고 논의에 자신의 메모를 추가하세요.

버그

버그를 제출하려면:

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

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

기능 제안

기능 제안을 생성하려면, 기능 제안 - 상세 이슈 템플릿을 사용하여 이슈 추적기에서 이슈를 열어주세요.

기능 제안을 추적하기 위해, ~"type::feature" 레이블을 사용합니다.

프로젝트의 멤버가 아닌 사용자들은 UI를 통해 레이블을 추가할 수 없습니다.

대신, 반응형 레이블 명령어를 사용하세요.

기능 제안은 가능한 작고 단순하게 유지하세요. 복잡한 것은 작고 단순하게 만들기 위해 수정될 수 있습니다.

사용자 인터페이스(UI) 변경에 대해서는 디자인 및 UI 가이드라인을 따르고, 시각적 예시(스크린샷, 와이어프레임 또는 목업)을 포함하세요.

이런 이슈는 ~UX" 레이블이 부여되어야 하며, 제품 디자인 팀이 의견과 지침을 제공할 수 있도록 합니다.

작업할 이슈 찾기

GitLab에는 작업할 수 있는 75,000개 이상의 이슈가 있습니다.

레이블을 사용하여 적합한 이슈를 필터링하고 찾을 수 있습니다.

새로운 기여자는 quick win 레이블이 있는 이슈를 찾을 수 있습니다.

frontend 및 backend 레이블도 이슈 목록을 세분화하는 데 좋은 선택입니다.

이슈 명확히 하거나 검증하기

많은 이슈가 최근에 방문되거나 검증되지 않았습니다.

이슈를 해결하기 전에, 다음 단계를 따르세요:

저자에게 이슈가 여전히 유효한지 물어보세요.
커뮤니티에 이슈가 여전히 유효한지 물어보세요.
다음을 검증하려고 시도하세요:
- 병합 요청이 이미 생성되었는지(관련된 병합 요청 섹션 참조). 이슈가 닫히지 않았거나 업데이트되지 않은 경우가 있습니다.
- type::bug가 여전히 존재하는지(다시 재현하여).
- type::feature가 이미 구현되지 않았는지(시도하여).

이슈 작업하기

이슈를 작업하고 싶다는 것을 나타내는 메모를 남기고 할당받고 싶다고 알려주세요 (저자 및/또는 @gitlab-org/coaches를 언급하세요).

작업이 막히거나 이슈를 제대로 이해하지 못했다면 저자 또는 커뮤니티에 도움을 요청할 수 있습니다.

이슈 triaging

우리의 이슈 triage 정책은 우리의 핸드북에 설명되어 있습니다.

GitLab 팀이 이슈를 triage하는 데 도움을 주시면 매우 환영합니다.

가장 중요한 것은 유효한 이슈가 개발 팀으로부터 피드백을 받도록 하는 것입니다.

따라서 우선적으로 해당 이슈에 도움을 줄 수 있는 개발자를 언급하는 것이 중요합니다.

GitLab 팀에서 관련 경험이 있는 사람을 선택하세요.

해당 전문성을 가진 사람이 없다면, 영향을 받는 파일의 커밋 히스토리에서 누군가를 찾아보세요.

우리는 또한 우리의 핸드북에 설명된 triage 자동화가 있습니다.

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

이슈 무게

이슈 무게는 하나 이상의 이슈를 해결하는 데 필요한 작업량에 대한 아이디어를 제공합니다.

이로 인해 작업을 보다 정확하게 계획할 수 있게 됩니다.

어떤 이슈의 무게도 설정하는 것이 권장됩니다. 아래의 가이드라인을 따르면

이를 쉽게 관리할 수 있으며, 불필요한 부담이 없습니다.

가능한 한 빨리 모든 이슈에 대한 무게를 설정하세요.
설정된 무게에 동의하지 않는 경우, 다른 개발자와 논의하여 무게에 대한 합의에 도달하세요.
이슈 무게는 이슈의 복잡성을 추상적으로 측정한 것입니다. 이슈 무게를 시간에 직접 연관시키지 마세요.

이는 앵커링이라고 불리며, 피해야 할 것입니다.

무게가 1(또는 무게가 없는) 것은 정말 작고 간단합니다.

무게가 9인 것은 GitLab의 큰 기본 부분을 다시 작성하는 것으로, 많은 어려운 문제를 해결해야 할 수 있습니다.

GitLab에서 텍스트를 변경하는 것은 아마도 1일 것이고, 새로운 Git Hook을 추가하는 것은 4 또는 5일 수 있으며, 큰 기능은 7-9일 수 있습니다.

어떤 것이 매우 크다면 아마도 여러 이슈나 청크로 나누어져야 합니다.

부모 이슈의 무게를 설정할 수 없으며 자식 이슈에 무게를 설정할 수 있습니다.

리그레션 이슈

매월 릴리즈는 CE 이슈 트래커에서 해당 릴리즈로 인해 기능이 손상된 경우 및 패치 릴리즈에 포함될 필요가 있는 모든 수정을 추적하기 위한 해당 이슈를 가지고 있습니다(예시로 8.3 리그레션을 참조합니다).

이슈 설명에 요약된 바와 같이 의도된 워크플로우는 리그레션을 설명하는 이슈에 대한 참조가 포함된 하나의 노트를 게시한 다음,

해당 이슈를 수정하는 머지 요청에 대한 참조로 노트를 업데이트하는 것입니다.

필요한 권한이 없는 기여자는 다른 사용자의 노트를 업데이트할 수 없으며, 이슈와 머지 요청 모두를 참조한 새로운 노트를 게시하세요.

릴리즈 관리자는 노트를 업데이트하며 수정 사항이 처리될 때 따라 합니다.

후속 이슈에서의 기술적 부채

새로운 기능 개발 중에 기술적 부채를 발견하는 것은 흔한 일입니다.

“최소 기능적 변경(minimum viable change)”이라는 정신에서 해결책은 종종 후속 이슈로 미뤄집니다.

그러나 이것은 원래 검토를 통과하지 못할 질 낮은 코드를 병합하는 핑계로 사용되어서는 안 되며,

독립적으로 일정이 잡힐 필요가 없는 사소한 문제를 간과해서는 안 되며,

원래의 머지 요청에서 해결하는 것이 최선입니다 - 아니면 전혀 추적하지 않거나 말입니다!

일정 잡기와 GitLab 코드베이스의 변화 속도의 오버헤드는 사소한 기술적 부채 이슈의 비용이 추적할 가치보다 빨리 초과될 수 있음을 의미합니다.

이는 일반적으로 이러한 문제를 원래의 머지 요청에서 해결해야 하며,

아예 후속 이슈를 만들지 않아야 함을 의미합니다.

예를 들어, 파일 사이에 복사되고 있는 주석의 오타는 동일한 MR에서 수정할 가치가 있지만

후속 이슈를 만들 만큼의 가치가 없습니다.

여러 곳에서 사용되는 메서드의 이름을 약간 더 명확하게 만드는 것은 수정할 가치가 있을 수 있지만,

동일한 MR에서 이루어지지 않아야 하며, 적어도 그 자체로 문제를 만들 만큼의 오버헤드의 가치는 없습니다.

이러한 문제는 우리가 이를 생성한다면 반드시 ~P4 ~S4로 라벨이 붙을 것입니다.

보다 심각한 기술적 부채는 개발 속도에 영향을 줄 수 있습니다.

적시에 해결되지 않으면 코드베이스는 불필요하게 변경하기 어려워지고, 새로운 기능 추가가 어려워지며 리그레션이 발생하게 됩니다.

이런 종류의 기술적 부채 발견은 심각하게 다루어져야 하며,

후속 이슈에서의 해결이 적절할 수 있지만,

유지 보수자는 일반적으로 원래 MR의 저자나 해당 영역의 엔지니어링 또는 제품 관리자로부터 일정 약속을 받아야 합니다.

이는 적절한 우선 순위/심각도 라벨이나 명시적인 마일스톤과 담당자를 통해 이루어질 수 있습니다.

유지 보수자는 항상 Outstanding discussion이 이러한 방식으로 해결되기 전에 동의해야 하며,

문제를 생성하는 사람이 될 것입니다.

제목과 설명은 일반적인 방식으로 생성된 것과 동일한 품질이어야 합니다 - 특히,

이슈 제목은 결코 Follow-up으로 시작해서는 안됩니다!

생성하는 유지 보수자는 후속 이슈에서 작업이 시작될 때 어떤 방식으로든 관련될 것이라고 예상해야 합니다.