레이블

비동기적 이슈 처리를 위해 마일스톤과 레이블을 사용합니다. 리더 및 제품 매니저는 대부분의 마일스톤 스케줄링을 담당합니다. 레이블링은 모두의 작업입니다. (일부 프로젝트에서는 레이블을 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::로 검색하여 찾을 수 있습니다.

이러한 레이블은 scoped labels이므로 서로 배타적입니다.

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

그룹 레이블

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

그룹 레이블을 추가하는 것이 권장됩니다. 자동화된 정리를 위해 우리의 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::로 검색하여 찾을 수 있습니다.

이러한 레이블은 scoped labels이므로 서로 배타적입니다.

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

우리는 제품 단계에서 제품 요구 사항을 구체화하기 위해 그룹 용어를 사용합니다. 팀이 멤버들이 할당될 작업을 수집하는 방법이 필요하므로 ~group:: 레이블을 사용합니다.

카테고리 레이블

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

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

자동화된 정리를 위해 우리의 triage 자동화가 올바른 그룹과 단계 레이블을 추론하는 데 사용되므로 카테고리 레이블을 추가하는 것이 권장됩니다.

특정 영역에 전문 지식이 있는 경우 작업할 이슈를 쉽게 찾아볼 수 있습니다. 또한 해당 레이블을 구독하여 전문 지식에 해당하는 카테고리 레이블이 이슈에 추가될 때마다 이메일을 받을 수 있습니다.

명명 및 색상 지침

카테고리 레이블은 Category:<카테고리 이름> 명명 규칙을 준수하며 색상은 #428BCA입니다. <카테고리 이름>은 https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/categories.yml의 카테고리 단일 진실 공급원에 있는 이름과 동일합니다.

예를 들어, “DevOps 보고서” 카테고리는 gitlab-org 그룹에서 devops_reports.name 값이 “DevOps 보고서”이므로 ~"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::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"

측면 레이블

개발자는 이슈를 만들 때 추가 정보나 맥락을 추적하기 위해 _facetter labels_를 추가할 수 있습니다. facet 레이블은 때때로 이슈 우선 순위 지정이나 메트릭(종료까지 걸린 시간과 같은)에도 사용됩니다. facet 레이블의 예시로는 ~"customer" 레이블이 있으며, 이는 고객의 관심을 나타냅니다.

부서 레이블

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

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

팀 레이블

중요: 대부분의 기존 팀 레이블(예: 관리 또는 계획)은 그룹 레이블과 단계 레이블로 대체되었습니다.

팀 레이블은 해당 이슈에 대한 책임을지는 팀을 지정합니다. 팀 레이블을 할당하면 해당 문제가 적절한 사람들의 주의를 받을 수 있도록 합니다.

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

  • ~"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" 레이블이 지정됩니다. 왜냐하면 이러한 해결책을 해결하기 위한 MR을 제출하는 것을 환영하기 때문입니다.

커뮤니티 기여자는 원하는 이슈에 대한 MR을 제출할 수 있지만, ~"Seeking community contributions" 레이블은 특별한 의미를 가지고 있습니다. 이는:

  1. 이미 합의된 내용이며,
  2. 명확히 정의되어 있으며,
  3. 유지자에 의해 수락될 가능성이 높습니다.

우리는 컨트리뷕터가 ~"Seeking community contributions" 이슈를 선택하고 그들의 MR이 닫히는 상황을 피하고 싶습니다. 이는 해당 MR이 우리의 비전에 부합하지 않거나 우리가 다른 방식으로 해결하길 원할 수 있기 때문입니다.

이전에 오픈 소스 프로젝트에 기여해본 적이 없는 사람들에게는 무게가 1이거나 ~"quick win" 레이블이 부착된 문제를 찾아서 이를 찾아보기를 권장합니다. 보다 숙련된 기여자들은 이것들 중 중 하나에 임해주는 것을 매우 환영합니다.

2 이상의 무게를 가지고 명확한 범위를 가진 복잡한 기능을 위한 경우, 레이블 ~"Community Challenge" 이슈를 살펴보는 것을 권장합니다. ~"Community Challenge" 이슈에 대한 당신의 MR이 Merge되고, 당신은 사용자 정의 GitLab 상품을 얻을 기회를 얻을 수 있습니다.

이슈에 대해 일 할 것을 결정했다면, 가능한 한 빨리 적절한 제품 매니저를 언급합니다. 제품 매니저는 적절한 GitLab 팀 구성원을 더 논의하기 위해 끌어들일 것입니다. 이는 당신의 기여가 GitLab 제품과 일치하도록 하는 것과 Merge되는 데 필요한 재작업과 지연을 최소화할 것입니다.

이슈에 ~"Seeking community contributions" 레이블을 적용하는 GitLab 팀 구성원은 위의 방법으로 잠재적인 커뮤니티 기여자를 @-mention하여 책임있는 제품 매니저가 이슈 설명을 업데이트하십시오.

(이 이하는 한국어로 번역된 내용을 포함하지 않아도 됩니다.)

관리 레이블

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" 이슈가 연관된 Merge Request을 설명하는 문제 설명에 반드시 언급해야 합니다.