레이블

비동기 이슈 처리를 위해 마일스톤 및 레이블을 사용합니다. 리더 및 제품 관리자들이 대부분 마일스톤으로 일정을 관리합니다. 레이블링은 모두의 작업입니다. (일부 프로젝트의 경우, 레이블은 GitLab 팀 멤버만 설정할 수 있으며 커뮤니티 기여자는 설정할 수 없습니다).

대부분의 이슈에는 다음 중 하나 이상의 레이블이 있을 것입니다:

  • 유형. 예: ~"type::feature", ~"type::bug", 또는 ~"type::maintenance".
  • 단계. 예: ~"devops::plan" 또는 ~"devops::create".
  • 그룹. 예: ~"group::source code", ~"group::knowledge", 또는 ~"group::editor".
  • 카테고리. 예: ~"Category:Code Analytics", ~"Category:DevOps Reports", 또는 ~"Category:Templates".
  • 피처. 예: ~wiki, ~ldap, ~api, ~issues, 또는 ~"merge requests".
  • 부서: ~UX, ~Quality
  • 팀: ~"Technical Writing", ~Delivery
  • 전문화: ~frontend, ~backend, ~documentation
  • 릴리스 범위: ~Deliverable, ~Stretch, ~"Next Patch Release"
  • 우선 순위: ~"priority::1", ~"priority::2", ~"priority::3", ~"priority::4"
  • 심각도: ~"severity::1", ~"severity::2", ~"severity::3", ~"severity::4"

이슈가 중요 변경 사항으로 간주될 수 있다면 ~"breaking change" 레이블을 추가하세요.

이슈가 응용 프로그램 보안과 관련이 있다면 ~security 레이블을 추가하세요.

모든 레이블, 그 의미 및 우선 순위는 레이블 페이지에 정의되어 있습니다.

위의 항목 중에서 어느 하나에 해당되지 않는 문제가 발견되면 레이블을 설정할 수 있는 경우, 항상 유형, 단계, 그룹, 그리고 종종 카테고리/피처 레이블을 추가할 수 있습니다.

유형 레이블

유형 레이블은 매우 중요합니다. 이슈의 종류를 정의합니다. 각 이슈는 하나의 유형 레이블만 가져야 합니다.

유형 및 하위 유형 레이블의 SSOT(단일 권한 소유)은 핸드북에서 이용 가능합니다.

일부 유형 레이블에는 우선 순위가 할당되어 있어 중요도에 따라 자동으로 상위에 표시됩니다.

유형 레이블은 항상 소문자여야 하며, 파란색 이외의 색상을 가질 수 있습니다(파란색은 이미 카테고리 레이블에 예약되어 있음).

레이블 페이지의 설명에는 각 유형 레이블에 속하는 것이 설명되어 있습니다.

GitLab 핸드북에서 버그인지 여부와 기능 요청인지 여부를 문서화하고 있습니다.

단계 레이블

단계 레이블은 이슈가 속한 단계를 지정합니다.

명명 및 색상 규칙

단계 레이블은 devops::<stage_key> 명명 규칙을 준수합니다. <stage_key>은 단계 키이며 단계에 대한 단일 진실의 위치로부터 가져온 것이며 https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/stages.yml에 _를 공백으로 대체한 것입니다.

예를 들어 “Manage” 단계는 gitlab-org 그룹의 ~"devops::manage" 레이블로 표시됩니다. 왜냐하면 stages 아래에 키가 manage로 나와 있기 때문입니다.

현재 단계 레이블은 레이블 디렉터리에서 devops::를 검색함으로 찾을 수 있습니다.

이 레이블은 범위가 지정된 레이블이며 상호 배타적입니다.

단계 레이블은 방향 페이지를 자동으로 생성하는 데 사용됩니다.

그룹 레이블

그룹 레이블은 이슈가 속한 그룹을 지정합니다.

그룹 레이블을 추가하는 것이 매우 권장됩니다. 우리의 triage 자동화에서 사용함으로써 올바른 단계 레이블을 추론합니다.

명명 및 색상 규칙

