라벨

비동기적으로 이슈를 처리하기 위해 마일스톤과 라벨을 사용합니다. 리더와 제품 매니저는 대부분 마일스톤으로 일정을 관리합니다. 라벨링은 모두의 업무입니다. (어떤 프로젝트에서는 라벨을 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 라벨을 추가하세요.

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

이 중 이것과 전혀 다른 라벨이 있는 경우, 그리고 라벨을 설정할 수 있는 권한이 있는 경우, 항상 유형, 단계, 그룹 및 종종 카테고리/기능 라벨을 추가할 수 있습니다.

유형 라벨

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

유형 및 하위 유형 라벨의 단일 소스는 핸드북에서 확인할 수 있습니다.

일부 유형 라벨에는 자동으로 우선순위가 할당되어 있어 중요도에 따라 가장 상단에 노출됩니다.

유형 라벨은 항상 소문자이며 파란색을 제외한 모든 색깔을 사용할 수 있습니다(파란색은 이미 카테고리 라벨에 예약됨).

라벨 페이지의 설명에서 각 유형 라벨에 속하는 것이 무엇인지 설명합니다.

GitLab 핸드북에서 버그가 되는 시점과 기능 요청이 되는 시점을 문서화하였습니다.

단계 라벨

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

명명 및 색상 규칙

단계 라벨은 devops::<단계_키> 네이밍 규칙을 준수합니다. <단계_키>는 단일 진실의 단계에서 사용되는 키이며 https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/stages.yml에서 _가 공백으로 대체된 것입니다.

예를 들어, “관리” 단계는 gitlab-org 그룹의 경우 manage로 키가 지정되어 있으므로 ~"devops::manage" 라벨로 표현됩니다.

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

이 라벨들은 스코프 라벨이므로 상호 배타적입니다.

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

그룹 라벨

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

당사의 triage 자동화에서 사용되므로 그룹 라벨을 추가하는 것이 권장됩니다. infer the correct stage label.

네이밍 및 색상 규칙

그룹 레이블은 group::<그룹 키> 네이밍 규칙을 준수하며 색상은 #A8D695입니다. <그룹 키>는 여기에 있는 그룹의 단일 정보 출처에서 일반적으로 _를 공백으로 대체한 그룹 키입니다.

예를 들어, “파이프라인 실행” 그룹은 stages.manage.groups에서의 키가 pipeline_execution이므로 gitlab-org 그룹의 ~"group::pipeline execution" 레이블로 표시됩니다.

현재 그룹 레이블은 group::를 검색하여 찾을 수 있습니다.

이러한 레이블은 범위가 지정된 레이블이므로 서로 배타적입니다.

제품 단계, 그룹 및 카테고리 페이지에서 그룹을 찾을 수 있습니다.

팀이 회원들이 할당할 계획을 세우는 작업을 수집하는 방법이 필요하기 때문에 제품 단계에서 제품 요구 사항을 매핑하기 위해 우리는 ~group:: 레이블을 사용합니다.

카테고리 레이블

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

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

카테고리 레이블을 추가하는 것이 매우 권장됩니다. 그것은 우리의 트리아지 자동화에서 올바른 그룹 및 단계 레이블을 추론하기 위해 사용됩니다.

특정 영역에 대한 전문가이라면 일할 문제를 찾는 것이 더 쉬워집니다. 또한 해당 레이블에 가입하여 전문분야에 해당하는 카테고리 레이블이 지정될 때마다 이메일을 받을 수 있습니다.

네이밍 및 색상 규칙

카테고리 레이블은 Category:<카테고리 이름> 네이밍 규칙을 준수하며 색상은 #428BCA입니다. <카테고리 이름>은 여기에 있는 카테고리의 단일 정보 출처에 나와있는 카테고리 이름입니다.

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

카테고리의 레이블이 이 네이밍 규칙을 준수하지 않는 경우, 여기의 label 속성으로 지정해야 합니다.

기능 레이블

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

기능: 작고 구체적인 기능, 예를 들어 이슈 가중치 등. 일부 일반적인 기능은 키워드에 의해 책임 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"

Facet 레이블

생성된 이슈에 대한 추가 정보나 컨텍스트를 추적하려면 개발자가 _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은 많은 이슈가 GitLab 사용자에게 논쟁이 없는 혜택을 제공하는 명확한 해결책을 갖고 있습니다. 그러나 GitLab은 현재 로드맵에서 이러한 제안에 대한 모든 용량을 가지고 있지 않을 수 있습니다. 이러한 이슈는 ~"Seeking community contributions" 레이블이 붙여져 있습니다. 왜냐하면 우리는 이를 해결하기 위한 MR을 환영하기 때문입니다.

커뮤니티 기여자는 원하는 모든 이슈에 대한 MR을 제출할 수 있지만, ~"Seeking community contributions" 레이블에는 특별한 의미가 있습니다. 이는 다음과 같은 변경 사항을 가리킵니다.

  1. 이미 합의된 변경 사항,
  2. 잘 정의된 변경 사항,
  3. 메인테이너가 받아들일 가능성이 높은 변경 사항.

우리는 기여자가 ~"Seeking community contributions" 이슈를 선택하고, 그런 다음 그들의 MR이 우리의 비전과 일치하지 않는 것을 깨달아서 이를 해결하거나, 다른 방식으로 해결하고 싶어하는 상황을 피하고자 합니다.

우리는 이미 위에 설명된 기준에 부합하는 이슈에 수동으로 ~"Seeking community contributions" 레이블을 추가합니다. 이 레이블은 자동으로 추가하지 않습니다. 왜냐하면 이것은 사람의 평가를 필요로하기 때문입니다.

우리는 어떤 오픈 소스 프로젝트에도 기여해본 적이 없는 사람들에게 가중치 1의 ~"Seeking community contributions"로 레이블이 붙어있는 이슈를 찾아보거나 ~"quick win" 레이블가 달린 이슈를 찾는 것을 권장합니다. 숙련된 기여자들은 어떤 것이든 적극적으로 해결해주기를 환영합니다.

가중치가 2 이상이고 명확한 범위를 가진 더 복잡한 기능에 대해서는 레이블 ~"Community Challenge"이 달린 이슈를 살펴보는 것을 권장합니다. 만일 ~"Community Challenge" 이슈에 대한 MR이 병합되면, 사용자 정의 GitLab 굿즈를 받을 기회도 생깁니다.

이슈에서 작업하고 싶다고 결정한 경우, 가능한 빨리 적절한 제품 관리자에게 언급하십시오. 그제서야 제품 관리자는 적절한 GitLab 팀 멤버를 추가로 토론하기 위해 찾아올 것입니다. 이는 여러분의 기여가 GitLab 제품과 일치하도록 하고, 병합되기까지의 재작업과 지연을 최소화하기 위한 것입니다.

이슈에 ~"Seeking community contributions" 레이블을 적용하는 GitLab 팀 멤버는 책임 있는 제품 관리자가 명시된 이슈 설명을 업데이트하도록 하여, 위에서 설명한 대로 잠재적인 커뮤니티 기여자에게 @-멘션을 달라고 초대합니다.

관리 레이블

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

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

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

기술 및 UX 부채

GitLab 코드베이스에서 개선할 수 있는 사항을 추적하기 위해 GitLab 이슈 트래커에서 ~"technical debt" 레이블을 사용합니다. ~"UX debt" 레이블은 MVC(Minimum Viable Change)를 따르지 않고 사용자 경험을 해치는 방식으로 우회하는 경우에 사용됩니다.

이러한 레이블은 개선이 필요한 사항, 거칠게 넘어간 단축키, 추가 관심이 필요한 기능 및 모든 개발 속도가 빠른 탓에 남겨진 기타 사항을 설명하는 이슈에 추가해야 합니다. 예를 들어 리팩터링이 필요한 코드는 ~"technical debt" 레이블을 사용하고, 디자인 시스템 가이드라인에 따라 출시되지 않은 항목은 ~"UX debt" 레이블을 사용해야 합니다.

누구나 이슈를 만들 수 있지만, 권한이 없는 경우 레이블을 추가해야 할 수 있습니다. 추가 레이블을 결합하여 해당 릴리스에 개선을 쉽게 예약할 수 있습니다.

이러한 레이블이 지정된 문제는 GitLab에 도입될 새로운 기능을 설명하는 문제와 동등한 우선순위를 가지며, 해당하는 담당자에 의해 릴리스에 예약되어야 합니다.

~"technical debt" 이슈나 ~"UX debt" 이슈와 관련된 병합 요청을 해당 이슈의 설명에 언급해야 합니다.