비동기 이슈 처리를 위해 마일스톤과 라벨을 사용합니다. 리드와 프로덕트 매니저가 마일스톤으로의 스케줄링 대부분을 담당하며, 라벨 지정은 모든 사람의 업무입니다. (일부 프로젝트에서는 라벨을 GitLab 팀원만 설정할 수 있으며 커뮤니티 기여자는 설정할 수 없습니다.)

대부분의 이슈는 해당하는 경우 다음 각 항목에 대해 최소 하나 이상의 라벨을 가집니다:

• 유형(Type). 예: ~"type::feature", ~"type::bug", 또는 ~"type::maintenance".

• 섹션(Section). 예: ~"section::dev" 또는 ~"section::ai".

• Stage. 예: ~"devops::plan" 또는 ~"devops::create".

• 그룹(Group). 예: ~"group::source code", ~"group::knowledge", 또는 ~"group::editor".

• 카테고리(Category). 예: ~"Category:Code Analytics", ~"Category:DevOps Reports", 또는 ~"Category:Templates".

• 기능(Feature). 예: ~wiki, ~ldap, ~api, ~issues, 또는 ~"merge requests".

• 기능 상태(Feature state): ~"Feature state::Experiment", ~"Feature state::Beta", 또는 ~"Feature state::GA"

• 부서(Department). 예: ~UX, ~Quality

• 팀(Team). 예: ~"Technical Writing", ~Delivery

• 전문화(Specialization): ~frontend, ~backend, ~documentation

• 릴리즈 범위(Release Scoping): ~Deliverable, ~Stretch, ~"Next Patch Release"

• 우선순위(Priority): ~"priority::1", ~"priority::2", ~"priority::3", ~"priority::4"

• 심각도(Severity): ~"severity::1", ~"severity::2", ~"severity::3", ~"severity::4"

이슈가 브레이킹 체인지로 간주될 수 있는 경우 ~"breaking change" 라벨을 추가하세요.

이슈가 애플리케이션 보안과 관련된 경우 ~security 라벨을 추가하세요.

모든 라벨, 의미 및 우선순위는 라벨 페이지에서 정의됩니다.

이러한 라벨이 없는 이슈를 발견하고 라벨을 설정할 권한이 있다면, 언제든지 유형, Stage, 그룹, 그리고 종종 카테고리/기능 라벨을 추가할 수 있습니다.

유형 라벨#

유형 라벨은 매우 중요합니다. 이슈가 어떤 종류인지를 정의합니다. 모든 이슈에는 하나의 유형 라벨만 있어야 합니다.

유형 및 하위 유형 라벨의 단일 진실 공급원(Single Source Of Truth, SSOT)은 핸드북에서 확인할 수 있습니다.

일부 유형 라벨에는 우선순위가 지정되어 있으며, 이에 따라 중요도에 따라 자동으로 상단에 표시됩니다.

유형 라벨은 항상 소문자이며, 파란색(카테고리 라벨용으로 이미 예약됨)을 제외한 어떤 색상도 사용할 수 있습니다.

라벨 페이지의 설명은 각 유형 라벨에 해당하는 항목을 설명합니다.

GitLab 핸드북은 버그가 무엇인지와 기능 요청이 무엇인지를 문서화합니다.

Stage 라벨#

Stage 라벨은 이슈가 속하는 Stage를 지정합니다.

명명 및 색상 규칙#

Stage 라벨은 devops::<stage_key> 명명 규칙을 따릅니다. <stage_key>는 https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/stages.yml의 Stage에 대한 단일 진실 공급원에 있는 Stage 키로, _는 공백으로 대체됩니다.

예를 들어, "Manage" Stage는 stages 아래의 키가 manage이므로 gitlab-org 그룹에서 ~"devops::manage" 라벨로 표시됩니다.

현재 Stage 라벨은 devops::를 라벨 목록에서 검색하여 찾을 수 있습니다.

이러한 라벨은 범위 지정 라벨이므로 상호 배타적입니다.

Stage 라벨은 방향 페이지를 자동으로 생성하는 데 사용됩니다.

그룹 라벨#

그룹 라벨은 이슈가 속하는 그룹을 지정합니다.

그룹 라벨을 추가하는 것을 강력히 권장합니다. 트리아지 자동화에서 올바른 Stage 라벨을 추론하는 데 사용되기 때문입니다.

