이슈 생성하기#

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

버그#

버그를 제출하려면:

• 'Bug' 이슈 템플릿을 사용하세요. 주석(<!-- ... -->) 안의 텍스트가 포함해야 할 정보를 안내합니다.

• 보안 취약점으로 의심되는 사항을 보고하려면 GitLab.com 웹사이트의 공개 절차를 따르세요.

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

기능 제안#

기능 제안을 만들려면 이슈 트래커에서 Feature Proposal - detailed 이슈 템플릿을 사용하여 이슈를 여세요.

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

기능 제안은 가능한 한 작고 단순하게 유지하세요. 복잡한 제안은 작고 단순하게 편집될 수 있습니다.

사용자 인터페이스(UI) 변경 사항의 경우, 디자인 및 UI 가이드라인을 따르고 시각적 예시(스크린샷, 와이어프레임, 또는 목업)를 포함하세요. 이러한 이슈에는 Product Design 팀이 의견과 가이드를 제공할 수 있도록 (반응형 라벨 명령어를 사용하여) ~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 참조).

이슈 설명에 outlined된 대로, 의도된 워크플로는 회귀를 설명하는 이슈에 대한 참조와 함께 하나의 메모를 게시하고, 수정 사항이 제공되면 해당 머지 리퀘스트에 대한 참조로 그 메모를 업데이트하는 것입니다.

다른 사용자의 메모를 업데이트하는 데 필요한 권한이 없는 기여자라면, 이슈와 머지 리퀘스트 모두에 대한 참조와 함께 새 메모를 게시하세요.

릴리스 매니저는 수정 사항이 처리됨에 따라 회귀 이슈의 메모를 업데이트합니다.

후속 이슈의 기술 부채#

새 기능 개발 중에 기술 부채를 발견하는 것은 흔한 일입니다. "최소 실행 가능한 변경"의 정신에 따라, 해결은 종종 후속 이슈로 미루어집니다. 그러나 이것은 리뷰를 통과하지 못할 수준의 저품질 코드를 머지하거나, 독립적으로 일정에 넣을 가치가 없고 원래 머지 리퀘스트에서 해결하는 것이 더 좋은 사소한 사항을 간과하는 핑계로 사용될 수 없습니다 - 아니면 아예 추적하지 않는 것이 나을 수도 있습니다!

일정 조율의 오버헤드와 GitLab 코드베이스의 변경 속도를 고려할 때, 사소한 기술 부채 이슈의 비용은 추적의 가치를 금세 초과할 수 있습니다. 이는 일반적으로 원래 머지 리퀘스트에서 해결하거나 - 후속 이슈를 전혀 생성하지 않아야 함을 의미합니다.

예를 들어, 파일 간에 복사되는 주석의 오타는 동일한 MR에서 수정할 가치가 있지만, 후속 이슈를 만들 가치는 없습니다. 의도를 조금 더 명확하게 하기 위해 많은 곳에서 사용되는 메서드 이름을 바꾸는 것은 수정할 가치가 있을 수 있지만, 동일한 MR에서 이루어져서는 안 되며, 일반적으로 자체 이슈를 가질 오버헤드의 가치가 없습니다. 이러한 이슈에는 생성하더라도 ~P4 ~S4 라벨이 불가피하게 붙을 것입니다.

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

이러한 종류의 기술 부채 발견은 심각하게 다루어야 하며, 후속 이슈로 해결하는 것이 적절할 수 있지만, 유지보수자는 일반적으로 원래 MR의 작성자 또는 관련 영역의 엔지니어링 또는 제품 관리자로부터 일정 수립 약속을 받아야 합니다. 이것은 이슈에 적절한 Priority / Severity 라벨의 형태나 명시적인 마일스톤 및 담당자의 형태로 이루어질 수 있습니다.

유지보수자는 미해결 토론이 이 방식으로 해결되기 전에 반드시 동의해야 하며, 이슈를 생성하는 사람이 될 것입니다. 제목과 설명은 일반적인 방법으로 생성된 것과 동일한 품질이어야 합니다 - 특히, 이슈 제목은 Follow-up으로 시작해서는 절대 안 됩니다! 이슈를 생성하는 유지보수자는 또한 후속 이슈에 대한 작업이 시작될 때 어떤 방식으로든 관여하게 될 것을 예상해야 합니다.