그룹 레이블은 group::<group_key> 명명 규칙을 준수하며 그 색상은 #A8D695입니다. <group_key>은 그룹 키이며 그룹에 대한 단일 진실의 위치에서 가져온 것이며 https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/stages.yml에 _를 공백으로 대체한 것입니다.

예를 들어 “Pipeline Execution” 그룹은 gitlab-org 그룹의 ~"group::pipeline execution" 레이블로 표시됩니다. 왜냐하면 stages.manage.groups 아래에 키가 pipeline_execution로 나와 있기 때문입니다.

현재 그룹 레이블은 레이블 디렉터리에서 group::를 검색함으로 찾을 수 있습니다.

이 레이블은 범위가 지정된 레이블이며 상호 배타적입니다.

제품 단계, 그룹 및 범주 페이지에서 디렉터리화된 그룹을 찾을 수 있습니다.

그룹은 제품 요구 사항을 매핑하기 위해 사용합니다. 팀이 멤버들이 할당하도록 계획 중인 작업을 수집하는 방법이 필요하기 때문에 ~group:: 레이블을 사용합니다.

카테고리 레이블

핸드북의 제품 단계, 그룹 및 범주 페이지에서:

범주는 다른 회사에서 독립적인 제품일 수 있는 고수준의 기능입니다. 예를 들어 ‘포트폴리오 관리’와 같은 것입니다.

카테고리 레이블을 추가하는 것이 매우 권장됩니다. 우리 triage 자동화에서 사용함으로써 올바른 그룹 및 단계 레이블을 추론합니다.

특정 영역의 전문가가 되어 있으면 할 일을 찾기 쉬워집니다. 해당 레이블을 구독하여 전문 기술에 해당하는 카테고리 레이블이 지정된 모든 이슈에 대해 이메일을 수신할 수도 있습니다.

명명 및 색상 규칙

카테고리 레이블은 Category:<Category Name> 명명 규칙을 준수하며 그 색상은 #428BCA입니다. <Category Name>은 카테고리 이름이며 카테고리는 https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/categories.yml에 있는 단일 진실의 위치에서 가져온 것이며 devops_reports.name 값이 “DevOps Reports”로 나와 있기 때문에 “DevOps Reports” 카테고리는 gitlab-org 그룹의 ~"Category:DevOps Reports" 레이블로 표시됩니다.

만약 카테고리의 레이블이 이 명명 규칙을 준수하지 않는다면, https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/categories.yml의 label 속성으로 지정해야 합니다.

기능 라벨

핸드북의 제품 단계, 그룹 및 범주 페이지에서:

기능: 예를 들어 이슈 가중치와 같은 작고 독립적인 기능. 몇 가지 일반적인 기능은 적절한 PM을 키워드로 찾을 수 있도록 괄호 안에 나열되어 있습니다.

카테고리 라벨이 적용되지 않는 경우 기능 라벨을 추가하는 것이 매우 권장됩니다. 이는 우리의 트리아지 자동화에 의해 사용되어 올바른 그룹 및 단계 라벨을 추론하는 데 사용됩니다.

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

기능 라벨의 예는 ~wiki, ~ldap, ~api, ~issues, 그리고 ~"merge requests"입니다.

명명 및 색상 규칙

기능 라벨은 모두 소문자로 표시됩니다.

Workflow 라벨

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

  • ~"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"

관점 라벨

개발자는 작성된 이슈에 대한 추가 정보나 컨텍스트를 추적하기 위해 _facet 라벨_을 추가할 수 있습니다. facet 라벨은 때로는 이슈 우선 순위 지정이나 (예: 닫히는 데 걸리는 시간과 같은) 메트릭을 위해 사용되기도 합니다. 참고로 ~"customer" 라벨은 고객 관심을 나타냅니다.

부서 라벨

현재 부서 라벨은:

  • ~"UX"
  • ~"Quality"
  • ~"infrastructure"
  • ~"security"

팀 라벨

중요: Manage 또는 Plan과 같은 대부분의 팀 라벨은 그룹 라벨 및 단계 라벨로 인해 더 이상 사용되지 않습니다.

팀 라벨은 해당 이슈를 책임지는 팀을 지정합니다. 팀 라벨을 지정하면 해당 이슈가 적절한 사람들의 관심을 끌도록 보장됩니다.

