DistributionチームのTriage

共通リンク

• エンジニアリングチームTriage

Issue のトリアージ

用語集

• トリアージ: Issue のトリアージとは Issue を調査し、ラベルとマイルストーンを適用することです。
• 部分的にトリアージされた Issue: for schedulingまたはawaiting feedbackラベルが割り当てられている場合、Issue は部分的にトリアージされたとみなします。
• 完全にトリアージされた Issue: マイルストーン（Backlogであっても）が割り当てられている場合、Issue は完全にトリアージされたとみなします。適切なグループ、優先度、製品カテゴリラベルが適用されている必要があります。

注: ユーザーにはアサインされているがマイルストーンがない Issue はトリアージされていませんが、そのユーザーの責任とみなされ、現時点ではトリアージキューの一部ではありません。

Issue の重大度

重大度ラベルの説明についてはCEドキュメントを参照してください。

ラベル用語集

トリアージ中は、Issue に適切なgroup::ラベルを適用します。

• group::distribution::build は Distribution Buildチームの責任範囲の Issue に使用
• group::distribution::deploy は Distribution Deployチームの責任範囲の Issue に使用
• group::distribution は Distributionチームの共有責任の Issue に使用
• GitLab Features by Groupに基づいて最も適切なグループ

トリアージ中は、Issue によって影響を受ける製品の部分を示す追加ラベルも付けます。Distributionがよく使用するラベルの説明はDistributionよく使用するラベルページにあります。

リソース

トリアージする Issue は以下の基準で識別できます：

• マイルストーンがない
• アサインされていない
• 以下のラベルがついていない：
  • awaiting feedback
  • for scheduling
  • maintainer-discussion
  • needs investigation
  • Seeking community contributions

このような Issue はIssue フィルターを使用してリストアップできます。

プロセス

Distributionチームは、チームの各メンバーが1週間ずつ担当するローテーションスケジュールで Issue トリアージを実施しています。これは入社順に行われます。Issue トリアージ担当中に従うプロセスは以下のとおりです：

1. 前のトリアージ担当者は、週の終わりに週次メタ Issue を作成して自分にアサインしておくべきです。Issue タイトルはIssue triage rotation week of <starting date>です。
2. awaiting feedbackラベルが追加されてから14日間応答がなかった場合に Issue をクローズするポリシーに従います。awaiting feedbackラベルのある Issue リストを確認し、“for issues with no reply"レスポンスでクローズします。
3. トリアージする Issue を確認し、適切なラベルを割り当てます。Issue の根本を究明するために多少の調査が必要な場合があるのは通常のことですが、Issue トリアージはアイテムを識別して分類することを目的としており、Issue の解決ではないことを念頭に置いてください。
4. Issue が記録されたプロジェクトのドメインに直接関係しない場合（例：gitlab-railsアプリケーションへの変更が必要だが、omnibus-gitlabプロジェクトに登録されている場合）、Issue を適切な Issue トラッカーに移動し、最も適切なチームラベルを追加します。どのプロジェクトのトラッカーに置くべきか、またはどのチームのラベルを適用すべきか判断できない場合は、コメントで@gitlab-org/issue-triageをメンションしてQualityチームに助けを求めることができます。
5. Issue がコードベースや作業フローに関するものではなく、GitLab インスタンスのインストール/設定/トラブルシューティングのサポートリクエストである場合は、“problems not related to package installation and configuration"レスポンスを使用して Issue をクローズします。
6. Issue のトリアージを成功させるための必要情報がすべて揃っていない場合は、“issues that lack enough information"レスポンスを使用して情報を求め、awaiting feedbackラベルを追加します。
7. 妥当な時間内に Issue をトリアージできなかった場合は、needs investigationラベルを追加します。
8. Issue によっては、プロジェクトメンテナーが直接確認するのが最善の場合があります。その場合はmaintainer-discussionでラベル付けします。例：
   1. Issue は作成時には正確だったが、現時点では疑問がある場合。
   2. Issue は作成時には正確でなかったり、ビジョンに合わなかったが、現在はそうかもしれない場合。
   3. Issue の実現可能性に興味があるが、提案どおりに実現可能でない場合。
