課題のワークフロー
イシュー・トラッカー・ガイドライン
イシュー・トラッカーを検索してください。同じようなイシューや機能提案がある可能性があります。 アワードの絵文字でサポートを表明したり、ディスカッションに参加してください。
イシュー・トラッカーで提供されている「Bug」イシュー・テンプレートを使ってバグを提出してください。 括弧内のテキストは、何を含めるべきかを説明するためのものです。 実際のイシューを提出する際には省略してください。 コピーペーストして、適当に編集してください。
イシューのトリアージ
GitLabのイシュー・トリアージのポリシーはハンドブックに記載されています。 GitLabチームのイシュー・トリアージを手伝ってくださるのは大歓迎です。 また、四半期に一度、イシュー・バッシュのイベントも開催しています。
最も重要なことは、有効なイシューが開発チームからのフィードバックを受けられるようにすることです。 そのため、そのイシューに協力できる開発者を記載することが優先されます。 GitLabチームから関連する経験を持つ人を選択してください。 その専門知識を持つ人が記載されていない場合は、影響を受けるファイルのコミット履歴を見て誰かを探してください。
また、GitLabTriageを使っていくつかのトリアージポリシーを自動化しています。 これは現在、quality/triage-opsプロジェクトで実行されるスケジュールパイプライン (https://gitlab.com/gitlab-org/quality/triage-ops/pipeline_schedules/10512/editpipeline_schedules/10512/edit、少なくとも開発者のアクセス権が必要) として設定されています。
ラベル
非同期のイシュー処理を可能にするため、私たちはマイルストーンとラベルを使用しています。 マイルストーンへのスケジューリングは、リードとプロダクトマネージャーがほとんどを担当します。 ラベルは全員のタスクです。
ほとんどのイシューには、以下のうち少なくとも1つのラベルが貼られています：
- タイプ：
~feature,~bug,~backstage,~documentation, etc. - ステージ：
~"devops::plan",~"devops::create", etc. - グループ：
~"group::source code",~"group::knowledge",~"group::editor", etc. - カテゴリー：
~"Category:Code Analytics",~"Category:DevOps Score",~"Category:Templates", etc. - 特徴：
~wiki,~ldap,~api,~issues,~"merge requests", etc. - 部門:
~UX、~Quality - チーム：
~"Technical Writing"、~Delivery - 専門分野:
~frontend,~backend、~documentation - リリーススコープ:
~Deliverable,~Stretch、~"Next Patch Release" - 優先順位：
~P1,~P2,~P3、~P4 - 深刻度：～
S1,~S2,~S3、~S4
すべてのラベル、その意味、優先順位はラベルページで定義されています。
これらのどれにも当てはまらないイシューに遭遇し、ラベルを設定することが許可された場合、_いつでも_タイプ、ステージ、グループ、そして多くの場合カテゴリー/フィーチャーラベルを追加することができます。
タイプラベル
タイプ・ラベルは非常に重要で、このイシューがどのようなイシューであるかを定義します。 すべてのイシューは1つだけ持つべきです。
現在のタイプラベルは以下の通りです：
- ~特集
- ~虫
- ~バックステージ
- ~サポートリクエスト
- ~メタ
- ~ドキュメント
多くのタイプラベルには優先順位が割り当てられており、重要度に応じて自動的に上位に表示されます。
タイプ・ラベルは常に小文字で、青色（これはすでにカテゴリー・ラベル用に予約されています）以外ならどんな色でもかまいません。
ラベルのページにある説明は、各タイプのラベルに該当するものを説明しています。
GitLabハンドブックには、バグと 機能リクエストの区別が書かれています。
ファセットラベル
イシューの種類を絞り込むのに便利な場合もあります。 そのような場合は、ファセット・ラベルを追加できます。
以下は、ファセットラベルの非網羅的なリストです：
- ~enhancement:このラベルは、~featureラベルを持つイシューを洗練させることができます。
- ~master:broken”: このラベルは~bugラベルを持つイシューを絞り込むことができます。
- ~failure::flaky-test”: このラベルは~bugラベルを持つイシューを絞り込むことができます。
- ~技術的負債”: このラベルは、”~backstage” ラベルを持つイシューを絞り込むことができます。
- ~静的分析”: このラベルは、”~backstage “ラベルを持つイシューを絞り込むことができます。
- ~”ci-build”: このラベルは~backstageラベルを持つイシューを絞り込むことができます。
- ~パフォーマンス: パフォーマンスのイシューとは、バグや機能のことです。
- ~セキュリティ：セキュリティのイシューは、バグや機能を表すかもしれません。
- ~データベース: データベースのイシューは、~バグや~機能を表すことがあります。
- ~顧客: 顧客が作成したイシュー、または顧客が関心を持つイシューに関するものです。
- ~UI text”:ユーザ補助のマイクロコピー、ボタン/メニュー・ラベル、エラー・メッセージなど、UI内のテキストを追加または変更するイシュー。
ステージラベル
ステージラベルは、イシューがどのステージに属するかを指定します。
ネーミングとカラーコンベンション
ステージラベルは、devops::<stage_key> の命名規則を尊重しています。<stage_key> は、https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/stages.ymlのステージの単一真実源にあるステージキーで、_ はスペースに置き換えられています。
例えば、「管理」ステージは、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 のキーがcontinuous_integrationであるため、gitlab-org グループの~”group::continuous integration” ラベルで表されます。
現在のグループ・ラベルは、のラベルリストでgroup::を検索することで見つけることができます。
これらのラベルはスコープ付きラベルなので、相互に排他的です。
グループは、「製品ステージ、グループ、カテゴリー」ページにリストされています。
私たちは、製品ステージから製品要件をマップダウンするためにグループという用語を使用しています。 チームは、メンバーが割り当てられる予定の作業を収集する何らかの方法が必要であるため、~group:: ラベルを使用しています。
通常、ステージ・ラベルとグループ・ラベルの間には1対1の関係があります。 誰もが貢献できる」という精神に基づき、現在の優先順位に応じて、どの課題もどのグループでも取り上げることができます。 別のグループに属する課題を取り上げる場合、ラベルを貼り替える必要があります。例えば、~"devops::create"、~"group::knowledge" というラベルが貼られたイシューを、プラン・ステージのアクセス・グループの誰かが取り上げる場合、元の~"devops::create" はそのままに、~"group::access" とラベルを貼り替える必要があります。
また、スループットを定量化するために、ステージラベルとグループラベルを使用しています。スループットにおけるステージラベルとグループラベルの使用方法については、「スループットにおけるステージラベルとグループラベル」をお読みください。
カテゴリーラベル
ハンドブックの製品ステージ、グループ、カテゴリのページから：
カテゴリは、他の会社では独立した製品である可能性のある高レベルの機能です。
カテゴリーラベルは、トリアージオートメーションが正しいグループとステージラベルを推測するために使用するため、追加することを強くお勧めします。
特定の分野の専門家であれば、取り組むべきイシューを見つけやすくなります。 また、これらのラベルを購読しておけば、あなたの専門に対応するカテゴリーラベルが付いたイシューが発表されるたびに、Eメールを受け取ることができます。
ネーミングとカラーコンベンション
カテゴリーラベルは、Category:<Category Name> の命名規則を尊重し、その色は#428BCAです。<Category Name> は、https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/categories.ymlにあるカテゴリーの単一真理源にあるカテゴリー名です。
例えば、”DevOps Score “カテゴリーは、devops_score.name の値が “DevOps Score “であるため、gitlab-org グループの~”Category:DevOps Score “ラベルで表されます。
カテゴリのラベルがこの命名規則に従わない場合、label 属性https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/categories.ymlで指定する必要があります。
機能ラベル
ハンドブックの製品ステージ、グループ、カテゴリのページから：
イシューの重み付けなど。 キーワードから担当PMを見つけやすくするために、いくつかの共通機能を括弧内に記載しています。
カテゴリーラベルがない場合は、フィーチャーラベルを追加することを強くお勧めします。フィーチャーラベルは、トリアージオートメーションが正しいグループラベルとステージラベルを推測するために使用されます。
特定の分野の専門家であれば、取り組むべきイシューを見つけやすくなります。 また、これらのラベルを購読しておけば、あなたの専門知識に対応する特集ラベルが付いたイシューが発表されるたびに、Eメールを受け取ることができます。
特徴ラベルの例は、~wiki,~ldap,~api,~issues,~"merge requests" など。
ネーミングとカラーコンベンション
フィーチャーラベルはすべて小文字です。
部門ラベル
現在の部門ラベルは以下の通りです：
- ~ユーエックス
- ~品質
チームラベル
重要：歴史的なチームラベル（Manage、Planなど）のほとんどは、グループラベルやステージラベルに取って代わられ、現在は非推奨となっています。
チーム・ラベルは、この問題を担当するチームを指定します。 チーム・ラベルを割り当てることで、イシューが適切な担当者に注目されるようになります。
現在のチームラベルは以下の通り：
- ~配達
- ~テクニカルライティング
ネーミングとカラーコンベンション
チーム・ラベルは常に大文字で、どのイシューでも最初のラベルとして表示されます。
専門化ラベル
これらのラベルは、作業単位の専門性を狭めます。
- ~フロントエンド
- ~バックエンド
- ~ドキュメント
リリース・スコープ・ラベル
リリーススコープラベルは、リリースの作業に対する期待を明確に伝えるのに役立ちます。 リリーススコープラベルには3つのレベルがあります：
- ~交付可能：現在のマイルストーンで交付が期待されるイシュー。
- ~ストレッチ: 現在のマイルストーンで達成するためのストレッチゴールとなるイシュー。 これらのイシューが現在のリリースで達成されない場合、次のリリースに向けて強く検討されます。
- ~”次のパッチリリース”: 次のパッチリリースに入れるべきイシュー。 これらに最初に取り組み、適切なマイルストーンとともに
~"Pick into X.Y"のラベルをマージリクエストに追加してください。
現在のマイルストーンで予定されている各イシューには、「~Deliverable」または「~Stretch」というラベルを付けてください。 以前のマイルストーンで未解決のイシューには、「~Next Patch Release」というラベルを付けるか、別のマイルストーンに再スケジュールしてください。
優先ラベル
優先ラベルは以下の通りです：
- ~P1
- ~P2
- ~P3
- ~P4
ハンドブックのissue triagepriority labelセクションを参照して、その使用方法を確認してください。
重大度ラベル
私たちは以下の重大度ラベルを持っています：
- ~S1
- ~S2
- ~S3
- ~S4
どのように使用されるかについては、ハンドブックのイシュー・トリアージの重大度ラベルのセクションを参照してください。
コミュニティ貢献者のラベル
ユーザーにとって有益なイシュー、’nice to have’で、現在のところ私たちにその能力がなく、優先順位をつけたくないイシューは、コミュニティが貢献できるように、~”Accepting merge requests “と表示されます。
コミュニティの貢献者はどのイシューに対してもマージリクエストを提出することができますが、「マージリクエスト受付中」というラベルには特別な意味があります。 それは、以下の変更を指しています：
- 私たちはすでに合意しました、
- 明確に定義されていること、
- メンテナーに受け入れられる可能性があります。
コントリビューターが「マージリクエスト受付中」のイシューを選択し、それが私たちのビジョンに合わないことに気づいたり、別の方法で解決したいと思ったりしたために、そのマージリクエストがクローズされてしまうような事態は避けたいのです。
トリアージポリシーに一致するイシューには、自動的に ~”マージリクエスト受付中” ラベルが追加されます。
オープンソースプロジェクトに貢献したことがない人は、~"Accepting merge requests" と書かれた、重みが 1のイシューを探すことをお勧めします。
イシューに貢献したいと決めたら、できるだけ早く適切なプロダクトマネージャーを@ にしてください。 プロダクトマネージャーは適切な GitLab チームのメンバーを引き込んで、スコープやデザイン、技術的な検討事項についてさらに話し合います。 そうすることで、あなたの貢献が GitLab のプロダクトに沿ったものになり、手戻りが発生したり master にマージされるのが遅れたりするのを最小限に抑えることができます。
GitLabのチームメンバーがイシューに~”Accepting merge requests “ラベルを適用した場合、担当プロダクトマネージャーと一緒にイシューの説明を更新し、コミュニティへの貢献者となりうる人を上記の@-mentionに招待してください。
スチュワードシップ・ラベル
GitLabのオープンソース・スチュワードシップに関するイシューには、~”stewardship “ラベルがあります。
このラベルは、GitLabのスチュワードシップが議論されているイシューに使われます。 例えば、GitLab Inc.がGitLab EEからGitLab CEへの機能追加を計画している場合、関連するイシューには~”stewardship “というラベルが付けられます。
最近の例では、GitLab CEにタイムトラッキングAPIを導入するためのイシューがありました。
特集提案
機能提案を作成するには、イシュー・トラッカーにイシューを登録してください。
機能提案を追跡しやすくするため、feature ラベルを作成しました。当面の間、プロジェクトのメンバーでないユーザーはラベルを追加できません。代わりに、コアチームのメンバーの誰かにラベル ~feature をイシューに追加してもらうか、説明文の直後に次のコードスニペットを改行で追加することができます:~feature.
機能提案はできるだけ小さくシンプルにしてください。複雑な提案は小さくシンプルにするために編集されるかもしれません。
機能提案は、イシュー・トラッカーで提供されている「機能提案」テンプレートを使用して提出してください。
インターフェイスの変更については、モックアップを含めると便利です。 インターフェイスを追加または変更するイシューには、~”UX “ラベルを付けるべきです。 これにより、UXチームが意見や指導を提供できるようになります。 自分でラベルを付ける権限がない場合は、コアチームメンバーの誰かにラベルを付けるよう依頼する必要があるかもしれません。
もし自分で何かを作りたいのであれば、まずイシューを開いてGitLabに取り入れるのが面白いかどうかを議論することを検討してください。
イシューのウェイト
イシューの重みによって、1つまたは複数の問題を解決するために必要な作業量を把握することができます。 これにより、より正確な作業スケジュールを立てることが可能になります。
イシューのウェイトを設定することが奨励されています。 以下のガイドラインに従うことで、不必要なオーバーヘッドを発生させることなく、簡単に管理することができます。
- イシューの重量をできるだけ早い段階で設定します。
- 設定された重さに同意できない場合は、重さについて合意が得られるまで他の開発者と議論してください。
- イシューの重みは、問題の複雑さを抽象的に測定したものです。 イシューの重みを時間に直接関連付けないでください。 これはアンカリングと呼ばれ、避けたいことです。
- 重みが1（あるいは重みなし）のものは、本当に小さくてシンプルなものです。 9のものは、GitLabの基本的な部分を大きく書き換えるもので、解決するのが難しい問題がたくさん出てくるかもしれません。 GitLabのテキストを変更するのはおそらく1、新しいGit Hookを追加するのは4か5、大きな機能を追加するのは7から9です。
- 親イシューのウェイトを設定せず、子イシューにウェイトを設定することもできます。
回帰のイシュー
毎月のリリースには、そのリリースで壊れた機能や、パッチリリースに含める必要のある修正を追跡するために、CE issue trackerに対応するイシューがあります（例として、8.3 Regressionsを参照してください）。
問題の説明にあるように、意図するワークフローは、リグレッションを説明するイシューへの参照を含む1つのノートを投稿し、それが利用可能になると、それを修正するマージリクエストへの参照を含むノートを更新することです。
あなたが他のユーザーのノートを更新するのに必要な権限を持っていない貢献者である場合、イシューとマージリクエストの両方を参照して新しいノートを投稿してください。
リリースマネージャは、修正が行われるたびにリグレッション問題のノートを更新します。
技術的負債とUX負債
GitLabのコードベースで改善できることを追跡するために、私たちはGitLabのイシュー・トラッカーで~”technical debt “ラベルを使います。 ユーザーエクスペリエンスの要件を見逃した場合は、~”UX debt “ラベルを使います。
これらのラベルは、改善できること、ショートカットされたこと、追加的な注意が必要な機能、その他開発の速度が速いために置き去りにされたすべてのことを記述するイシューに追加されるべきです。 たとえば、リファクタリングが必要なコードは~”technical debt “ラベルを使うべきですし、デザインシステムのガイドラインに従って出荷されなかったものは~”UX debt “ラベルを使うべきです。
イシューは誰でも作成することができますが、自分で作成する権限がない場合は、特定のラベルを追加してもらう必要があるかもしれません。 追加のラベルをこれらのラベルと組み合わせることで、リリースのための改善スケジュールを立てやすくすることができます。
これらのラベルでタグ付けされたイシューは、GitLabに導入される新機能を説明するイシューと同じ優先度を持ち、適切な担当者がリリースを予定してください。
技術的負債」イシューまたは「UX負債」イシューが関連するマージリクエストを、イシューの説明に必ず明記してください。
後続イシューにおける技術的負債
新機能の開発中に技術的負債を発見することはよくあることです。 実行可能な最小限の変更」の精神に則り、解決はしばしば後続のイシューに先送りされます。 しかし、これを、そうしなければレビュアーに通らないような質の悪いコードをマージしたり、独立にスケジュールされるに値しない些細な事柄を見過ごしたりする言い訳にしてはいけません！
GitLab コードベースでは、スケジューリングのオーバーヘッドや変更の速度から、些細な技術的負債のイシューのコストはすぐにそれを追跡する価値を超えてしまいます。 これは一般的に、オリジナルのマージリクエストでこれらを解決する、あるいは単にフォローアップのイシューをまったく作らない、ということを意味します。
例えば、ファイル間でコピーされているコメントのタイプミスは、同じMRで修正する価値がありますが、フォローアップのイシューを作成する価値はありません。 多くの場所で使用されているメソッドの名前を変更して、その意図を少し明確にすることは、修正する価値があるかもしれませんが、同じMRで発生すべきではなく、一般的に、それ自身のイシューを作成するオーバーヘッドには値しません。 これらのイシューを作成する場合、必ず~P4 ~S4 とラベル付けされます。
技術的負債が深刻化すると、開発速度にも影響を及ぼしかねません。 技術的負債がタイムリーに対処されないと、コードベースの変更が不必要に難しくなり、新機能の追加が困難になり、リグレッションが多発します。
この種の技術的負債を発見した場合、深刻に扱うべきであり、フォローアップのイシューで解決することが適切かもしれませんが、メンテナーは一般的に、元のMRの作成者、または関連する分野のエンジニアリング・マネージャやプロダクト・マネージャからスケジュールの確約を得るべきです。 これは、イシューに適切な優先度/重要度のラベルを付けるか、マイルストーンと担当者を明示する形をとるかもしれません。
未解決の議論がこの方法で解決される前に、メンテナーは常に同意しなければならず、イシューを作成することになります。 タイトルと説明は、通常の方法で作成されたものと同じ品質であるべきです。特に、イシューのタイトルはFollow-upで始まってはいけません! また、作成するメンテナーは、フォローアップのイシューの作業が始まるときに、何らかの立場で関与することを期待すべきです。
