이슈 워크플로우

이슈 생성

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

버그

버그를 제보하려면:

caution
의심스러운 보안 취약점에 대해 공개적으로 확인 가능한 이슈를 만들지 마세요.

기능 제안

기능 제안을 생성하려면 이슈 트래커에서 자세한 기능 제안 이슈 템플릿을 사용하세요.

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

기능 제안을 가능한 작고 간단하게 유지하다 보면 복잡한 것들은 편집되어 작고 간단하게 만들기도 합니다.

사용자 인터페이스(UI) 변경 사항에 대해서는 디자인 및 UI 가이드라인을 따르고 시각적인 예제(스크린샷, 와이어프레임 또는 모델)를 포함하세요. 해당 이슈에는 ~UX" 라벨을 붙여서(Product Design 팀의 의견과 안내를 얻기 위해 반응형 라벨 명령을 사용합니다.

작업할 이슈 찾기

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

frontend와 backend 라벨도 이슈 디렉터리을 정리하는 데 좋은 선택입니다.

이슈 명확화/유효성 검사

많은 이슈가 최근에 방문되거나 유효성을 검사하지 않았습니다. 이슈를 해결하기 전에 다음 단계를 수행하세요:

  • 이슈 작성자에게 해당 이슈가 여전히 관련이 있는지 물어봅니다.
  • 커뮤니티에게 해당 이슈가 여전히 관련이 있는지 물어봅니다.
  • 다음을 유효성을 검사해보세요:
    • 관련된 Merge Request이 이미 생성되었는지(관련 Merge Request 섹션 참조). 때로는 이슈가 닫히지 않거나 업데이트되지 않습니다.
    • type::bug가 여전히 존재하는지(재생성함으로써).
    • type::feature가 이미 구현되지 않았는지(시도함으로써).

이슈 처리

이슈에 대해 작업하고 해당 작업을 맡길 의사를 나타내는 노트를 남기고(작성자 및/또는 @gitlab-org/coaches를 언급) 해당 작업을 맡길 의사를 나타내는 노트를 남깁니다.

문제에 막혔거나 문제를 제대로 이해하지 못했다면 작성자나 커뮤니티의 도움을 요청할 수 있습니다.

이슈 트라이징

저희의 이슈 트라이지 정책은 핸드북에 설명되어 있습니다. GitLab 팀이 이슈 트라이지에 도움을 주는 것은 매우 환영받는 일입니다.

가장 중요한 것은 유효한 이슈가 개발 팀으로부터 피드백을 받도록 하는 것입니다. 따라서 이슈를 해결할 수 있는 개발자들을 언급하는 것이 우선이며 해당 분야의 경험을 가진 사람을 선택하세요. 그 분야에 해당하는 GitLab 팀에서 언급된 사람이 없다면 영향을 받는 파일의 커밋 기록을 확인하여 적합한 사람을 찾으세요.

또한 저희는 핸드북에 설명된 트라이지 자동화를 가지고 있습니다.

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

이슈 가중치

이슈 가중치를 설정해 두면 하나 또는 여러 개의 이슈를 해결하는 데 필요한 작업량을 파악할 수 있습니다. 이를 통해 작업을 더 정확하게 예약할 수 있습니다.

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

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

회귀 이슈

매월 릴리스에는 해당 릴리스로 일어난 기능의 문제와 패치 릴리스에 포함할 수정 사항을 추적하는 CE 이슈 트래커에 해당하는 이슈가 있습니다(예: 8.3 Regressions).

이슈 설명에 명시된 대로 의도된 워크플로우는 회귀를 설명하는 이슈에 참조를 포함한 메모를 게시하고 해당 수정 내용이 나타날 때 해당 메모를 업데이트하는 것입니다.

권한이 없는 기여자인 경우 사용자의 메모를 업데이트할 권한이 없다면 이슈와 해당 Merge Request에 대한 참조를 포함한 새로운 메모를 게시하세요.

릴리스 관리자는 회귀 이슈를 업데이트하며 수정이 주어질 때마다 이를 반영합니다.

후속 이슈의 기술적 부채

새 기능 개발 중에 기술적 부채를 발견하는 것은 일반적입니다. “최소한의 변경만”이라는 정신으로 인해 해결이 종종 후속 이슈로 연기됩니다. 그러나 이로 인해 검토를 통과하지 못할 부족한 품질의 코드를 Merge하는 구실로 사용해서는 안 되며, 독립적으로 일정되지 않아도 되는 사소한 문제를 놓칠 필요가 없습니다.

일정 및 GitLab 코드베이스의 변경 속도의 오버헤드로 인해 사소한 기술적 부채 문제의 비용이 빨리 증가할 수 있습니다. 이는 일반적으로 이를 해결하기 위해 원본 Merge Request에서 해결해야 합니다. - 또는 후속 이슈를 만들지 않는 것이 더 좋을 수 있습니다.

예를 들어, 파일 간에 복사되는 주석 오타는 동일한 Merge Request에서 수정하는 것은 가치가 있지만 새로운 후속 이슈를 만드는 가치는 없습니다. 여러 곳에서 사용되는 메서드의 이름을 약간 더 명확하게 하기 위해 이름을 바꾸는 것은 수정할 가치가 있지만 동일한 Merge Request에서 수행해서는 안 되며 일반적으로 자체 문제가 생성될 가치가 없을 정도의 오버헤드가 되지는 않습니다. 이러한 이슈들은 라벨 ~P4 ~S4를 붙입니다.

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

이러한 종류의 기술적 부채 발견은 심각하게 다뤄지어야 하며, 후속 이슈에서 해결하는 것이 적절한 경우에는 일반적으로 관리자는 원본 MR의 저자 또는 해당 영역의 엔지니어링 또는 제품 매니저로부터 일정 확인을 받아야 합니다. 이는 이슈에 적절한 Priority/Severity 라벨을 부여하거나 명시적으로 마일스톤과 담당자를 지정하는 형태로 진행할 수 있습니다.

저희가 결정한 방식으로 논의를 최종 해결하기 전에 유지자는 언제나 동의해야 하며, 이을 만들어야 할 것입니다. 제목과 설명은 일반적으로 문제가 생성되었던 평소대로 하여야 합니다. 이를 Follow-up으로 시작하면 안됩니다! 이를 해결할 때 작성자는 일반적으로 후속 이슈에 대한 작업이 시작될 때 어느 정도 관여할 것으로 예상됩니다.