9. 有効な Issue と特定された場合は、For Schedulingラベルを割り当てて部分的にトリアージし、次のマイルストーン（またはBacklogマイルストーン）のスケジュールに入れます。また、重大度ラベルを適用します。
10. 適切な場合はSeeking community contributionsラベルを使用してコミュニティを参加させるようにします。コミュニティへのコントリビューションの良い候補となる Issue は、低い重大度と優先度、または有効な回避策があるものです。workflow::ready for development状態である必要があります。必要な変更がシンプルでわかりやすい場合はquick winラベルを使用します。Omnibusの例を参照してください。
11. Issue が有効で有効な回避策がある場合は、回避策の詳細と共に Issue をクローズし、バグを修正するためのフォローアップ Issue を作成します。Issue に含める内容：
    1. バグを再現する手順の詳細
    2. Issue の回避方法
    3. 期待される動作
    4. 関連する Issue としてのユーザー Issue
    5. 適切な優先度と重大度
12. Issue が部分的にまたは完全にトリアージされたら、その Issue へのリンクをメタ Issue へのコメントとして追加します。<action> <url>の形式が望ましく、<action>はmoved、closed、triaged、resolved、marked as needs investigationのいずれかです。これにより週ごとにトリアージされた Issue を追跡しやすくなります。GitLab のRelated issues機能は Issue 間の不正確な関連付けが生成されるため、この目的に使用しないでください。
13. Issue のトリアージに費やした時間を追跡するために、GitLab の/spendクイックアクション機能を使用します。厳しい制限はありませんが、1週間に3〜5時間が妥当です。
14. どのソフトウェアプロジェクトでも Issue が積み上がるのはほぼ避けられないため、できるだけ Issue 数を減らすようにします。これには主に既存のトリアージされていない Issue のバックログへの対応が含まれます。
15. 次の週次ミーティングで、トリアージ週について報告します。メタ Issue へのリンク、トリアージした Issue 数、費やした時間を共有します。また、プロセスについて変更すべきことがあると思う場合は議論します。次の発表者のために、翌週のミーティングドキュメントのアジェンダアイテムとして同様のヘッダーを作成します。

レスポンステンプレート

Issue に適宜コピーペーストしてください。

GitLab コードベースに関連しない問題の場合

プロジェクト内でサポートを求めている場合は、正しい場所に案内します。

We are sorry you are having troubles. The provided issue description seems to indicate that the problem is not related to this project. Commonly this indicates other troubles such as network connectivity or filesystem permissions.