명명 및 색상 규칙#

그룹 라벨은 group::<group_key> 명명 규칙을 따르며 색상은 #A8D695입니다. <group_key>는 https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/stages.yml의 그룹에 대한 단일 진실 공급원에 있는 그룹 키로, _는 공백으로 대체됩니다.

예를 들어, "Pipeline Execution" 그룹은 stages.manage.groups 아래의 키가 pipeline_execution이므로 gitlab-org 그룹에서 ~"group::pipeline execution" 라벨로 표시됩니다.

현재 그룹 라벨은 group::를 라벨 목록에서 검색하여 찾을 수 있습니다.

이러한 라벨은 범위 지정 라벨이므로 상호 배타적입니다.

그룹 목록은 Product Stages, Groups, and Categories 페이지에서 확인할 수 있습니다.

우리는 그룹이라는 용어를 사용하여 프로덕트 Stage에서 프로덕트 요구사항을 매핑합니다. 팀이 구성원들이 배정될 예정인 작업을 수집할 방법이 필요하므로, ~group:: 라벨을 이를 위해 사용합니다.

카테고리 라벨#

핸드북의 Product stages, groups, and categories 페이지에서:

카테고리는 예를 들어 Portfolio Management와 같이 다른 회사에서 독립적인 제품이 될 수 있는 고수준 기능들입니다.

카테고리 라벨을 추가하는 것을 강력히 권장합니다. 트리아지 자동화에서 올바른 그룹 및 Stage 라벨을 추론하는 데 사용되기 때문입니다.

특정 영역의 전문가라면, 작업할 이슈를 찾기가 더 쉬워집니다. 또한 해당 라벨을 구독하여 이슈에 전문 분야에 해당하는 카테고리 라벨이 지정될 때마다 이메일을 받을 수도 있습니다.

명명 및 색상 규칙#

카테고리 라벨은 Category: 명명 규칙을 따르며 색상은 #428BCA입니다. 은 https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/categories.yml의 카테고리에 대한 단일 진실 공급원에 있는 카테고리 이름입니다.

예를 들어, "DevOps Reports" 카테고리는 devops_reports.name 값이 "DevOps Reports"이므로 gitlab-org 그룹에서 ~"Category:DevOps Reports" 라벨로 표시됩니다.

카테고리 라벨이 이 명명 규칙을 따르지 않는 경우, https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/categories.yml에서 label 속성으로 지정해야 합니다.

기능 라벨#

핸드북의 Product stages, groups, and categories 페이지에서:

기능: 예를 들어 이슈 가중치와 같은 소규모의 독립적인 기능들입니다. 키워드로 담당 PM을 찾기 쉽도록 일부 일반적인 기능들은 괄호 안에 나열되어 있습니다.

카테고리 라벨이 적용되지 않는 경우 기능 라벨을 추가하는 것을 강력히 권장합니다. 트리아지 자동화에서 올바른 그룹 및 Stage 라벨을 추론하는 데 사용되기 때문입니다.

특정 영역의 전문가라면, 작업할 이슈를 찾기가 더 쉬워집니다. 또한 해당 라벨을 구독하여 이슈에 전문 분야에 해당하는 기능 라벨이 지정될 때마다 이메일을 받을 수도 있습니다.

기능 라벨의 예로는 ~wiki, ~ldap, ~api, ~issues, ~"merge requests"가 있습니다.

명명 및 색상 규칙#

기능 라벨은 모두 소문자입니다.

기능 상태 라벨#

기능이 릴리즈될 때 상태에 맞는 기능 상태 라벨을 추가하세요. 라벨은 작업 항목 제목과 일치해야 합니다. 제목의 기능 상태가 이미 목표 상태를 전달하지만, 필터링을 위해 라벨이 필요합니다.

예를 들어, 베타로 릴리즈하려는 기능에 대한 에픽이 있다고 가정합니다. 에픽의 제목은 "Your Feature (Beta)"입니다. 이에 맞게 ~"Feature state::Beta" 라벨을 추가하세요.

이미 일반적으로 사용 가능(GA 이후)으로 릴리즈된 기능에 대한 작업 항목은 기능 상태 라벨이 필요하지 않습니다.

워크플로 라벨#

이슈는 현재 이슈 상태를 지정하기 위해 다음 워크플로 라벨을 사용합니다:

