ラベル

非同期のイシュー処理を可能にするために、マイルストーンと ラベルを使用しています。マイルストーンへのスケジューリングのほとんどは、リードとプロダクトマネージャーが行います。ラベルの作成は全員の仕事です。(プロジェクトによっては、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 を追加してください。

すべてのラベルとその意味、優先順位はラベルのページで定義されています。

もしこれらのどれにも当てはまらないイシューに遭遇し、ラベルの設定が許可された場合、_いつでも_タイプ、ステージ、グループ、そして多くの場合カテゴリー/機能のラベルを追加することができます。

タイプラベル

タイプ・ラベルは非常に重要です。どのようなイシューであるかを定義します。すべてのイシューは1つだけ持つべきです。

タイプ・ラベルとサブタイプ・ラベルのSSOTはハンドブックにあります。

多くのタイプラベルには優先順位が割り当てられており、重要度に応じて自動的に一番上に浮くようになっています。

タイプ・ラベルは常に小文字で、青色（これはすでにカテゴリー・ラベルのために予約されています）以外であれば、どんな色でもかまいません。

ラベルのページの説明は、それぞれのタイプラベルに何が該当するかを説明しています。

GitLab ハンドブックでは、どのようなものがバグで、どのようなものが機能リクエストなのかを説明しています。

ステージラベル

ステージラベルは、イシューがどのステージに属するかを指定します。

命名規則と色彩規則

ステージのラベルは、devops::<stage_key> の命名規則を尊重しています。<stage_key> は、https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/stages.yml のステージの単一真理源にあるステージのキーで、_ はスペースに置き換えられています。

例えば、「Manage」ステージは、stages のキーがmanage であるため、gitlab-org グループの~"devops::manage" ラベルで表されます。

現在のステージラベルは、のラベルリストでdevops::を検索することで見つけることができます。

これらのラベルはスコープ付きラベルであるため、相互に排他的です。

ステージラベルは、ディレクションページを自動的に生成するために使われます。

グループラベル

グループ・ラベルは、イシューがどのグループに属するかを指定します。

グループラベルはトリアージオートメーションが正しいステージラベルを推測するために使用するため、追加することを強くお勧めします。

命名規則と色彩規則

グループ・ラベルは、group::<group_key> の命名規則を尊重し、その色は#A8D695 です。<group_key> は、https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/stages.ymlにあるグループの単一の真理源にあるように、_ をスペースに置き換えたグループ・キーです。

例えば、「パイプライン実行」グループは、stages.manage.groups のキーがpipeline_execution であるため、gitlab-org グループの~"group::pipeline execution" ラベルで表されます。

現在のグループラベルは、 group::のラベルリストを検索することで見つけることができます。

これらのラベルはスコープ付きラベルであるため、相互に排他的です。

グループは、Product Stages, Groups, and Categoriesページにリストされています。

グループという用語は、製品ステージから製品要件をマッピングするために使用します。チームには、メンバーが割り当てられる予定の作業を収集する方法が必要なため、~group:: ラベルを使用しています。

カテゴリーラベル

ハンドブックの製品ステージ、グループ、カテゴリーページより：

カテゴリは、例えばPortfolio Managementのように、他社では独立した製品であるかもしれない高レベルの機能です。

カテゴリーラベルは、トリアージオートメーションが正しいグループとステージラベルを推測するために使用するため、追加することを強くお勧めします。

特定の分野の専門家であれば、取り組むべきイシューを見つけやすくなります。また、これらのラベルを購読することで、あなたの専門分野に対応するカテゴリーラベルが付いたイシューが発表されるたびに、Eメールを受け取ることができます。

命名規則と色彩規則

カテゴリー・ラベルは、Category:<Category Name> の命名規則を尊重し、その色は#428BCA です。<Category Name> は、https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/categories.ymlにあるカテゴリーの単一真理源にあるカテゴリー名です。

例えば、「DevOps Reports」カテゴリーは、devops_reports.name の値が「DevOps Reports」であるため、gitlab-org グループの~"Category:DevOps Reports" ラベルで表されます。

カテゴリのラベルがこの命名規則に従わない場合は、 label 属性 https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/categories.ymlで指定する必要があります。

フィーチャー・ラベル

ハンドブックの製品ステージ、グループ、カテゴリーページより：

機能：イシューの重み付けなど。キーワードから担当PMを見つけやすくするために、いくつかの共通機能を括弧内にリストアップしています。

カテゴリラベルがない場合は、機能ラベルを追加することを強くお勧めします。機能ラベルは、トリアージオートメーションが正しいグループとステージラベルを推測するために使用されます。

特定の分野のエキスパートであれば、取り組むべきイシューを見つけやすくなります。また、これらのラベルを購読することで、イシューにあなたの専門分野に対応する機能ラベルが付けられるたびに、Eメールを受け取ることができます。

機能ラベルの例は、~wiki 、~ldap 、~api 、~issues、~"merge requests"です。

命名規則と色彩規則

フィーチャーラベルはすべて小文字です。

ワークフローラベル

イシューは以下のワークフロー・ラベルを使用して、現在のissueステータスを指定します：

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

リリーススコープラベル

リリーススコープラベルは、リリースの作業に対する期待を明確に伝えるのに役立ちます。リリーススコープラベルには3つのレベルがあります：

  • ~"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" のラベルが付けられた課題を探すか、~"quick win" のラベルが付けられた課題を探すことをお勧めします。経験豊富な貢献者は、これらのどれかに取り組むことを大歓迎します。

ウェイトが2以上で、スコープが明確な、より複雑な機能については、のラベルが付いたイシュー~"Community Challenge"を探すことをお勧めします。~"Community Challenge" のイシューに対するあなたの MR がマージされた場合、GitLab のカスタムグッズを獲得するチャンスもあります。

イシューに取り組みたいと思ったら、できるだけ早く適切なプロダクトマネージャに@ をつけてください。プロダクトマネージャーが適切なGitLabチームメンバーを引き込み、スコープやデザイン、技術的な検討事項についてさらに話し合います。こうすることで、あなたの貢献がGitLabの製品に沿ったものになり、手戻りやmainへのマージの遅れを最小限に抑えることができます。

イシューに~"Seeking community contributions" ラベルを貼った GitLab チームメンバーは、担当のプロダクトマネージャーと一緒にイシューの説明を更新し、潜在的なコミュニティ貢献者に上記のように @-メンションで招待してください。

スチュワードシップラベル

GitLabのオープンソース・スチュワードシップに関するイシューには、~"stewardship" ラベルがあります。

このラベルは、GitLabのスチュワードシップが議論されているイシューに使われます。例えば、GitLab Inc.がGitLab EEからGitLab CEへの機能追加を計画している場合、関連するイシューには~"stewardship"。

最近の例としては、GitLab CE にタイムトラッキング API を導入するためのイシューがありました。

技術的・UX的負債

GitLabコードベースで改善できることを追跡するために、GitLabイシュー・トラッカーでは~"technical debt" というラベルを使っています。ユーザーエクスペリエンスを損なうような方法でMVCから逸脱することを選択した場合、~"UX debt" 。

これらのラベルは、改善すべき点、ショートカットしてしまった点、さらに注意が必要な機能、その他、開発速度が速いために置き去りにされてしまったあらゆることを記述したイシューに追加します。たとえば、リファクタリングが必要なコードには~"technical debt" ラベルを、デザインシステムのガイドラインに従って出荷されなかったものには~"UX debt" ラベルを使用します。

誰でもイシューを作成することができますが、自分でラベルを追加する権限がない場合は、特定のラベルを追加してもらう必要があるかもしれません。追加のラベルをこれらのラベルと組み合わせることで、リリースのための改善スケジュールを立てやすくすることができます。

これらのラベルでタグ付けされたイシューは、GitLab に導入される新機能を説明するイシューと同じ優先順位を持ち、適切な担当者がリリースのスケジュールを立てる必要があります。

~"technical debt" issue や~"UX debt" issue が関連するマージリクエストを、issue の説明文に必ず明記してください。