이슈 작업 흐름

이슈 생성

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

버그

버그를 제출하려면:

경고: 의심되는 보안 취약점에 대해 공개적으로 볼 수 있는 이슈를 만들지 마십시오.

기능 제안

기능 제안을 작성하려면, 이슈 트래커에서 상세 기능 제안 이슈 템플릿을 엽니다.

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

기능 제안을 가능한 작고 간단하게 유지하고, 복잡한 경우 수정하여 간단하게 만드세요.

사용자 인터페이스(UI) 변경에 대해 우리의 디자인 및 UI 지침을 준수하고 시각적 예제(스크린샷, 와이어프레임 또는 모형)를 추가하세요. 이러한 문제는 ~UX" 라벨을 설정하여(Product Design 팀이 의견과 지침을 제공할 수 있도록) 처리합니다.

작업할 이슈 찾기

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

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

이슈 명확화/유효성 검증

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

  • 이슈 작성자에게 해당 이슈가 여전히 관련이 있는지 물어보세요.
  • 커뮤니티에게 해당 이슈가 여전히 관련이 있는지 물어보세요.
  • 다음을 유효성을 검증하려고하세요:
    • 하나 이상의 병합 요청이 이미 생성되었는지(관련 병합 요청 섹션 참조). 때로는 이슈가 닫히거나 업데이트되지 않습니다.
    • type::bug가 여전히 존재하는지(다시 만들어 확인).
    • type::feature가 이미 구현되지 않았는지(시도하여 확인).

이슈 작업

작업을 수행하고 할당받기를 희망하면 이슈에 작업할 의사를 나타내는 노트를 남기고, (작성자 및/또는 @gitlab-org/coaches를 언급하세요).

문제가 생긴 경우 또는 문제에 대해 올바르게 이해하지 못한 경우 작성자나 커뮤니티에 도움을 요청할 수 있습니다.

이슈 트리지

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

가장 중요한 것은 유효한 이슈가 개발 팀으로부터 피드백을 받는 것입니다. 그러므로 우선순위는 해당 이슈에 도움을 줄 수 있는 개발자들을 언급하는 것입니다. 그래서 중요한 것은 이 문제를 해결할 수 있는 누군가를 선택하는 것입니다. 해당 전문지식을 가진 사람이 언급되지 않은 경우 영향을 받는 파일의 커밋 기록을 확인하여 찾아보세요.

우리는 또한 핸드북에서 설명하는 트리지 자동화도 사용하고 있습니다(참조).

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

이슈 가중치

이슈의 가중치는 하나 이상의 이슈를 해결하는 데 필요한 작업량을 파악할 수 있도록 합니다. 이를 통해 작업을 보다 정확하게 예약할 수 있게 됩니다.

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

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

회귀 이슈

매월 릴리스마다 해당 릴리스에 의해 손상된 기능을 추적하고 패치 릴리스에 포함해야 할 수정 사항을 추적하는 CE 이슈 트래커에서 해당 문제에 대한 대응 사례가 있습니다(8.3 Regressions를 참조).

이슈 설명에 설명 된대로 의도된 워크플로우는 회귀를 설명하는 이슈에 노트를 하나 올리고, 나중에 사용 가능해지면 그것을 수정하는 머지 리퀘스트에 대한 참조를 노트에 업데이트하는 것입니다.

권한이 없는 기여자인 경우에는 다른 사용자의 노트를 업데이트 할 수 있는 권한이 없으므로 새로운 노트를 게시하여 해당 이슈와 머지 리퀘스트에 대한 참조를 남겨야 합니다.

릴리스 매니저는 수정 사항이 처리 될 때 회귀 이슈의 노트를 업데이트할 것.

Follow-up 이슈의 기술적 부채

새로운 기능을 개발하는 동안 기술적 부채를 발견하는 것은 흔한 일입니다. “최소한의 변경으로”라는 정신에서 해결은 종종 후속 이슈로 연기됩니다. 그러나 이는 검토를 통과하지 못할 경우에 합치는 허점이나, 독립적으로 예정되지 않을 사소한 문제를 간과하는 변명으로 사용될 수 없습니다. 이는 일반적으로 처음의 머지 리퀘스트에서 해결하거나 아예 추적하지 않는 것이 더 나은 해결책일 수 있습니다!

GitLab 코드베이스의 예약 및 변경 속도에 따라 사소한 기술적 부채 문제의 비용이 빠르게 증가할 수 있습니다. 이는 일반적으로 이러한 문제를 처음의 머지 리퀘스트에서 해결해야 하거나 후속 이슈를 전혀 작성하지 않아야 함을 의미합니다.

예를 들어, 파일 간 복사되는 주석의 오타는 같은 머지 리퀘스트에서 수정할 가치가 있지만, 후속 이슈를 작성할 가치는 없습니다. 사용되는 곳이 많은 메서드의 이름을 약간 더 명확하게 만들기 위해 이름을 바꾸는 것은 고치는게 가치가 있을 수 있지만, 같은 머지 리퀘스트에서 일어나서는 안되며, 일반적으로 별도의 이슈가 발생할만한 가치가 없습니다. 이러한 문제들은 대부분 ~P4 ~S4로 레이블이 지정될 것입니다.

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

이러한 종류의 기술적 부채 발견은 심각하게 다뤄져야 하며, 후속 이슈에서의 해결이 적절할 수 있지만, 유지자는 일반적으로 초기 MR의 저자나 관련 영역의 엔지니어 또는 프로덕트 매니저로부터 일정에 대한 약속을 얻어야 합니다. 이는 이슈에 적절한 우선 순위/심각도 레이블 또는 명시적인 마일스톤 및 담당자의 형태로 진행될 수 있습니다.

해결되지 않은 토론 전에는 유지자가 항상 동의해야하며, 그 사람이 이슈를 만들어야 합니다. 제목과 설명은 일반적인 방식대로 품질이어야합니다 – 특히 이슈 제목은 Follow-up로 시작해서는 안됩니다! 이슈를 만드는 유지자는 후속 이슈의 작업이 시작될 때 일정정도 관여할 것으로 예상해야 합니다.