Content last updated 2026-07-20

コードレビューガイドライン

コードレビューはすべてのマージリクエストで必須です。コードレビューガイドラインに慣れ、それに従ってください。

概要

コードレビューはすべてのマージリクエストで必須です。コードレビューガイドラインに慣れ、それに従ってください。

これらのガイドラインは、あなたまたはコミュニティメンバーのマージリクエストを誰がレビュー、承認、マージする必要があるかも説明しています。また、チームメンバーが順守すべきレビュー応答 SLOについても説明しています。

価値観

GitLab のすべてのレビュアーは、私たちのレビュアー価値観を目指して努力する必要があります。

レビュアー

GitLab のすべてのエンジニアは、同僚やコミュニティ貢献者のマージリクエストでコードレビューを実行でき、また奨励されています。マージリクエストをレビューしたい場合は、誰かがあなたにマージリクエストをアサインするまで待つこともできますが、オープンなマージリクエストのリストをブラウズして、フィードバックや質問を残すことも大歓迎です。

マージリクエストをレビューしてくれる人は、チームページまたは GitLab エンジニアリングプロジェクトのリストから見つけることができます。どちらも data/team_members/person/* 配下の YAML ファイルから供給されています。

マージリクエストコーチになることで、コミュニティ貢献者がマージリクエストを準備するのを助けることもできます。

すべてのエンジニアがすべてのマージリクエストをレビューできますが、マージリクエストを承認する能力はメンテナに制限されている点に注意してください。

PTO の前にレビューアサインメントを管理する

有給休暇を取る前に、レビュアーは次のことを行うべきです:

  • PTO 前の最後の労働日に、自分にアサインされているすべての MR レビューを確認する
  • レビュー SLO を尊重し、次のいずれかを行う:
    • PTO の日付と復帰予定を MR にコメントとして残す
    • 別の利用可能なレビュアーにレビューを再アサインする
  • PTO の開始前にレビューを完了できない場合は、MR の作成者に直接通知する

これにより、マージリクエストがあなたの不在中にブロックされるのを防ぎます。

メンテナ

メンテナはコードレビューの専門家である GitLab エンジニアであり、GitLab プロダクトおよびコードベースを非常によく知っており、1 つまたは複数の GitLab エンジニアリングプロジェクトでマージリクエストを承認する権限を持っています。

すべてのプロジェクトには少なくとも 2 人のメンテナがいるべきですが、ほとんどのプロジェクトにはそれ以上いる必要があります。一部のプロジェクトには専門分野ごとに別のメンテナがいます。たとえば、メインの GitLab コードベースでは、フロントエンド、バックエンド、データベースに別々のメンテナがいます。

優れたエンジニアはしばしば優れたレビュアーでもありますが、コードレビューはそれ自体のスキルであり、シニアリティに関係なく、すべてのエンジニアがそのスキルを磨く機会を同じように得てきたわけではありません。良いメンテナの大きな部分は既存のプロダクトとコードベースを非常によく知っていることに由来し、それによって他のフィーチャーとの一貫性のなさ、エッジケース、または容易に見逃される非自明な相互作用を見つけられる、という点にも注意することが重要です。

レビュアー／メンテナになることは、直近のグループを超えてより広い責任を引き受けることを意味します。効果的に作業できる余地を作るために、利用可能なキャパシティを調整する必要があります。各プロジェクトには異なるワークロードが伴うため厳密な公式はありませんが、バーンアウトを避け、これがチームのキャパシティにどう影響するかをマネージャーが理解できるよう、必ずマネージャーと議論してください。

コードベースとプロダクト全体の品質を守り、確実にするため、既存メンテナと同等のレビュースキルを持つことを説得力を持って示したときにのみ、人はメンテナになれます。

通常のレビュアーと同様に、メンテナはチームページまたは GitLab エンジニアリングプロジェクトのリストで見つけることができます。

Senior+ メンテナ

Senior+ エンジニアにとって、マネージャーまたはチームメンバーリレーションズと合理的配慮プロセスに沿って議論していない限り、メンテナであることは職務ファミリーの一部です。個人がそのプロジェクトの貢献者であり、アクティブなレビュアーであるかぎり、プロダクトの一部と見なされるエンジニアリングプロジェクトはどれも適切です。2022-08-01 以降、メンテナシップのタイムフレーム期待値については次の表を使用しています:

説明タイムフレーム
Intermediate Engineersメンテナシップはオプション
既存の Senior+ Engineerまだメンテナでない既存の Senior+ エンジニアは、チームの生産性とモチベーションを支援するため、トレイニープログラムの完了を奨励されます。トレイニープログラムの完了タイムフレームは決まっていません。
新規採用の Senior+オンボーディング中、新規採用の Senior+ エンジニアはレビュアーの代わりにトレイニーメンテナになるよう依頼されます。オンボーディング完了から 12 か月以内にメンテナシップが完了することを期待します。
Senior への昇進Senior 役職に移るエンジニアは、昇進前にすでにメンテナになっていることを期待します。

レビュアー／メンテナとの面会

コードをレビューする人を知っていれば、コミュニケーションがより容易になります。機会（たとえばコーヒーチャット）を捉えて、レビュアーを知り、氷を砕き、将来のコミュニケーションを促進してください。

プロジェクトメンテナになる方法

これは特にバックエンド、フロントエンド、データベースのメンテナに適用されます。他の領域（ドキュメントなど）には、以下に文書化された別のプロセスがあるかもしれません。

メンテナシップを考える前に、まず貢献者である必要があります。トレイニーメンテナプロセスでレビュアーになる前に、プロジェクトに少なくとも数件のフィーチャーまたはメンテナンスの貢献を行う必要があります。これらの貢献は、プロジェクト独自のドメインと設計を理解できるほど十分に複雑である必要があります。

メンテナシップのチェックインとメンターシップ

関心のあるレビュアーは、メンテナシップへの進捗状況を議論し、最近の詳細なレビューをレビューするため、定期的にマネージャー／メンターとチェックインする必要があります。たとえば 1-on-1 中などです。レビュアーは、レビューに関する追加の視点を得るため、メンテナメンターを探すことも奨励されています。レビュアーは、メンテナシップへの適格性について、「正当化されれば、いつでもメンテナになる準備ができている」という観点で考えるよう奨励されます。

このテンプレート トレイニーメンテナ Issue テンプレート を使って トレイニーメンテナ Issue を開くこともでき、最終マージリクエストに反映される例を積み上げることができます。

レビュアー向けのマージリクエストフィードバック

各レビューが完了した後、レビュアーはなぜマージリクエストがマージ準備ができていると考えるかについての正当化を書く必要があります。この正当化はメンテナによってレビューされ、メンテナが正当化に同意する場合は、追加の非ブロッキングコメントがあっても、コメントに 👍 リアクションを追加する必要があります。メンテナは、最初のレビューで見逃されたブロッキング懸念を強調するコメントを残す必要があります。

メンテナシップ指名プロセス

いつでも、マネージャー／メンターはレビュアーをメンテナとして追加するマージリクエストを開くことを選択できます。このマージリクエストには、なぜレビュアーがメンテナになるべきかについてマネージャー／メンターからの正当化があるべきです。いつでも自分でこのマージリクエストを開くこともできます。内容とステップをサポートする利用可能なマージリクエストテンプレートがあります。

メンテナシップの前提条件

マージリクエストを開く前に、作成者は次のことを行うべきです:

  1. レビュアーの最近のマージリクエストのいくつかについて、正当化をレビューする。
  2. レビュアーに関するフィードバックを得るため、少なくとも 2 人のメンテナに非公開で連絡する。レビュアーは、これらのメンテナが誰になり得るかの提案を持っているかもしれません。

メンテナシップフィードバックを依頼する

マージする前に、マネージャー／メンターは次のことを行うべきです:

  1. 当該専門分野のメンテナをメンションし、マネージャー／メンターに直接フィードバックを提供するよう依頼する。否定的なフィードバックは、マージリクエストではなくマネージャー／メンターに非公開で伝えるべきだと強調する。これは、ネガティブフィードバックは 1-1というコラボレーションの価値観に沿っています。ネガティブフィードバックの管理の追加ガイダンスを参照してください。
  2. マージリクエストを 1 週間オープンのままにし、メンテナがマネージャー／メンターにフィードバックを提供する時間を与える。
  3. 既存のメンテナから少なくとも 2 件の承認を得る。
ネガティブフィードバックの管理

マネージャー／メンターがレビュアーはメンテナになる準備ができていないことを示すプライベートフィードバックを受け取った場合:

  1. マネージャー／メンターは提起された懸念をレビューし、マージリクエストをクローズするほど実質的かを判断するべきです。
  2. マネージャー／メンターは、レビュアーが取り組むべきフィードバックがあるとコメントしてマージリクエストをクローズしますが、フィードバックは機密のままにします。
  3. マネージャー／メンターは、1 対 1 の会話でレビュアーに直接フィードバックを提供します。このアプローチにより、レビュアーはメンテナステータスのために再提出される前にギャップに対処できます。マネージャー／メンターがこのフィードバックを早期に求めて受け取るほど、良いです。

メンテナ準備の意見の相違を扱う:

マネージャー／メンターは、現在のメンテナがトレイニーメンテナの準備や資格に同意しないときに提起された懸念を理解しようとするべきです。次のガイドラインを使って、単一の不承認がトレイニーメンテナに対する承認を覆すべきかどうかを判断してください。

  1. 他の価値観に沿って、メンテナの懸念は個人的または偏見に基づくべきではありません。
  2. メンテナの懸念はメンテナの責任と一致するべきです。
  3. メンテナの懸念は次の事実に根ざすべきです:
  4. トレイニーメンテナが一貫して従来の方法での MR レビューを行っていない、または
  5. 一貫してトレイニーメンテナがコード品質と基準の確保に無責任であった。単発のインシデントはトレーニングプロセスで予期されます。

決定を十分に情報に基づいて行うため、マネージャーはフィードバックに関する個人情報を共有することなく、2 人の既存メンテナに非公開で連絡を取るべきです。マネージャーは最終的にトレイニーメンテナの準備状況に責任を持ち、トレイニーメンテナにメンテナの責任を委ねる決定を所有します。

メンテナシップの承認

マージ後、マネージャーは次のことを行うべきです:

  1. エンジニアリングコミュニケーションハンドブックの Slack セクションにリストされている該当チャンネル、および #backend_maintainers/#frontend_maintainers および #backend/#frontend でこの変更を発表する。
  2. Engineering Week-in-Review ドキュメントにアップデートを投稿する。アジェンダは社内のみです。Google ドライブで ‘Engineering Week-in-Review’ を検索してください。

承認済みプロジェクトメンテナの追加ステップ

以下のプロジェクトに関心のあるレビュアーは、レビュアーからメンテナに進むため、プロジェクトメンテナになる方法で説明されているものに加えて、リストされたタスクを完了する必要があります。

gitlab-rails のプロジェクトメンテナプロセス

  • バックエンドメンテナの場合は、@gitlab-org/maintainers/rails-backend にピングしてください
    • バックエンドメンテナは Rails コアフレームワーク gem を担当します。 これらの gem をアップグレードするためにアプリケーションを更新する作業に加え、これらの gem に関連する GitLab の安定性と可用性のために必要なその他の作業を含みます。
  • フロントエンドメンテナの場合は、@gitlab-org/maintainers/rails-frontend にピングしてください

gitlab-database のプロジェクトメンテナプロセス

ヒント:

  • ~"database::reviewed" ラベルを適用したレビューだけに制限されたダッシュボードが欲しい場合は、データベースグループマネージャーに連絡して取得してください。

gitlab-components のプロジェクトメンテナプロセス

gitlab-components

承認後、MR をマージするメンテナは次のことを行います:

  • 新しく承認されたメンテナを CI コンポーネントメンテナグループ（@gitlab-org/maintainers/ci-components）に追加する。
  • #ci_components_maintainers で発表し、Engineering Week-in-Review document にアップデートを投稿する

design.gitlab.com または gitlab-svgs のプロジェクトメンテナプロセス

design.gitlab.com または gitlab-svgs

  • メンテナになる方法を理解する。
  • すべてのデザイナーは gitlab-design プロジェクトのメンテナです。gitlab および gitlab-ui プロジェクトの UI（.scss）のメンテナになることに関心がある場合は、エンジニアリングレビューワークフローに従ってください。
  • 十分な MR をレビューでき、多様な種類が含まれるようにするのはあなた次第です。チームからのレビューを求めることも、#upstream-studios や #g_pajamas-design-system Slack チャンネルでレビューを依頼することもできます。トレーニングを進めるのに十分な MR を受け取っていない場合は、能動的に Pajamas への自分自身の改善に取り組んでください。これは、プロダクトの全体的な理解と品質の高い貢献を示し、進捗を後押しするのに役立ちます。メンテナはあなたを導く準備ができています。
  • あなたのレビューは、レビュアーの責任に加えてメンテナの責任もカバーすることを目指すべきです。デザインメンテナは、使いやすさに影響を与え、既存のユーザー体験をイテレートする MR、および／またはデザインガイドライン、標準、パターンの使用を含む MR に焦点を当てるべきです。あなたの承認は、マージ準備ができていると考えていることを意味します。
  • メンテナとして、自分が持っていない専門知識を他者に頼り続ける必要があります。MR の説明では、メンテナレベルでの結果を示す取り組みを強調し、続けて取り組みたいスキルと、この Issue へのリンクを追加してください。(例)。

gitlab-quality のプロジェクトメンテナプロセス

gitlab-quality

gitlab-secure-analyzers のプロジェクトメンテナプロセス

gitlab-secure-analyzers

gitlab-elasticsearch-indexer のプロジェクトメンテナプロセス

gitlab-elasticsearch-indexer

gitlab-advanced-search-migration のプロジェクトメンテナプロセス

customers-gitlab-com のプロジェクトメンテナプロセス

customers-gitlab-com

gitlab-secure-license-db のプロジェクトメンテナプロセス

gitlab-secure-license-db

gitlab-chart のプロジェクトメンテナプロセス

gitlab-chart

gitlab-operator のプロジェクトメンテナプロセス

gitlab-operator

ai-gateway のプロジェクトメンテナプロセス

ai-gateway

メンテナになるための学習

レビュアーは誰でも、マネージャーによっていつでもメンテナになることが推奨される可能性がありますが、メンテナになりたいレビュアーは、メンテナマインドセットに入り、メンテナからのフィードバックから学ぶため、各レビューでいくつかの基本的なステップに従う必要があります。

マージリクエストを作成し、チームメンバーエントリーで project-name: trainee_maintainer として役割を示します。マージのため MR をマネージャーにアサインします。

各レビューの後、レビュアーはなぜマージリクエストがマージ準備ができていると考えるかをまとめるべきです:

例:

良いですね！この MR は Issue を解決しており、コード変更が比較的孤立しているため安全に見えます。

LGTM！この MR は良いイテレーションだと感じます。フィーチャーフラグの背後にあるため、リスクは低いです。

メンテナは、同意する場合は 👍 でレビュアーのコメントに反応し、マージ時にキャッチされるべきだったと感じる追加コメントがある場合は、レビュアーがコメントを認識できるようピングするべきです。

一部のレビュアーは、自分の進捗を追跡するのが役立つと感じます。これは必須ではありませんが、人々がこれを行ってきたいくつかの方法があります:

メンテナになった後

新しいメンテナになった場合は、自分の役割を果たすために必要な関連権限をリクエストするため、以下の手順に従ってください:

  • Slack のメンテナのグループチャンネルに参加する: #frontend_maintainers、#backend_maintainers など。
  • グループ内のメンテナに、メンテナ固有のミーティングがあれば招待してもらう。
  • 所属する GitLab メンテナグループへのアクセスをリクエストする: frontend、backend、または database。
  • Single Person Access Request Issue テンプレートを使用して、メンテナとして活動するプロジェクトでメンテナ権限をリクエストします。Issue を作成したら、別のメンテナにこれらの権限を付与してもらうよう依頼します。

レビュアーメンターシッププログラム

新しいメンテナのトレーニングとオンボーディングは重要なプロセスです。エンジニアリングチームが成長し、MR の総数が急速に拡大するにつれて、メンテナごとの MR レビュー数はすぐに維持困難になります。

最近の調査では、新しいメンテナのためのトレイニープロセスがいくつかの重要な要因によって妨げられていることが示されています:

  • レビュアーの自己認識される準備度と自信
  • 大量の MR をレビューするレビュアーの能力
  • コードベース全体にわたる十分な幅をカバーする多様な MR をレビューするレビュアーの能力

構造

  1. 参加は、メンテナとレビュアーの両方にとって任意です。
  2. メンテナは、一度に最大 4 人のレビュアーを直接メンタリングできます。
  3. メンター／レビュアーの割り当ては maintainer_mentorship.yml ファイル内で調整されます。
  4. 新しいレビュアーは、maintainer_mentorship.yml で空きのある既存メンテナを探し、メンテナに直接連絡する必要があります。
  5. 6 週間ごとに、メンテナは各レビュアーとチェックインします。これは非同期またはコーヒーチャットで行えます。
  6. チェックインのゴールは: MR をレビューし、質問に答え、疑問を明確化し、卒業に向けた準備状況を追跡することです。
  7. メンターシップは 12 か月でキャップされ、その時までにレビュアーは卒業の準備ができているはずです。
  8. レビュアーが卒業した後、達成を祝い、さらなる質問に答えるため、少なくとも 1 回の追加チェックインをスケジュールするべきです。
  9. 新しい受講者のために空間を確保するため、卒業したレビュアーを maintainer_mentorship.yml ファイルから必ず削除してください。

利点

  1. メンテナのメンターシップスキルを開発・拡大する
  2. レビュアーが不十分な領域でスキルアップする定期的なタッチポイントを提供する
  3. 現在存在するよりも、レビュアー／メンテナの間に強いネットワークを作る
  4. メンテナの直接の指導を受けることで、GitLab コードベースの所有権を取ることへのコンピテンスと自信を促進するはずです。
レビュアー／メンテナの役割からの移行

マネージャーとの相談後、レビュアー／メンテナの役割から離れたいか、離れる必要があるかもしれません。状況に関係なく、これが起こるのはまったく問題ありません！ 責任やワークロードは変わります。プロジェクトは進化します。だから、最も重要な領域に時間を費やすことを確実にすることが重要です。変更を公式にし、reviewer roulette から削除されるには:

  1. YAML ファイルを更新する方法については Team Member Database ドキュメントを参照してください。
  2. 新しい MR を作成し、MR をマネージャーにアサインします。
レビュアー／メンテナへの復帰

レビュアー／メンテナから離れる期間の後、これらの職務を行うことに戻りたい場合があります。リクエストを公式にするには、プロジェクトメンテナになる方法のセクションを参照し、追跡 Issue とマージリクエストを作成し、コンテキストのために以前の追跡 Issue とマージリクエストを参照してください。プロセスは通常、迅速に進められるため、新しく作成したマージリクエストは即時レビューのためにマネージャーにアサインされるべきです。

より小規模なプロジェクトのメンテナシッププロセス

これは、特定のグループに属するプロジェクトおよび／または社内貢献者が 10 人未満のプロジェクトが、メンテナシッププロセスを定義および文書化するために使用できる汎用テンプレートです。

プロジェクトはこれらのメンテナシップのガイドラインを採用して、メンテナが足りないプロジェクトでメンテナを育てるのに役立てることができます。

  • すべてのチームメンバーは エンジニアリング開発の役割に相談し、レビュアーまたはメンテナになるべきです。
  • プロジェクトメンテナになる方法 の下に、プロジェクト固有のメンテナプロセスを追加する。軽量テンプレートが提供されています。
  • MR レビュアーを特定するために、プロジェクト内で simple_roulette を使用して Danger Review を有効にする。
  • メンテナと見なすために必要なマージリクエストレビュー数を減らす。
  • プロジェクト自体への作業をメンテナシップの進捗としてカウントする。
  • プロセスを速めるためにメンテナメンターを必要とする。
  • 過去のレビューに基づいて練習用 MR をいくつか作成する。MR のコピーをクローズ状態で作成し、リンクをプロジェクトメンテナシッププロセスで提供する。
  • プロジェクトにまだ存在しない場合は、プロジェクト固有の開発ガイドラインの作成を検討する。
  • プロジェクトメンテナになる方法を、プロジェクトの README に追加する。

より小規模なプロジェクトのための加速メンテナオンボーディング

メンテナ数が限られている小規模なプロジェクトは、加速されたオンボーディングプロセスから利益を得ることができます。このプロセスは、これらの小規模なプロジェクトでは十分な機能作業と MR がないため、メインの GitLab メンテナシップよりも複雑ではありません。各プロジェクトは、ニーズに合わせてこのプロセスを修正できます。

オンボーディングプロセスは以下のステップで構成されます:

  • メンテナになる基準と、新しいメンテナのオンボーディングプロセスを確立し、Issue に文書化する。たとえば:
    • 対象エンジニア: TypeScript で作業したいすべての人。
    • トレーニング: 録画されたコードウォークスルーとインタラクティブなペアリングセッション。
    • メンテナになる基準: コードベースへの自信に基づいてトレーニング後に自己選択。
  • エンドツーエンド機能でのペアプログラミングを通じて知識を共有する。現在のプロジェクトメンテナが、潜在的なメンテナを教育するための一連のペアリングセッションをホストします。VS Code 拡張機能のパイロットでは、4 週間にわたる 4 つの 1 時間セッションで VS Code コマンドの 1 つの実装を変更しました。
  • 潜在的な新しいメンテナとコードウォークスルーとペアリングセッションをスケジュールする。コードベースの包括的な理解を提供するために必要な適切な時間量とセッション数を決定する。
  • パイロットプログラムでは、各潜在的なメンテナが X 回の MR レビューを行うことも検討しましたが、プロジェクト内に十分な MR がありませんでした。
  • プロセスを設計した後、潜在的な新しいメンテナからフィードバックを求める。彼らはウォークスルー、ペアリングセッション、その他のリソースの異なる組み合わせを好むかもしれません。

このオンボーディングプロセスに従うことで、プロジェクトはコードベースとプロジェクトのビジネスロジックを十分に理解した新しいメンテナを効率的に追加できます。このプロセスの実例は GitLab VS Code Extension プロジェクトで見られます。

メンテナプロセステンプレート

プロジェクトのメンテナ要件を定義するための出発点として、この軽量テンプレートを使用してください。

  • プロジェクトのドメインとガイドラインに慣れるため、Issue に取り組む。
  • メインの GitLab プロジェクトで使われていないプログラミング言語の場合は、プロジェクト固有の言語トレーニングを完了する（例: golang トレーニング）。
  • プロジェクト固有のリリースプロセス（存在する場合）をレビューする。
  • [project or team] Slack チャンネルに参加する。
  • マージリクエストを作成し、チームメンバーエントリー で project-name: trainee_maintainer として役割を示します。マージのため MR をマネージャーにアサインします。
  • オプション: 利用可能であれば、練習用 MR でシミュレートしたレビューを実行する。
  • オプション: MR のピアレビューを行う。
  • オプション: メンテナになるのを手伝う既存のメンテナに連絡する(メンテナになる方法)。

メンテナ比率

私たちは、フロントエンドとバックエンドの両方で、エンジニア : メンテナ比率を 6 以下に保つことを目指しています。これは Engineer : Maintainer Ratio ダッシュボードで追跡しています:

https://10az.online.tableau.com/t/gitlab/views/DraftEngineerMaintainerRatio/EngineerMaintainerRatio_1

メンテナ需要

需要は、月、プロジェクト、テクノロジーでフィルタリングできる Maintainership Demand ダッシュボードを見て判断できます:

https://10az.online.tableau.com/#/site/gitlab/views/MaintainershipDemand/MaintainershipDemand?:iid=1

このダッシュボードについて

メトリクスの定義:

  • Incoming Merge Requests - 任意の作成者によって開かれたマージリクエストの総数。
  • Average Availability - メンテナがレビューを受け付けており、忙しい・不在・休暇・キャパシティ上限ではない時間の平均パーセンテージ。
  • Total Maintainers - team.yml で maintainer が指定されたエンジニアの数
  • Available Maintainers - Total Maintainers × Average Availability
  • Monthly Review Target - メンテナごとに想定される月次レビュー件数に基づく可変数。月次レビューターゲットは、領域ベースのカスタムにすることも、Incoming Merge Requests の数に基づいて一般的に定義することもできます。このメトリクスについての詳細はこちらをお読みください。
  • Target Maintainer Counts - その月の領域に向けた Incoming Merge Requests の数、現在の Total Maintainers の数、Average Availability に基づいて、月ごとに変わる可変数。
  • Minimum Maintainers Required - Incoming Merge Requests の需要を満たすために必要な Available Maintainers の数。
  • Maintainers Needed - Minimum Maintainers Required を満たすために必要となる、まだ足りない Available Maintainers の数。
  • Technology Group - データベース、バックエンド、フロントエンド、CI Templates、Workhorse など、メンテナに特定の専門分野があるプロジェクト用

チャートの説明:

  • Available Maintainers VS Need - メンテナのターゲット、合計、可用性の全体的なハイレベル表示。
  • Projects where maintainers are needed - 前月のデータに基づき、より多くの Available Maintainers が必要と予測される領域の出力。
  • Project/Area Maintainership Health - Minimum Maintainers Required を時間経過とともに満たしていないプロジェクト (GitLab) または領域 (backend) のパーセンテージ。
  • Unhealthy Core Areas of Maintainership Health - Minimum Maintainers Required を満たしておらず、かつ月あたり 100 件を超える Incoming Merge Requests を受け取っているプロジェクト (GitLab) または領域 (backend) のパーセンテージを時間経過とともに表示。
  • Part of Product Repos - Full Data - 上記のすべてのメトリクスを含む、各プロジェクト、領域、月のオールインクルーシブチャート。

月次レビューターゲット

ターゲットは、Available Maintainers の数（上記の説明参照）と、「合理的な」メンテナごとの月次レビュー数に基づいて計算されます。「合理的」は別途の分析 Issue で一部の領域について定義されています。これらは “maintainer_custom_targets” Sisense スニペットで定義されたカスタムターゲットです。Incoming Merge Requests の数に基づいて、他のすべてのプロジェクト向けの一般的なターゲットがあります。これらの数値は最初のイテレーションで、分析 Issue に基づいています。需要の少ないプロジェクトでは、メンテナが少ない（したがってより多くの月次レビュー件数を 1 人あたり要求する）一方、需要の多いプロジェクトではメンテナが多い（したがってより少ない月次レビュー件数を 1 人あたり要求する）というものでした:

  • デフォルトのターゲットはメンテナごとに 5 件のレビュー
  • 領域が 10 件超のマージリクエストを受け取る場合、月次ターゲットはメンテナごとに 10 件のレビュー
  • 領域が 500 件超のマージリクエストを受け取る場合、月次ターゲットはメンテナごとに 40 件のレビュー
  • 領域が 1000 件超のマージリクエストを受け取る場合、月次ターゲットはメンテナごとに 16 件のレビュー
  • 領域が 1500 件超のマージリクエストを受け取る場合、月次ターゲットはメンテナごとに 20 件のレビュー

maintainer_custom_targets Sisense スニペットを使って、領域にカスタムターゲットを追加するには:

  • Sisense で、Snippets > maintainer_custom_targets に移動
  • プロジェクト名と、オプションでテクノロジーグループに基づいて新しい CASE/WHEN 文を追加
  • このプロジェクトでの合理的なレビュー件数に従い、1 人あたり理想的な月次レビューターゲットに数を設定

注意点

  • Total Maintainer のカウントが 0 と表示される場合があります - このデータは reviewer roulette を使用してメンテナの総数を判断しています。なぜなら Sisense からプロジェクトのメンバーシップにアクセスできず、また、実際にはアクティブでないメンテナ／オーナーがいるプロジェクトも多いためです。メンテナがいるにもかかわらず 0 と表示される理由の 1 つは、表示されたプロジェクト名が reviewer roulette の team.yml で使われているプロジェクト名と一致していないからです。別の理由は、プロジェクトが reviewer roulette を使用していない場合です。これらの場合、プロジェクトは reviewer roulette を使用するよう正しくセットアップして構成する必要があります。最後に、team.yml はプロジェクトまたは領域の要件と一致する必要があります。たとえば、あなたのプロジェクトのレビューが任意のメンテナに行ける場合、team.yml は maintainer を指定するべきです。あなたのプロジェクトのレビューが専門分野で分かれている場合、team.yml は maintainer [SPECIALTY] を指定し、マージリクエストはその専門分野に従ってラベル付けされるべきです。

メンテナ／レビュアーの可用性

私たちは、レビュー負荷を妥当なレベルに保ちつつ、タイムリーに MR をレビューできる人がいるようにするため、タイムゾーンをまたぐ十分なレビュアーとメンテナを持つことを目指しています。これを Reviewer/Maintainer Availability and Capacity ダッシュボードで追跡しています:

https://10az.online.tableau.com/#/site/gitlab/workbooks/2286852/views

ドメインエキスパート

私たちのコードレビューガイドラインでは、デフォルトでドメインの専門知識を持つチームメンバーにレビューを割り当てると述べています。

ドメインエキスパートとは?

私たちは現在、チームメンバーをドメインエキスパートとして資格付ける厳密なルールを提供しておらず、代わりに暗黙的および自己識別という退屈なソリューションを使っています。

暗黙的:

  • 特定のステージ／グループ（例: Create: Source Code）で働くチームメンバーは、彼らが取り組むアプリの領域について暗黙的にドメインエキスパートと見なされます。
  • 特定のフィーチャー（例: 検索）で働くチームメンバーは、そのフィーチャーについて暗黙的にドメインエキスパートと見なされます。

自己識別:

  • チームメンバーは、特定のフィーチャー（例: ファイルアップロード）についてドメインエキスパートとして自己識別できます。
  • チームメンバーは、特定のテクノロジー（例: GraphQL）、プロダクトフィーチャー（例: ファイルアップロード）、またはコードベースの領域（例: CI）についてドメインエキスパートとして自己識別できます。

ドメインエキスパートとして自己識別する方法

ドメインエキスパートと見なされるための唯一の要件は、特定のテクノロジー、プロダクトフィーチャー、またはコードベースの領域での十分な経験を持っていることです。この基準を満たすかどうかは、チームメンバー本人に委ねます。

  1. data/domain_expertise.yml にある新しい、または既存のドメイン専門知識キーを定義します。
  2. 自分のYAML ファイルで、新しい domain_expertise プロパティを追加し、すべてのドメイン専門知識キーをリストします。

例:

domain_expertise.yml

webpack:
  display_name: Webpack
  link: https://webpack.js.org/
frontend_architecture:
  display_name: Frontend Architecture
  link: https://docs.gitlab.com/ee/development/fe_guide/architecture.html

your_handle.yml

domain_expertise:
    - webpack
    - frontend_architecture

ドメインエキスパートとして自己識別するときは、すでに確立されたドメインエキスパートまたは対応するエンジニアリングマネージャーにマージしてもらうよう MR をアサインすることをお勧めします。

ドメインの専門知識を持つ人のリストはどこにありますか?

チームメンバーの専門知識はエンジニアリングプロジェクトページで確認できます。

レビュー対応時間

他の人をブロック解除することは常に最優先事項であるため、レビュアーはタイムリーにマージリクエストをレビューすることを期待されており、これが他のタスクや優先事項に否定的な影響を与える場合でもそうです。

そうすることで、コンテキストが記憶に新しいうちにマージリクエストに関わるすべての人が、より速くイテレートでき、貢献者の体験が大幅に向上します。

レビュー応答 SLO

レビュー準備が整ったコードに迅速なフィードバックを保証するため、私たちは Review-response サービスレベル目標 (SLO) を維持しています。 SLO は GitLab チームメンバーに適用されますが、他のより広いコミュニティ貢献者には適用されません。

SLO は次のように定義されます:

Review-response SLO = (レビューが提供される時間) - (MR がレビュアーにアサインされる時間)

SLO 値はマージリクエストの作成者によって異なります:

  • GitLab チームメンバーから: Review-response SLO < 2 営業日

Review-response SLO の時間枠内にマージリクエストをレビューできないと思う場合は、コメントでできるだけ早く（レビューリクエストを最初に受け取ってから 36 時間以内まで）作成者に知らせ、他のレビュアーまたはメンテナを探すのを手伝うようにしてください。これにより、作成者はブロックを解除して、自分の仕事を素早く進められます。レビュアーから自分を外してください。

レビュアーは、いくつかの他の絵文字を使用してステータスを伝えることもできます。これらの他のステータスの詳細については、開発者ドキュメントの code review ページを参照してください。

もちろん、不在で GitLab.com ステータスを通じてこれを伝えている場合、作成者はこれを認識し、別のレビュアーを自分で見つけることを期待されます。

マージリクエストの作成者が Review-response SLO よりも長くブロックされている場合は、Slack でレビュアーに思い出させるか、別のレビュアーを追加する自由があります。

期待値の管理

MR をレビューするようにアサインされていて、Review-response SLO 内に対応できない場合は、遅れた対応について作成者に知らせるコメントを MR に残すべきです。可能であれば、作成者がフィードバックを期待できる時期を示すか、代替のレビュアーを見つけるのを手伝うべきです。

MR の作成者として、Review-response SLO を満たせず、アサインされた人と連絡が取れない場合は、別のレビュアーまたはメンテナに再アサインするべきです。

コードオーナー承認

一部の GitLab プロジェクトでは、特定のファイルパスとタイプに対する承認を管理するために、GitLab の CODEOWNERS ファイル機能を使用しています。gitlab-org/gitlab プロジェクトでは、職務分離のベストプラクティスに従うため、CODEOWNERS 承認ルールと MR 承認設定の組み合わせを使用しています。このセクションでは、gitlab-org/gitlab プロジェクトの CODEOWNERS 変更の対象承認者を更新するプロセスを説明します。

CODEOWNERS ファイル自体の Code Owners は、ファイル内のルールで管理されます。たとえば:

CODEOWNERS @gitlab-org/development-leaders @gitlab-org/tw-leadership

CODEOWNERS ファイルの Code Owner を更新する方法は 2 つあります:

  1. CODEOWNERS 変更を承認する能力をすでに持つグループのメンバーシップを、標準のアクセスリクエストプロセスで更新する。
  2. 関連する行を更新するためにマージリクエストを開く。既存の Code Owner がマージリクエストを承認する必要があります。可視性のためにセキュリティコンプライアンスチームメンバーにピングすることもお勧めします。

@gitlab-org/development-leaders グループは、Engineering 内の開発部門の管理職トラックの Senior Manager 以上、および個人貢献者トラックの Distinguished Engineer 以上のチームメンバーで構成されます。

最終更新 July 30, 2026: Merge pull request #483 from kyama0/translation/batch-2026-07-29-1 (c955a93f)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License