현재 팀 라벨은:

  • ~"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에는 사용자에게 명백한 이점을 제공하는 명확한 해결책이 있는 많은 이슈가 있습니다. 그러나 현재 로드맵에는 모든 제안에 대한 여유 공간이 없을 수 있습니다. 이러한 이슈는 ~"Seeking community contributions" 라벨이 지정되어 있습니다. 왜냐하면 우리는 이러한 이슈를 해결하기 위한 MR을 환영하기 때문입니다.

커뮤니티 기여자는 원하는 경우 어떤 이슈에 대해서든 MR을 제출할 수 있지만, ~"Seeking community contributions" 라벨에는 특별한 의미가 있습니다. 이는 이미 합의된 사항이며, 명확히 정의되었으며, 유지자에 의해 받아들여질 가능성이 높은 변경 사항을 가리킵니다.

우리는 위의 기준을 충족하는 이슈에 매뉴얼으로 ~"Seeking community contributions" 라벨을 추가합니다. 이는 자동으로 라벨을 추가하지 않으며, 인간의 평가가 필요합니다.

한번도 오픈 소스 프로젝트에 기여해본 적이 없는 사람들에게는 무게가 1인 이슈나 ~"quick win" 라벨이 붙은 이슈를 찾으실 것을 권장합니다. 좀 더 숙련된 기여자들은 어떤 것이든 대상으로 삼으시길 바랍니다.

2 이상의 가중치가 있는 보다 복잡한 기능의 경우 라벨 ~"Community Challenge"을 가진 이슈를 살펴보기를 권장합니다. ~"Community Challenge" 이슈에 대한 MR이 Merge되면 사용자 정의 GitLab 상품도 받을 수 있는 기회가 있습니다.

이슈에 작업을 수행하고 싶다고 결정했다면 가능한 한 빨리 적절한 프로덕트 매니저에게 언급하십시오. 프로덕트 매니저는 이후 적절한 GitLab 팀 구성원을 참여시켜 범위, 디자인 및 기술적 고려 사항에 대해 논의할 것입니다. 이를 통해 귀하의 기여가 GitLab 제품과 일치하고 Merge에 대한 재작업과 지연을 최소화할 수 있습니다.

이슈에 ~"Seeking community contributions" 라벨을 적용하는 GitLab 팀 구성원은 위 조건에 부합하는 이슈 설명을 책임지는 제품 매니저로 업데이트하고, 위에서 언급한 바에 따라 잠재적 커뮤니티 기여자를 언급하도록 초청해야 합니다.

Stewardship 레이블

GitLab의 오픈 소스 관리와 관련된 문제에 대해, ~"stewardship" 레이블이 있습니다.

이 레이블은 GitLab의 관리가 토론의 주제인 문제에 사용됩니다. 예를 들어, GitLab Inc.가 GitLab EE에서 GitLab CE로 기능을 추가하기로 계획하는 경우, 관련 문제에 ~"stewardship" 레이블이 지정됩니다.

최근의 예로는 시간 추적 API를 GitLab CE로 가져오는 문제가 있습니다.

기술적 부채 및 지연된 UX

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

이러한 레이블은 개선할 수 있는 사항, 생략된 것, 추가 관심이 필요한 기능 및 개발 속도가 빠른 결과로 인해 뒷전이 된 모든 것을 나타내는 문제에 추가되어야 합니다. 예를 들어, 리팩터링이 필요한 코드는 ~"technical debt" 레이블을 사용하고, 디자인 시스템 가이드라인에 따라 출하되지 않은 것은 ~"Deferred UX" 레이블을 사용해야 합니다.

누구나 문제를 만들 수 있지만, 권한이 없는 경우 해당 레이블을 추가해야 할 수 있습니다. 추가적인 레이블은 개선사항을 릴리스에 쉽게 예약할 수 있도록 사용될 수 있습니다.

이러한 레이블이 지정된 문제는 GitLab에 도입될 새로운 기능을 설명하는 문제와 동일한 우선 순위를 가지고 있으며, 적절한 사람에 의해 릴리스를 예약해야 합니다.

~"technical debt" 문제 또는 ~"Deferred UX" 문제와 관련된 Merge Request을 이슈 설명에 언급해야 합니다.