• ~"workflow::awaiting security release"

• ~"workflow::blocked"

• ~"workflow::complete"

• ~"workflow::design"

• ~"workflow::feature-flagged"

• ~"workflow::in dev"

• ~"workflow::in review"

• ~"workflow::planning breakdown"

• ~"workflow::problem validation"

• ~"workflow::production"

• ~"workflow::ready for design"

• ~"workflow::ready for development"

• ~"workflow::refinement"

• ~"workflow::scheduling"

• ~"workflow::solution validation"

• ~"workflow::start"

• ~"workflow::validation backlog"

• ~"workflow::verification"

패싯 라벨#

생성된 이슈에 대한 추가 정보나 컨텍스트를 추적하기 위해, 개발자는 패싯 라벨을 추가할 수 있습니다. 패싯 라벨은 이슈 우선순위 지정이나 측정(예: 종료까지 소요 시간)에도 사용되는 경우가 있습니다. 패싯 라벨의 예로는 고객의 관심을 나타내는 ~"customer" 라벨이 있습니다.

부서 라벨#

현재 부서 라벨은 다음과 같습니다:

• ~"UX"

• ~"Quality"

• ~"infrastructure"

• ~"security"

팀 라벨#

중요: 대부분의 과거 팀 라벨(예: Manage 또는 Plan)은 이제 그룹 라벨 및 Stage 라벨을 위해 더 이상 사용되지 않습니다.

팀 라벨은 이 이슈를 담당하는 팀을 지정합니다. 팀 라벨을 지정하면 이슈가 적절한 담당자의 주목을 받을 수 있습니다.

현재 팀 라벨은 다음과 같습니다:

• ~"Delivery"

• ~"Technical Writing"

• ~"Engineering Productivity"

• ~"Contributor Success"

명명 및 색상 규칙#

팀 라벨은 항상 대문자로 시작하므로 이슈의 첫 번째 라벨로 표시됩니다.

전문화 라벨#

이 라벨들은 작업 단위에서의 전문화를 좁혀줍니다.

• ~"frontend"

• ~"backend"

• ~"documentation"

릴리즈 범위 라벨#

릴리즈 범위 라벨은 릴리즈에 대한 작업 기대치를 명확하게 전달하는 데 도움이 됩니다. 릴리즈 범위 라벨에는 세 가지 수준이 있습니다:

• ~"Deliverable": 현재 마일스톤에서 제공될 것으로 예상되는 이슈입니다.

• ~"Stretch": 현재 마일스톤에서 제공하기 위한 스트레치 목표인 이슈입니다. 이 이슈들이 현재 릴리즈에서 완료되지 않으면 다음 릴리즈에서 강력하게 고려됩니다.

• ~"Next Patch Release": 다음 패치 릴리즈에 포함할 이슈입니다. 이것을 먼저 작업하고 패치 릴리즈 런북을 따라 현재 버전에 버그 수정을 백포트하세요.

현재 마일스톤에 예정된 각 이슈는 ~"Deliverable" 또는 ~"Stretch" 라벨을 붙여야 합니다. 이전 마일스톤에 대한 열린 이슈는 ~"Next Patch Release" 라벨을 붙이거나 다른 마일스톤으로 재스케줄링해야 합니다.

우선순위 라벨#

다음 우선순위 라벨이 있습니다:

• ~"priority::1"

• ~"priority::2"

• ~"priority::3"

• ~"priority::4"

사용 방법은 핸드북의 이슈 트리아지 우선순위 라벨 섹션을 참조하세요.

심각도 라벨#

다음 심각도 라벨이 있습니다:

• ~"severity::1"

• ~"severity::2"

• ~"severity::3"

• ~"severity::4"

사용 방법은 핸드북의 이슈 트리아지 심각도 라벨 섹션을 참조하세요.

커뮤니티 기여자를 위한 라벨#

GitLab 사용자에게 명확한 해결책과 논란 없는 이점을 가진 이슈들이 많이 있습니다. 그러나 GitLab이 현재 로드맵에서 이러한 모든 제안을 수용할 용량이 없을 수 있습니다. 이러한 이슈들은 ~"Seeking community contributions" 라벨이 지정되어 있으며, 이를 해결하기 위한 머지 리퀘스트를 환영합니다.