For this reason, I will close this issue and recommend checking out [how to get further help](https://about.gitlab.com/get-help/) on the GitLab website.

/close

GitLab コードには関連するがOmnibus以外の問題の場合

バグがOmnibus以外の GitLab コードに関連している場合

We are sorry you are having troubles. The provided issue description seems to indicate that the problem is not related to Omnibus.

For this reason, we are moving this report to a more appropriate issue queue.  Please review the bug templates for the new project in case they require additional information to help diagnose the problem.

We also recommend checking out [how to get further help](https://about.gitlab.com/get-help/) on the GitLab website.

情報が不足している Issue の場合

十分な情報なしにチケットが作成された場合は、Bugテンプレートを使用して記入するよう促します。

We can't reproduce the issue with the information you provided here.

Can you please use our `Bug` template to help gather more details?

1. Click on the pencil icon near the issue title to edit the description
1. From the **Choose a template** drop down, select the **Bug** template
1. Read the template, and provide as much information as you can that we ask for
1. Click on the **Save changes** button to apply your changes.
1. Add a comment mentioning you updated the description.

/label ~"awaiting feedback"

返信がない Issue の場合

Issue にawaiting feedbackラベルが付いて2週間経過しても応答がない場合はクローズできます。

We haven't heard back from you, so we're going to go ahead and close the issue.

If you're still experiencing the problem, please re-open the issue and provide the requested information.

/close

返信なしでクローズされた Issue に別のレポーターからの新しいコメントがある場合

Issue が返信なしでクローズされ、元のレポーターでない人がコメントした場合は、新しい Issue を作成するよう求めます。コメントしたコントリビューターをタグ付けしてください。

Thank you for letting us know about your issue COMMENTOR. Unfortunately, this issue was already closed. Please [open a new issue](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/new?issue) following the ***BUG*** template and mark this closed issue as related.

メンテナーが現在の実現可能性を確認すべき Issue の場合

Issue がプロジェクトメンテナーによる直接のレビューが必要に見える場合

I'm going to ask that this issue be reviewed by the project maintainers directly.
This is so that we can make the most accurate decision regarding further work and viability.
/label ~maintainer-discussion

Triageへのオンボーディング

Distributionチームの新メンバーをTriage担当にオンボーディングするのは3ヶ月後から検討します。チームプロセスに十分慣れていると感じているメンバーは、これより早く開始することもできます。

Triageにオンボーディングするために、チームメンバーは1週間、経験豊富なTriageチームメンバーのシャドウを行います。期待されることは以下のとおりです：

• メンターとシャドウは、トリアージ週の前に認識し合い、メンタリングに同意している。
• シャドウはトリアージプロセスドキュメントを事前に読んでいる。
• メンターとシャドウはトリアージ週の早い段階で同期コールを行い、メンターがトリアージへのアプローチ方法を説明する。
• シャドウは週中に非同期でいくつかの Issue のトリアージを試みる。
• メンターとシャドウが一緒にいくつかの Issue をトリアージするためのフォローアップ同期コールが週の後半にスケジュールされる。

シャドウは、ソロトリアージ週に自信が持てるようになるまでに複数週間のシャドウが必要な場合があります。

パイプラインのトリアージ

パイプラインの障害はチーム全員の共有責任であり、利用可能なメンバーができるだけ早く対処する必要があります。とはいえ、トリアージ担当のチームメンバーは発生した障害をフォローアップし、Triageノートに集計サマリーを提供する責任があります。

クリティカルなパイプラインが失敗するたびに自動的に Issue を作成するプロセスを自動化中です。一部のパイプライン障害は#g_distribution Slack チャンネルに通知されますが、まだ Issue が自動的に作成されていないものもあります。進行中の作業を追跡するにはこのepicを参照してください。

パイプライン障害トリアージの推奨ワークフロー

1. オプションとして、Slack メッセージで最初の考えを共有するか、アクションプランを示すコメントを残します。
2. Issue が自動的に作成されたかどうかを確認します。されていない場合は作成してください。
3. 問題を解決するために貢献するすべての人が単一の情報源として Issue を使用できるよう、Issue へのリンクを Slack の最初のメッセージに含めます。
4. Issue の調査を開始したら、pipeline failure::under investigationラベルを追加します。
5. Issue に次の形式でコメントします：@gitlab-bot retry_job <job-id>。これにより、プロジェクトのメンテナー権限を必要とせずに、triage-ops botが指定されたジョブをリトライします。
6. 必要に応じてリトライコマンドを繰り返します。これにより失敗したジョブが通過する場合は Issue をクローズします。そうでない場合は、根本原因を手動で修正してリトライするか、根本原因を追跡する新しい関連 Issue を作成します。
7. 問題を緩和してパイプラインを通過させることができたが、Issue が将来再び発生する可能性がある場合は：
   • 緩和するために取った対応を説明するコメントを書きます。
   • 問題の根本的な修正を調査/実装するためのフォローアップ Issue が既に存在するかどうかを確認し、このパイプライン Issue 障害にリンクします。そのようなフォローアップ Issue が存在しない場合は、作成してリンクします。
   • すでに停止していたリリースを再起動する必要があった場合は、パイプラインを修正した後、@gitlab-bot retry_job <job-id of stop-review-*>を使用して手動で環境を停止します。そのジョブは自動的に再トリガーされないため、宙吊りのリリースがELBsのクォータ枯渇を引き起こす可能性があります。chart Issue #5326を参照してください。
8. まだ壊れた状態のパイプラインを修正するためのフォローアップ Issue を必要とする障害も、チームの認識を高めるために記録する必要があります。それらの Issue にはBroken Pipelineラベルを付けます。
9. アップストリームの障害によって引き起こされた障害はUpstream bugでラベル付けし、関連するアップストリーム Issue にリンクします。
10. Issue をクローズする前に、マイルストーンを設定し、pipeline failure::under investigationが追加されていることを確認します。これはメトリクスの目的のために重要です。

Distributionの各プロジェクトで実装されたパイプラインとジョブの詳細は以下のとおりです：

1. omnibus-gitlab

ページのソースコードを見る - ページの編集 - please contribute.