Issue トリアージオンボーディング

#### ステージ 1 - Issue トリアージ

##### ゴール

* トリアージする Issue をどこで探すかを理解する
* Issue に適用するさまざまなラベルを理解する
* 他のチームメンバーに Issue を効果的に伝える方法を理解する
* 「トリアージ済み」の定義を理解する
* 「リグレッション」Issue を特定してラベルを付ける方法を理解する

##### Issue の見つけ方

開発者は [GitLab-Org グループ](https://gitlab.com/gitlab-org/)内のプロジェクトの Issue トラッカーと GitLab.com の [GitLab.com サポートトラッカー](https://gitlab.com/gitlab-com/support-forum/)に投稿されたすべての Issue をトリアージすることが期待されています。

##### チェックリスト

- [ ] 利用可能なさまざまなプロジェクトを探索し、それらの違いを理解する
- [ ] これらのプロジェクトの Issue トラッカーを探索し、最もアクティビティが多いものを見つける

##### Issue のトリアージと伝え方

ラベルは GitLab 製品内で Issue を分類・整理するための最も重要な機能です。Issue に正しくラベルを付けることで、正しいチームメンバーが参照でき、後日見つけることができます。

主な目標は、Issue トラッカーに報告されたすべての Issue にラベルを付けることです。適用された各ラベルはそのラベルのサブスクライバーに新しい Issue を通知するため、関心のあるチームやコミュニティメンバーが調査できるようになります。

各 Issue にラベルを付けるための経験則として、Issue には以下のラベルが必要です:

 * カテゴリラベル 1 つ
 * チームラベル 1 つ以上
 * 機能ラベル 1 つ以上

ワークフローラベルの詳細については、[プロダクト開発フロー](/handbook/product-development/how-we-work/product-development-flow/)をお読みください。

##### Issue の効果的なトリアージ

Issue に正しくラベルを付けることは重要です。これにより Issue が見つかり、正しいサブスクライバーが通知されます。しかし、Issue の深刻さと、潜在的に影響を受ける機能やユーザーを判断することも重要です。

深刻なバグや人気の機能リクエストが発見された Issue を調査している場合は、正しいチームメンバーに直接通知するよう努力すべきです。通常はチームリード・プロダクトマネージャー・または関連する機能の責任者です。

この種の深刻な Issue はいつでも報告される可能性がありますが、リリース時に多発します。RC 時・リリース時・リリース後に、リファクタリングや新機能の追加から生じるリグレッションが報告されます。チームメンバーがそれらを見つけて迅速に修正できるよう、リグレッション Issue に正しくラベルを付けることは非常に重要です。

###### リグレッション Issue へのラベル付け

[リグレッション](/handbook/glossary/#regression)とは、最近の変更（最新リリース）により既存機能の機能性に悪影響をもたらす変更として定義されます。

各リリースには独自のリグレッション Issue があり、既存機能の劣化に関連して提起されたすべての Issue のインデックスとして使用されます。

* 通常は名前に同じ形式を使用します。例えば「8.16 regressions」

報告されたリグレッション Issue に遭遇した場合、以下を行う必要があります:

* まずリグレッションの動作を確認するために Issue を再現しようとする

リグレッションの特定に成功した場合:

* 上記のプロセスに従ってすべての関連ラベルを追加する
* Issue に `regression` ラベルを付ける
* Issue に `Next Patch Release` ラベルを付ける
* リグレッションが導入されたリリースのマイルストーンを追加する（最新リリースと仮定）
  * 最新リリースでない場合、おそらくバックポートしないため、必要に応じて開発者や報告者と話し合う
* その機能に密接に関わったコントリビューターに言及するよう努力する。Git Blame 機能がここで役立つことが多い
* リリースのリグレッション Issue に新しい Issue を参照する

例:

報告された Issue:

v8.15 にアップグレード後、Issue で別のユーザーを言及しても Todo が作成されない

これはリグレッションか？

証明されれば、これは確実にリグレッションとして分類されます。この機能は製品のコア機能です。動作していない場合、リグレッションが導入されています。

まず GitLab.com でサンプルプロジェクトを作成し、提供された手順を使用して（または提供されていない場合は独自の手順を作成して）再現を試みます。

GitLab.com でバグを再現できました。これは適切なリグレッションです！修正されることを確認しましょう！「8.15 regressions」Issue に以下の情報を追加し参照します:

* `Discussion` - これは Discussion チームが担当する機能のためです
* `todos` - この Issue は Todo リスト機能に関連しているためです
* `issues` - Issue でユーザーを言及して再現したためです
* `bug` - 機能が意図したとおりに動作していないためです
* `reproduced on GitLab.com` - GitLab.com で再現したためです！
* `regression` - 機能が以前のリリース（8.14.x）では動作していたためです
* `Next Patch Release` - すべてのリグレッションはパッチリリースで修正するよう努力すべきです
* `8.16 マイルストーン` - これはリグレッションが修正されるフェーズです。修正は 8.15 パッチリリースで行われるため、これは混乱を招きます

##### チェックリスト

- [ ] 既存の Issue を探索し、適用されているラベルに注目する
- [ ] 各プロジェクトで利用可能なラベルを探索・理解する。[GitLab プロジェクトのラベル](https://gitlab.com/gitlab-org/gitlab/-/labels)から始める
- [ ] [ハンドブック](/handbook/engineering/)内のチームを探索する
- [ ] [チームページ](/handbook/company/team/)にリストされているドメインエキスパートを探索する
- [ ] 現在のリリースのリグレッション Issue を特定し、参照されているリグレッション Issue を確認する

---

#### ステージ 2 - コミュニティ支援の準備

##### ゴール

* コミュニティ支援を提供するための十分な製品知識を習得する
* コミュニティ Issue を複製・デバッグするための独自の環境を準備する
* ドキュメントや回答の探し方を理解する
* 利用可能なツールを理解する

##### 方法を学ぶ

Issue トリアージに取り組む開発者は、コミュニティから投稿された Issue に応答・トリアージするために、GitLab 製品の主要機能についての確固たる理解が必要です。

一部の Issue は機能を説明するための内部知識やドキュメントへのリンクのみが必要な場合があります。一部の Issue は、報告されたバグの存在（または非存在）を確認するために隔離された環境での再現が必要な場合があります。一部の Issue は、提案された機能リクエストを適切に把握するために特定の機能セットについてのより深い理解が必要な場合があります。

GitLab.com ユーザーが直面している Issue の診断は、利用可能なツールの十分な知識によって大幅に助けられます。エラートラッキングには [Sentry](https://sentry.gitlab.net)、ロギングには [Kibana](https://log.gprd.gitlab.net) を使用しています。

##### チェックリスト

- [ ] [サポートエンジニアオンボーディングチェックリスト](/handbook/support/onboarding/checklist/)を完成させ、インストールから一般的かつより高度な使用法まで製品の知識を習得する
- [ ] Issue を複製して顧客と同様に独自のインスタンスを管理するための[サポートエンジニアの独自環境構築手順](/handbook/support/onboarding/checklist/)を完成させる
- [ ] [GitLab ナレッジベース](https://docs.gitlab.com)を掘り下げ、機能と API に関する詳細情報の探し方を理解する
- [ ] GitLab.com の本番環境の Issue を診断するために[ランブック](https://gitlab.com/gitlab-com/runbooks/blob/master/howto/kibana.md)を通じて [Sentry](https://sentry.gitlab.net) と [Kibana](https://log.gprd.gitlab.net) に精通する

---

#### ステージ 3 - 最初のバグ修正を送り出す

##### ゴール

* GitLab へのコントリビューションの開発プロセスを理解する
* GitLab のコントリビューションガイドラインを理解する

##### チェックリスト

- [ ] [エンジニアリングワークフロー](/handbook/engineering/workflow/)に概説されている概念と原則に慣れる
- [ ] [GitLab Issue トラッカーのバグリスト](https://gitlab.com/gitlab-org/gitlab/-/issues?sort=created_date&state=opened&label_name[]=type::bug)から作業する既存の `~type::bug` Issue を見つける
- [ ] [コントリビューションガイドライン](community/contribute/)に従い、バグ修正をマージさせましょう！

#### ステージ 4 - GitLab.com の本番 Issue を調査するための本番アクセスの準備

##### ゴール

* GitLab.com のライブ本番サポート Issue をどこで探すかを知る
* ライブ GitLab.com の Issue を調査するための Rails コンソールへの本番アクセスを取得する

##### ライブ本番環境での Issue のデバッグ

本番環境でユーザーやプロジェクトにすでに影響を与えている Issue が GitLab の Issue トラッカーに報告されることがよくあります。GitLab.com は新たに発見されたバグや Issue を理解・再現するための貴重なリソースです。

これらの Issue を調査するには、本番 Ruby on Rails コンソールへのアクセス権を取得する必要があります。

##### GitLab.com サポート Issue の修正

GitLab.com のユーザーベースにのみ影響している Issue が報告される場合があります。本番アクセスがあれば、Issue を特定し、場合によってはコンソールを通じて修正することで、これらのユーザーを支援できることがよくあります。ライブ本番環境でこの種の作業を試みる前に、RoR コンソールの使い方を十分に理解することが重要です。

##### チェックリスト

- [ ] 独自のインスタンスで問題を調査・修正するために Ruby on Rails コンソールの使い方に慣れる
- [ ] [GitLab.com サポートトラッカー](https://gitlab.com/gitlab-com/support-forum/issues)で GitLab.com ユーザーベースから報告された Issue を調べる
- [ ] Infrastructure チームに本番アクセスを要求する