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

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

概要

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

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

価値観

GitLab のすべてのレビュアーはレビュアー価値観を目指す必要があります。

レビュアー

すべての GitLab エンジニアは同僚やコミュニティコントリビューターのマージリクエストに対してコードレビューを実行でき、奨励されます。マージリクエストをレビューしたい場合は、誰かが割り当てるまで待つこともできますが、オープンなマージリクエストの一覧を閲覧してフィードバックや質問を残すことも歓迎されます。

マージリクエストをレビューする人を見つけるには、チームページまたは GitLab エンジニアリングプロジェクトのリストを参照してください。どちらも data/team_members/person/* の YAML ファイルによって提供されています。

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

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

PTO 前のレビュー割り当て管理

有給休暇を取る前に、レビュアーは以下を行うべきです:

  • PTO 前の最終出勤日に割り当てられたすべての MR レビューを確認する
  • 以下のいずれかによりレビュー SLO を遵守する:
    • MR に PTO の日付と予定の復帰日を示すメッセージを残す
    • レビューを他の利用可能なレビュアーに再割り当てする
  • PTO 開始前にレビューを完了できない場合は、MR 作者に直接通知する

これにより、あなたの不在中にマージリクエストがブロックされないことを確保します。

メンテナー

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

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

優れたエンジニアは多くの場合優れたレビュアーでもありますが、コードレビューはそれ自体がスキルであり、すべてのエンジニアがそのスキルを磨く同じ機会を持っているとは限りません。良いメンテナーになることの大きな部分は、既存の製品とコードベースを非常によく知ることから来ており、それにより他の機能との非整合性、エッジケース、非自明な相互作用を見逃さずに発見できます。

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

コードベースと製品全体の品質を保護・確保するために、人々がメンテナーになるのは、レビュースキルが既存のメンテナーと同等のレベルであると説得力を持って実証した後のみです。

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

シニア以上のメンテナー

シニア以上のエンジニアにとって、メンテナーになることは合理的配慮プロセスに沿ってマネージャーまたはチームメンバー関係と議論した場合を除き、職務の一部です。個人がプロジェクトのコントリビューターであり積極的なレビュアーであれば、エンジニアリングプロジェクトのうち製品の一部と見なされるものはどれでも適切です。2022年8月1日から、メンテナーシップの時間枠の期待については以下の表を使用します:

説明時間枠
中堅エンジニアメンテナーシップはオプション
既存のシニア以上のエンジニアまだメンテナーでない既存のシニア以上のエンジニアは、チームの生産性とモチベーションをサポートするためにトレーニープログラムを完了することが奨励されます。トレーニープログラムの完了予定期間はありません。
新規採用のシニア以上オンボーディング中に、新規採用のシニア以上のエンジニアはレビュアーではなくトレーニーメンテナーになるよう依頼されます。オンボーディング完了から12ヶ月以内にメンテナーシップが完了することを期待します。
シニアへの昇進シニアの役割に移行するエンジニアには、昇進前にすでにメンテナーになっていることを期待します。

レビュアー/メンテナーとの出会い

コードをレビューする人に慣れていると、コミュニケーションが容易になります。コーヒーチャットなどの機会を活用してレビュアーと知り合い、将来のコミュニケーションを促進してください。

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

これは特にバックエンド、フロントエンド、データベースのメンテナーに適用されます。他のエリア（docs など）には以下に記載されている別のプロセスがある場合があります。

メンテナーシップを考慮する前に、まずコントリビューターになるべきです。トレーニーメンテナープロセスでレビュアーになる前に、プロジェクトに少なくともいくつかの機能またはメンテナンスのコントリビューションをしておく必要があります。これらのコントリビューションは、プロジェクト固有のドメインと設計を理解するのに十分な複雑さを持つ必要があります。

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

関心を持つレビュアーは、メンテナーシップへの進捗を話し合い、例えば1対1の際に最近の詳細なレビューをレビューするために、マネージャー/メンターと定期的にチェックインするべきです。レビュアーはまた、レビューへのさらなる視点のためにメンテナーメンターを探すことも奨励されます。レビュアーは「正当化される限りいつでもメンテナーになる準備ができている」という観点でメンテナーへの資格を考えることが奨励されます。

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

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

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

メンテナーシップのノミネートプロセス

マネージャー/メンターはいつでもマージリクエストを開いてレビュアーをメンテナーとして追加することができます。このマージリクエストには、レビュアーがなぜメンテナーになるべきかのマネージャー/メンターからの正当化を含める必要があります。このマージリクエストをいつでも自分で開くことも歓迎されます。内容と手順を助けるための MR テンプレートがあります。

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

MR を開く前に、作者は以下を行う必要があります:

  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. エンジニアリング週次レビュードキュメントにアップデートを投稿します。アジェンダは社内のみです。Google Drive で ‘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 で発表し、エンジニアリング週次レビュードキュメントにアップデートを投稿する

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

design.gitlab.com または gitlab-svgs

  • メンテナーになる方法を理解する。
  • すべてのデザイナーは gitlab-design プロジェクトのメンテナーです。gitlab と gitlab-ui プロジェクトの UI（.scss）のメンテナーになることに興味がある場合は、エンジニアリングレビューワークフローに従ってください。
  • 十分な MR をレビューするためのものを確保し、様々な種類のものを確保するのはあなた次第です。例えば #ux や #pajamas-design-system Slack チャンネルでのレビューをチームに依頼することもできます。トレーニングを進めるための十分な MR を受け取れていない場合は、積極的に Pajamas への改善に取り組んでください。これにより製品の全体的な理解と質の高いコントリビューションが実証され、進捗を後押しします。メンテナーはガイドするために利用可能です。
  • レビューはメンテナーの責任だけでなくレビュアーの責任もカバーすることを目指してください。デザインメンテナーは使いやすさに影響を与え、既存のユーザーエクスペリエンスを改善し、デザインガイドライン、標準、パターンの使用を含む 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 をマネージャーに割り当ててマージしてもらいます。

各レビュー後、レビュアーはなぜマージリクエストがマージの準備ができていると思うかをまとめる必要があります:

例えば:

Looks good! I believe this MR resolves the issue and it looks safe because the code change is relatively isolated.

LGTM! I feel this MR is a good iteration. And it has low risk because it is behind a feature flag.

メンテナーはレビュアーのコメントに対して 👍 で同意した場合応答し、マージする際に初回レビューで捕捉すべきだった追加コメントがあった場合はすべてのレビュアーにピングして認識させる必要があります。

進捗を追跡することが役立つと感じるレビュアーもいます。これは必須ではありませんが、人々が行ったいくつかの方法を以下に示します:

メンテナーになった後

新しいメンテナーになった場合は、役割を果たすことができる関連する権限をリクエストするためにこれらの指示に従ってください:

  • Slack のメンテナーのグループチャンネルに参加する: #frontend_maintainers、#backend_maintainers など。
  • グループのメンテナーに存在する場合はメンテナー固有のミーティングに招待してもらう。
  • 所属するメンテナーグループへのアクセスをリクエストする: フロントエンド、バックエンド、またはデータベース。
  • シングルパーソンアクセスリクエスト 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 コードベースの所有権において能力と自信が向上します。
レビュアー/メンテナーの移行

マネージャーとの相談後、レビュアー/メンテナーから移行する必要がある場合があります。どのような状況であっても、これは完全に問題ありません！責任とワークロードは変わります。プロジェクトも進化します。したがって、最も重要なエリアに時間を費やすことが重要です。レビュアールーレットから削除されるために変更を公式にするには:

  1. YAML ファイルの更新方法についてはチームメンバーデータベースドキュメントを参照してください。
  2. 新しい MR を作成し、MR をマネージャーに割り当てます。
レビュアー/メンテナーへの復帰

レビュアー/メンテナーからの移行期間後、これらの職務を再開したい場合があります。リクエストを公式にするには、プロジェクトメンテナーになる方法のセクションを参照し、トラッキング Issue とマージリクエストを作成して、コンテキストとして以前のトラッキング Issue とマージリクエストを参照してください。新しく作成されたマージリクエストは、プロセスを通常高速化できるため即時レビューのためにマネージャーに割り当てる必要があります。

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

これは特定のグループに属するプロジェクトや社内コントリビューターが10人未満のプロジェクトがメンテナーシッププロセスを定義・文書化するために使用できる汎用テンプレートです。

プロジェクトはこれらのガイドラインを採用して、メンテナーが十分でないプロジェクトでメンテナーを育成することができます。

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

小規模プロジェクトの加速されたメンテナーオンボーディング

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

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

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

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

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

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

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

メンテナー比率

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

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

メンテナーの需要

メンテナーシップ需要ダッシュボードを見ることで需要を測定できます。月、プロジェクト、技術でフィルタリングできます:

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

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

メトリクスの定義:

  • 受信マージリクエスト - 任意の作者によって開かれた MR の総数。
  • 平均可用性 - メンテナーがレビューを受け入れており、忙しくなく、休暇中でも、容量いっぱいでもない時間の平均割合。
  • 総メンテナー数 - team.yml に maintainer が指定されているエンジニアの数。
  • 利用可能なメンテナー数 - 総メンテナー数に平均可用性を掛けた数。
  • 月次レビュー目標 - 特定の月に各メンテナーが期待するレビュー数に基づく変動数。月次レビュー目標はエリアによって異なるか、受信マージリクエスト数に基づいて一般的に定義されます。このメトリクスの詳細については以下をお読みください。
  • ターゲットメンテナー数 - そのエリアのその月の受信マージリクエスト数、現在の総メンテナー数、平均可用性に基づいて月ごとに変動する数。
  • 最低必要メンテナー数 - 受信マージリクエストの需要を満たすために必要な利用可能なメンテナー数。
  • 必要なメンテナー数 - 最低必要メンテナー数を満たすために依然として必要な利用可能なメンテナー数。
  • 技術グループ - データベース、バックエンド、フロントエンド、CI テンプレート、Workhorse のようなメンテナー固有の専門分野を持つプロジェクト向け

グラフの説明:

  • 利用可能なメンテナー VS 需要 - メンテナーのターゲット、合計、可用性の全体的な高レベルの概観。
  • メンテナーが必要なプロジェクト - 前月のデータに基づき、より多くの利用可能なメンテナーが必要と予測されるエリアの出力。
  • プロジェクト/エリアのメンテナーシップ健全性 - 最低必要メンテナー数を満たしていないプロジェクト（GitLab）またはエリア（バックエンド）の割合の経時変化。
  • 不健全なメンテナーシップ健全性のコアエリア - 最低必要メンテナー数を満たしておらず、月あたり100件以上の受信マージリクエストを受け取っているプロジェクト（GitLab）またはエリア（バックエンド）の割合の経時変化。
  • 製品リポジトリの一部 - フル データ - 上記のすべてのメトリクスを含む各プロジェクト、エリア、月の完全なグラフ。

月次レビュー目標

ターゲットは利用可能なメンテナー数（上述）と1ヶ月に「合理的な」レビュー数に基づいて計算されます。「合理的な」は個別分析 Issue でいくつかのエリアに対して定義されています。これらは “maintainer_custom_targets” Sisense スニペットで定義されたカスタムターゲットです。他のすべてのプロジェクトにはプロジェクトへの受信マージリクエスト数に基づく一般ターゲットがあります。これらの数値は最初のイテレーションであり、分析 Issue に基づいていました。要求の少ないプロジェクトはメンテナー数が少なく（したがって1人あたり月次レビューが多く必要）、要求の多いプロジェクトはメンテナー数が多い（したがって1人あたり月次レビューが少ない）:

  • デフォルトのターゲットはメンテナーあたり5件のレビュー
  • エリアが10件以上のマージリクエストを受け取る場合、月次ターゲットはメンテナーあたり10件のレビュー
  • エリアが500件以上のマージリクエストを受け取る場合、月次ターゲットはメンテナーあたり40件のレビュー
  • エリアが1000件以上のマージリクエストを受け取る場合、月次ターゲットはメンテナーあたり16件のレビュー
  • エリアが1500件以上のマージリクエストを受け取る場合、月次ターゲットはメンテナーあたり20件のレビュー

maintainer_custom_targets Sisense スニペットを使用してエリアにカスタムターゲットを追加するには:

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

注意事項

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

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

タイムゾーン全体で、MR をタイムリーにレビューできる人がいることを確保しつつ、レビューの負荷を合理的なレベルに保つために、十分なレビュアーとメンテナーを持つことを目指しています。これは レビュアー/メンテナー可用性とキャパシティダッシュボードで追跡しています:

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

リーディングオーガニゼーション

すべての広いコミュニティメンバーとその組織はコントリビュートできます。私たちは、GitLab などのオープンソースへのコントリビューションが組織とそのメンバーにとって競争上の優位性であると強く信じており、それを行う組織を表彰したいと考えています。GitLab は頻繁かつ原子的なイテレーションでコントリビュートする人々を奨励、称賛、報酬します。組織または関係のない個人が過去3ヶ月間で20件以上のマージリクエストをマージした場合、その組織または個人を Leading Organization と見なします。

組織はプロフィールの Organization フィールドに基づいてマッチングされます。GitLab はコントリビューター成功チームが利用可能なその他のメタデータを使用して個人を組織にマッチングすることもあります。あなたまたはあなたの組織が該当するが Leading Organization ラベルをマージリクエストで受け取っていない場合は、コントリビューター成功キューで Issue を作成してください。

Leading Organization はレビューレスポンス SLO の権利が与えられます。この権利は各月の始めに付与されます。組織が Leading Organization のステータスを持つ間に作成されたマージリクエストは Leading Organization ラベルを受け取ります。

Leading Organization = 過去3ヶ月間で20件以上のマージ済みマージリクエスト

対象のマージリクエストには GitLab 製品とドキュメントへのコントリビューションが含まれます。www-gitlab-com リポジトリ（例えば GitLab ハンドブック）へのコントリビューションは現在含まれておらず、レビューレスポンス SLO の権利が与えられていません。

ドメインエキスパート

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

ドメインエキスパートとは何か？

現在、チームメンバーをドメインエキスパートとして認定するための厳格なルールは提供しておらず、代わりに暗黙的かつ自己識別というシンプルな解決策を使用しています。

暗黙的:

  • 特定のステージ/グループ（例: Create: Source Code）に取り組むチームメンバーは、そのエリアのアプリに対して暗黙的にドメインエキスパートと見なされます。
  • 特定の機能（例: search）に取り組むチームメンバーは、その機能に対して暗黙的にドメインエキスパートと見なされます。

自己識別:

  • チームメンバーは特定の機能（例: file uploads）のドメインエキスパートとして自己識別できます。
  • チームメンバーは特定の技術（例: GraphQL）、製品機能（例: file uploads）、またはコードベースのエリア（例: 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 の値はマージリクエストの作者によって異なります:

Review-response SLO の時間枠内にマージリクエストをレビューできないと思う場合は、できるだけ早く（最初のレビューリクエストを受け取ってから36時間以内に）コメントで作者に知らせ、別のレビュアーまたはメンテナーを見つける手助けをして、彼らが迅速にブロック解除されて作業を続けられるようにしてください。レビュアーとしての自分を削除してください。

レビュアーはいくつかの他の絵文字を通じてステータスをコミュニケーションすることもできます。これらの他のステータスの詳細については、開発者ドキュメントのコードレビューページを参照してください。

もちろん、休暇中で GitLab.com のステータスでそれをコミュニケーションしている場合は、作者はこれを把握して自分で別のレビュアーを探すことが期待されます。

マージリクエストの作者が Review-response SLO より長くブロックされている場合は、Slack を通じてレビュアーに知らせるか、別のレビュアーを追加することができます。

期待の管理

レビューに割り当てられており Review-response SLO 内に対応できない場合は、遅延した応答を作者に知らせる MR へのコメントを残してください。可能であれば、作者がフィードバックを期待できる時期や代替レビュアーを見つける手助けを示してください。

MR の作者として、Review-response SLO が満たされていないかつ担当者に連絡できない場合は、別のレビュアーまたはメンテナーに再割り当てしてください。

コードオーナーの承認

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

CODEOWNERS ファイル自体のコードオーナーはファイル内のルールで管理されています。例えば:

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

CODEOWNERS ファイルのコードオーナーを更新する2つの方法があります:

  1. 標準アクセスリクエストプロセスを通じて CODEOWNERS 変更を承認する能力がすでにあるグループのメンバーシップを更新する。
  2. 関連する行を更新するマージリクエストを開く。既存のコードオーナーがマージリクエストを承認する必要があります。また、セキュリティコンプライアンスチームメンバーに可視性のためにピングすることが奨励されます。

@gitlab-org/development-leaders グループは、エンジニアリング内の開発部門の管理職トラックのシニアマネージャー以上と個人コントリビュータートラックのディスティングイッシュドエンジニア以上のチームメンバーで構成されています。

最終更新 May 6, 2026: Merge pull request #100 from kyama0/fix/upload-images-tolerate-upstream-missing (70970e1a)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License