커뮤니티 기여자는 원하는 이슈에 대해 머지 리퀘스트를 제출할 수 있지만, ~"Seeking community contributions" 라벨은 특별한 의미를 가집니다. 이는 다음과 같은 변경사항을 가리킵니다:

• 이미 합의된 것,

• 잘 정의된 것,

• 메인테이너에게 수락될 가능성이 높은 것.

기여자가 ~"Seeking community contributions" 이슈를 선택한 후 해당 머지 리퀘스트가 우리의 비전에 맞지 않거나 다른 방식으로 해결하고 싶다는 이유로 닫히는 상황을 방지하고자 합니다.

위에 설명된 기준에 맞는 이슈에 ~"Seeking community contributions" 라벨을 수동으로 추가합니다. 이 라벨은 인간의 평가가 필요하므로 자동으로 추가하지 않습니다.

오픈 소스 프로젝트에 기여한 적이 없는 사람들에게는 가중치가 1이거나 ~"quick win" 라벨이 붙은 ~"Seeking community contributions" 라벨의 이슈를 찾아보기를 권장합니다. 더 경험 많은 기여자는 그 중 어느 것이든 도전해 보시기를 환영합니다.

가중치가 2 이상이고 명확한 범위를 가진 더 복잡한 기능의 경우, ~"Community Challenge" 라벨이 있는 이슈를 살펴보는 것을 권장합니다. ~"Community Challenge" 이슈에 대한 MR이 병합되면, 커스텀 GitLab 굿즈를 받을 기회도 얻을 수 있습니다.

이슈를 작업하기로 결정했다면, 가능한 한 빨리 적절한 프로덕트 매니저를 @-멘션하세요. 프로덕트 매니저는 범위, 디자인 및 기술적 고려사항을 추가로 논의하기 위해 적절한 GitLab 팀원을 참여시킬 것입니다. 이를 통해 기여가 GitLab 제품과 일치하고 main에 병합되는 데 있어 재작업과 지연을 최소화할 수 있습니다.

이슈에 ~"Seeking community contributions" 라벨을 적용하는 GitLab 팀원은 위에 설명한 대로 잠재적인 커뮤니티 기여자가 @-멘션할 수 있도록 담당 프로덕트 매니저와 함께 이슈 설명을 업데이트해야 합니다.

청지기 라벨#

GitLab의 오픈 소스 청지기(stewardship)와 관련된 이슈에는 ~"stewardship" 라벨이 있습니다.

이 라벨은 GitLab의 청지기가 논의 주제인 이슈에 사용됩니다. 예를 들어 GitLab Inc.가 GitLab EE의 기능을 GitLab CE에 추가할 계획이라면, 관련 이슈에 ~"stewardship" 라벨을 붙입니다.

최근의 예로는 GitLab CE에 시간 추적 API를 도입하는 이슈가 있었습니다.

기술 부채 및 Deferred UX#

GitLab 코드베이스에서 개선될 수 있는 사항을 추적하기 위해 GitLab 이슈 트래커에서 ~"technical debt" 라벨을 사용합니다. MVC에서 벗어나 사용자 경험을 해치는 방식으로 선택한 경우 ~"Deferred UX" 라벨을 사용합니다.

이 라벨들은 개선될 수 있는 것들, 취해진 지름길, 추가 주의가 필요한 기능, 그리고 높은 개발 속도로 인해 뒤처진 모든 것들을 설명하는 이슈에 추가해야 합니다. 예를 들어, 리팩토링이 필요한 코드는 ~"technical debt" 라벨을 사용하고, 디자인 시스템 가이드라인에 맞게 출시되지 않은 것은 ~"Deferred UX" 라벨을 사용합니다.

누구나 이슈를 생성할 수 있지만, 직접 권한이 없는 경우 특정 라벨을 추가하도록 요청해야 할 수 있습니다. 추가 라벨을 이러한 라벨과 결합하여 릴리즈에 대한 개선 스케줄을 더 쉽게 만들 수 있습니다.

이 라벨로 태그된 이슈는 GitLab에 도입될 새 기능을 설명하는 이슈와 동일한 우선순위를 가지며, 적절한 담당자가 릴리즈에 스케줄링해야 합니다.

~"technical debt" 이슈나 ~"Deferred UX" 이슈와 연관된 머지 리퀘스트를 이슈 설명에 반드시 언급하세요.