레이블

비동기적인 문제 처리를 위해 마일스톤 및 레이블을 사용합니다. 리드와 제품 관리자가 대부분의 일정 관리를 담당합니다. 레이블링은 모두의 작업입니다. (일부 프로젝트에서는 레이블을 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 자동화에서 올바른 단계 레이블을 추론하기 위해 그룹 레이블을 추가하는 것이 매우 권장됩니다. (https://handbook.gitlab.com/handbook/engineering/infrastructure/engineering-productivity/triage-operations/#auto-labelling-of-issues-and-merge-requests).

명명 및 색상 규칙

그룹 레이블은 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:: 레이블을 사용하여 팀의 구성원이 할당하려는 작업을 모아두도록 합니다.

카테고리 레이블

핸드북의 제품 단계, 그룹 및 카테고리 페이지에서: > 카테고리는 예를 들어 다른 회사에서 독립적인 제품이 될 수 있는 고수준의 기능입니다. 문제가 어떤 전문분야에 속하는지에 대한 전문 지식이 있다면 작업할 문제를 찾기가 더 쉽습니다. 또한 해당 레이블에 구독하여 해당 전문 분야에 해당하는 카테고리 레이블이 지정될 때마다 이메일을 수신할 수 있습니다.

네이밍 및 색상 규칙

카테고리 라벨은 Category:<카테고리 이름> 네이밍 규칙을 준수하며 색상은 #428BCA입니다. <Category Name>은 https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/categories.yml의 카테고리에 대한 참조 출처에서의 카테고리 이름을 의미합니다.

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

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

기능 라벨

핸드북의 제품 단계, 그룹 및 카테고리 페이지에서:

기능: 작고 분리된 기능으로 예를 들어 이슈 가중치입니다. 몇몇 일반적인 기능은 담화표에서 키워드로 쉽게 담당 PM을 찾을 수 있도록 괄호안에 나열되어 있습니다.

카테고리 라벨이 적용되지 않는 경우, 기능 라벨을 추가하는 것이 매우 권장됩니다. 이는 우리의 triage automation에서 올바른 그룹 및 단계 라벨을 추측하는 데 사용되기 때문입니다.

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

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

네이밍 및 색상 규칙

기능 라벨은 모두 소문자로 작성합니다.

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 라벨

개발자들은 생성된 이슈에 대한 추가 정보 또는 컨텍스트를 추적하기 위해 _페이셋 라벨_을 추가할 수 있습니다. 페이셋 라벨은 때로는 이슈 우선순위 지정이나 측정(예: 종료까지의 시간)에 사용됩니다. ~"customer" 라벨은 고객의 관심을 나타냅니다.

부서 라벨

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

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

팀 라벨

중요: (Manage 또는 Plan과 같은) 대부분의 과거 팀 라벨은 이제 그룹 라벨 및 단계 라벨을 대신하여 deprecated 되었습니다.

팀 라벨은 이 문제에 대한 책임을 지는 팀을 지정합니다. 팀 라벨을 지정함으로써 해당 문제가 적절한 사람들의 관심을 받을 수 있도록 합니다.

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

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

사용 방법을 보려면 이슈 triage 우선순위 라벨 섹션을 참조하십시오.

심각도 라벨

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

  • ~"severity::1"
  • ~"severity::2"
  • ~"severity::3"
  • ~"severity::4"

사용 방법을 보려면 이슈 triage 심각도 라벨 섹션을 참조하십시오.

커뮤니티 기여자 라벨

GitLab에는 GitLab 사용자에게 명백한 이점을 제공하는 명확한 해결책이 있는 많은 이슈가 있습니다. 그러나 현재 로드맵에서 모든 이러한 제안에 대한 여유가 없을 수 있습니다. 이러한 이슈는 GitLab에게 날짜 예정 없음이기 때문에 ~"Seeking community contributions" 라벨이 지정됩니다.

커뮤니티 기여자는 원하는 모든 이슈에 대한 MR(병합 요청)을 제출할 수 있지만, ~"Seeking community contributions" 라벨은 특별한 의미를 갖습니다. 다음 내용을 가리킵니다.

  1. 우리가 이미 합의한 내용,
  2. 명확하게 정의된 내용,
  3. 유지자가 수락할 가능성이있는 내용.

그런 내용들을 피하고 싶습니다. 커뮤니티 기여자가 ~"Seeking community contributions" 이슈를 선택하고, 그들의 MR이 우리의 비전에 맞지 않는 것으로 깨닫거나 다른 방식으로 해결할 수도 있기 때문입니다.

우리는 위의 조건을 충족하는 이슈에 수동으로 ~"Seeking community contributions" 라벨을 추가합니다. 이 라벨은 자동으로 추가하지 않습니다. 이것은 인간적으로 추후 평가가 필요하기 때문입니다.

한 번도 오픈 소스 프로젝트에 기여해본 적이 없는 사람들에게는 1의 가중치 또는 ~"quick win" 라벨이 지정된 이슈를 찾을 것을 권장합니다. 경험 많은 기여자들은 외의 모든 이슈에 착수 을 환영합니다.

2 또는 그 이상의 가중치가 있는 더 복잡한 기능에 대해서는, ~"Community Challenge" 라벨의 이슈를 검토하는 것을 권장합니다. ~"Community Challenge" 이슈에 대한 MR이 합병되면, 맞춤형 GitLab 제품을 얻을 기회가 있습니다.

이슈에 작업하고자 하는 것으로 결정했다면, 최대한 빨리 적합한 제품 관리자 를 언급하도록합니다. 제품 관리자는 그러면 적절한 GitLab 팀 멤버들을 더 구체적으로 범위, 디자인 및 기술적 고려 사항을 논의하기 위해 참여하게 될 것입니다. 이것은 귀하의 기여가 GitLab 제품과 일치하도록 하며 병합에 대한 재 작업 및 지연을 최소화할 것입니다.

이슈에 ~"Seeking community contributions" 라벨을 적용하는 GitLab 팀 멤버들은 위에 설명된 조건에 부합하는 경우에는 해당 이슈 설명을 책임 있는 제품 관리자를 업데이트하여 위의 @-mention를 통해 잠재적인 커뮤니티 기여자를 초청합니다.

Stewardship label

오픈 소스 스튜어드십과 관련된 이슈의 경우 ~"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" 이슈와 관련된 병합 요청을 이슈 설명에 언급하는 것을 잊지 마세요.