레이블

비동기 이슈 처리를 허용하기 위해, 우리는 마일스톤 과 레이블을 사용합니다. 리드와 제품 관리자들은 대부분의 일정을 마일스톤에 배치하는 일을 처리합니다. 레이블링은 모든 사람이 해야 할 작업입니다. (일부 프로젝트의 경우, 레이블은 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” 단계는 ~"devops::manage" 레이블로 표현됩니다.

현재 단계 레이블은 ‘devops::’에 대한 레이블 목록 검색을 통해 확인할 수 있습니다.

이 레이블은 범위 있는 레이블이며, 따라서 상호 배타적입니다.

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

그룹 레이블

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

그룹 레이블을 추가하는 것이 강력히 권장됩니다. 이는 우리의 트리아지 자동화가 올바른 단계 레이블을 유추하는 데 사용됩니다.

명명 및 색상 규칙

그룹 레이블은 group::<group_key> 명명 규칙을 준수하며 색상은 #A8D695입니다.

<group_key>는 https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/stages.yml의 그룹에 대한 단일 진실 소스에서의 그룹 키입니다.

예를 들어, “Pipeline Execution” 그룹은 ~"group::pipeline execution" 레이블로 표현됩니다.

현재 그룹 레이블은 ‘group::’에 대한 레이블 목록 검색을 통해 확인할 수 있습니다.

이 레이블은 범위 있는 레이블이며, 따라서 상호 배타적입니다.

그룹은 제품 단계, 그룹 및 카테고리 페이지에 나열되어 있습니다.

우리는 ~group:: 레이블을 사용하여 제품 단계에서 제품 요구 사항을 매핑합니다.

팀은 구성원이 할당될 작업을 수집할 방법이 필요하므로, ~group:: 레이블을 사용하여 이를 수행합니다.

카테고리 레이블

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

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

카테고리 레이블을 추가하는 것이 강력히 권장됩니다. 이는 우리의 트리아지 자동화가 올바른 그룹 및 단계 레이블을 유추하는 데 사용됩니다.

특정 분야의 전문가라면 작업할 이슈를 찾는 것이 더 쉬워집니다. 또한 해당 레이블에 구독하여 귀하의 전문성과 일치하는 카테고리 레이블로 이슈에 라벨이 붙을 때마다 이메일을 받을 수 있습니다.

명명 및 색상 규칙

카테고리 레이블은 Category:<Category Name> 명명 규칙을 준수하며

색상은 #428BCA입니다.

<Category Name>은 https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/categories.yml의 카테고리에 대한 단일 진실 소스에 있는 카테고리 이름입니다.

예를 들어, “DevOps Reports” 카테고리는 gitlab-org 그룹의 ~"Category:DevOps Reports" 레이블로 표현되며, 이 레이블의 devops_reports.name 값은 “DevOps Reports”입니다.

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

기능 레이블

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

기능: 작은, 개별적인 기능, 예: Issue 가중치. 몇 가지 일반적인 기능은 책임 있는 PM을 키워드로 찾기 위해 괄호 안에 나열되어 있습니다.

카테고리 레이블이 적용되지 않는 경우 기능 레이블을 추가하는 것이 강력히 권장됩니다. 이는 우리의 분류 자동화에 의해 정확한 그룹 및 단계 레이블을 추론하는 데 사용됩니다.

특정 분야의 전문가인 경우 작업할 문제를 찾기 더 쉽습니다. 또한 해당 기능 레이블이 붙은 이슈가 있을 때마다 이메일을 받으려면 이러한 레이블을 구독할 수 있습니다.

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

명명 및 색상 규칙

기능 레이블은 모두 소문자로 작성됩니다.

워크플로우 레이블

이슈는 다음 워크플로우 레이블을 사용하여 현재 이슈 상태를 지정합니다:

  • ~"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과 같은 대부분의 역사적 팀 레이블은 그룹 레이블 및 단계 레이블을 위해 더 이상 사용되지 않습니다.

팀 레이블은 이 이슈에 대한 책임 있는 팀을 지정합니다. 팀 레이블을 할당하면 이슈가 적절한 사람의 주목을 받게 됩니다.

현재 팀 레이블은 다음과 같습니다:

  • ~"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" 레이블은 특별한 의미를 갖습니다. 이는 다음과 같은 변경 사항을 지적합니다:

  1. 이미 동의한 사항입니다,

  2. 잘 정의되어 있습니다,

  3. 유지 관리자가 수락할 가능성이 높습니다.

기여자가 ~"Seeking community contributions" 이슈를 선택하고 나서 머지 요청이 닫힐 경우, 이는 우리 비전에 맞지 않거나 다른 방식으로 해결하고 싶기 때문에 발생하지 않도록 하고자 합니다.

위 기준에 적합한 이슈에는 수동으로 ~"Seeking community contributions" 레이블을 추가합니다.

이 레이블은 자동으로 추가되지 않습니다. 인간 평가가 필요하기 때문입니다.

오픈 소스 프로젝트에 기여한 적이 없는 사람들은 가중치 1으로 레이블이 지정된 ~"Seeking community contributions"가 붙은 이슈를 찾아보는 것을 권장합니다.

또는 ~"quick win" 레이블이 붙은 이슈도 좋습니다.

더 많은 경험이 있는 기여자는 그들 중 어떤 것이라도 다룰 수 있습니다.

가중치가 2 이상이고 명확한 범위를 가진 보다 복잡한 기능에 대해서는 레이블 ~"Community Challenge"가 붙은 이슈를 찾아보는 것을 권장합니다.

~"Community Challenge" 이슈에 대한 귀하의 MR이 머지되면, 커스텀 GitLab 상품을 받을 기회도 있습니다.

작업하기로 결정했다면 가능한 한 빨리 @-mention하여 적절한 제품 관리자에게 알리십시오.

그런 다음 제품 관리자는 적절한 GitLab 팀 구성원을 호출하여 범위, 디자인 및 기술 고려 사항을 더 논의합니다.

이렇게 하면 귀하의 기여가 GitLab 제품과 일치하여 머지가 되는 데 있어 재작업과 지연을 최소화할 수 있습니다.

~"Seeking community contributions" 레이블을 이슈에 적용하는 GitLab 팀 구성원은 책임이 있는 제품 관리자와 함께 이슈 설명을 업데이트해야 하며, 위와 같이 잠재적인 커뮤니티 기여자가 @-mention 할 수 있도록 초대해야 합니다.

관리 레이블

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

이 레이블은 GitLab의 관리가 논의 주제가 되는 문제에 사용됩니다. 예를 들어, GitLab Inc.가 GitLab EE에서 GitLab CE로 기능을 추가할 계획이라면, 관련 문제는 ~"stewardship" 레이블이 붙습니다.

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

기술 부채 및 연기된 UX

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

이 레이블은 개선할 수 있는 사항을 설명하는 문제, 빠르게 처리된 단축키, 추가적인 주의가 필요한 기능, 그리고 개발 속도가 높아져 놓친 모든 것에 추가되어야 합니다.

예를 들어, 리팩토링이 필요한 코드는 ~"technical debt" 레이블을 사용해야 하며, 우리 디자인 시스템 가이드라인에 따라 출시되지 않은 것은 ~"Deferred UX" 레이블을 사용해야 합니다.

누구나 이슈를 생성할 수 있지만, 스스로 레이블을 추가할 수 있는 권한이 없다면 특정 레이블 추가를 요청해야 할 수 있습니다. 추가 레이블은 이러한 레이블과 결합되어 개선 사항을 릴리스 일정에 쉽게 맞출 수 있도록 도와줍니다.

이러한 레이블이 태그된 이슈는 GitLab에서 소개될 새로운 기능을 설명하는 이슈와 동일한 우선 순위를 가지며, 적절한 사람이 릴리스를 위해 일정에 추가해야 합니다.

~"technical debt" 이슈나 ~"Deferred UX" 이슈와 관련된 병합 요청을 이슈 설명에 반드시 언급해 주세요.