이슈 생성#

이슈를 제출하기 전에 이슈 트래커를 검색해 비슷한 항목이 있는지 확인합니다. 다른 사람이 이미 같은 버그나 기능 제안을 올렸을 수 있습니다. 기존 이슈를 찾았다면 이모지 반응으로 지지를 표시하고 토론에 의견을 덧붙입니다.

버그#

버그를 제출하는 방법은 다음과 같습니다.

• '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. 가능한 한 빨리 이슈에 가중치를 설정합니다
2. 설정된 가중치에 동의하지 않으면, 가중치에 대한 합의가 이루어질 때까지 다른 개발자와 논의합니다
3. 이슈 가중치는 이슈 복잡도를 나타내는 추상적인 측정값입니다. 이슈 가중치를 시간과 직접 연결하지 않습니다. 이는 앵커링이라고 하며, 피해야 할 현상입니다.
4. 가중치가 1이거나 가중치가 없는 항목은 아주 작고 단순한 작업입니다. 9인 항목은 GitLab의 크고 핵심적인 부분을 다시 작성하는 작업으로, 풀기 어려운 문제가 많이 따라올 수 있습니다. GitLab의 텍스트를 일부 바꾸는 작업은 대체로 1, 새 Git Hook 추가는 45, 큰 기능은 79 정도입니다.
5. 규모가 아주 크다면 여러 이슈나 단위로 나누는 편이 좋습니다. 상위 이슈에 가중치를 설정한 상태에서 하위 이슈에도 가중치를 설정할 수는 없습니다.

회귀 이슈#

월간 릴리스마다 CE 이슈 트래커에 대응 이슈가 있으며, 여기에서 해당 릴리스로 인해 깨진 기능과 패치 릴리스에 포함해야 할 수정 사항을 추적합니다 (예시는 8.3 Regressions 참고).

이슈 설명에 정리된 대로, 의도된 워크플로는 회귀를 설명하는 이슈를 참조하는 노트를 하나 올린 다음, 이를 해결하는 머지 리퀘스트가 나오면 그 노트를 머지 리퀘스트 참조로 갱신하는 것입니다.

다른 사용자의 노트를 수정할 권한이 없는 기여자라면, 이슈와 머지 리퀘스트를 모두 참조하는 새 노트를 올립니다.

릴리스 매니저는 수정 사항이 처리되는 대로 회귀 이슈의 노트를 갱신 합니다.

후속 이슈의 기술 부채#

새 기능을 개발하는 도중 기술 부채를 발견하는 일은 흔합니다. "최소 실행 가능한 변경"이라는 취지에 따라 해결을 후속 이슈로 미루는 경우가 많습니다. 다만 이를 근거로, 원래대로면 리뷰를 통과하지 못했을 낮은 품질의 코드를 머지하거나, 별도 일정을 잡을 가치가 없고 원래 머지 리퀘스트에서 해결하는 편이 낫거나 아예 추적할 필요가 없는 사소한 사항을 넘겨서는 안 됩니다.

일정 관리에 드는 부담과 GitLab 코드베이스의 변경 속도를 감안하면, 사소한 기술 부채 이슈의 비용이 추적의 가치를 금세 넘어설 수 있습니다. 이는 대체로 이러한 사항을 원래 머지 리퀘스트에서 해결하거나 후속 이슈를 아예 만들지 않아야 한다는 뜻입니다.

예를 들어 파일 사이에 복사되는 주석의 오타는 같은 MR에서 고칠 가치는 있지만 후속 이슈를 만들 가치는 없습니다. 여러 곳에서 사용되는 메서드의 이름을 바꿔 의도를 조금 더 명확히 하는 일은 고칠 가치가 있을 수 있지만, 같은 MR에서 할 일은 아니며 대체로 별도 이슈를 만드는 부담을 감수할 가치도 없습니다. 이런 이슈는 만들더라도 예외 없이 ~P4 ~S4 레이블이 붙게 됩니다.

더 심각한 기술 부채는 개발 속도에 영향을 줄 수 있습니다. 제때 처리하지 않으면 코드베이스를 바꾸기가 불필요하게 어려워지고, 새 기능을 추가하기 힘들어지며, 회귀가 늘어납니다.

이런 종류의 기술 부채를 발견하면 진지하게 다뤄야 하며, 후속 이슈에서 해결하는 것이 적절할 수도 있지만 maintainer는 원래 MR 작성자나 해당 영역의 엔지니어링 또는 프로덕트 매니저로부터 일정에 대한 약속을 받아 두는 것이 일반적입니다. 이는 이슈에 적절한 Priority / Severity 레이블을 붙이거나, 마일스톤과 담당자를 명시하는 형태가 될 수 있습니다.

미해결 논의를 이런 방식으로 마무리하려면 언제나 maintainer의 동의가 필요하며, 이슈를 만드는 사람도 maintainer 입니다. 제목과 설명은 일반적인 방식으로 만든 이슈와 같은 수준의 품질이어야 합니다. 특히 이슈 제목이 Follow-up으로 시작해서는 안 됩니다. 이슈를 만든 maintainer는 후속 이슈 작업이 시작될 때 어느 정도 관여하게 된다는 점도 염두에 둡니다.