Create:Code Review グループ

Create:Code Review グループは、DevOps ライフサイクルの Create ステージの Code Review グループに属するプロダクトカテゴリのすべての側面を担当しています。

グループ概要

グループメンバー

以下の方々が Create:Code Review グループの常設メンバーです:

チームメンバー情報は 原文 (英語) を参照してください。

サブ部門固有のページ

• バックエンド
• フロントエンド

プロダクトカテゴリ

Code Review グループは以下のプロダクトカテゴリを担当しています:

• コードレビュー
• GitLab CLI

カテゴリパフォーマンス指標

• コードレビューカテゴリ MAU（内部のみ）
• Editor Extension カテゴリ MAU（内部のみ）

作業

作業方法

一般的に、私たちは標準の GitLab エンジニアリングワークフローを使用しています。Create:Code Review チームに連絡するには、関連プロジェクト（通常は GitLab）に Issue を作成し、~"group::code review" ラベルと他の適切なラベル（~devops::create、~section::dev）を追加するのが最善です。その後、上記のリストの関連するプロダクトマネージャーおよび/またはエンジニアリングマネージャーに自由に ping してください。

より緊急なアイテムには、Slack の #g_create_code_review を使用してください。

カテゴリごとにサポートする機能はこちら。

ワークフローラベル

ワークフローラベルは 原文 (英語) を参照してください。

ミーティング

可能な限り、Issue、マージリクエスト、Slack を使用した非同期コミュニケーションを好みます。ただし、個人的なつながりを確立し、ブロッカーなど同期的に議論した方が効率的なアイテムを対処するために、対面ミーティングは有用です。

ミーティングを録画し、GitLab Unfiltered の Create Code Review プレイリストにアップロードします。

Code Review 週次

これは Code Review グループのすべてのメンバーが現在の優先事項、ブロッカー、計画について話し合うための機会です。

このミーティングのアジェンダは事前に設定され、誰でもトピックを追加できます。ミーティング開始30分前にアジェンダにアイテムがない場合、ミーティングはキャンセルします。

Code Review UX 同期

このミーティングは UX と PM 間のコラボレーションに重点を置いていますが、誰でも参加して貢献できます。

非同期スタンドアップ

チームメンバーが2番目の質問に関連して言及された場合、成果物の Issue またはマージリクエストへのリンクを投稿することを奨励します。これにより他のチームメンバーが他の人が何に取り組んでいるかを理解でき、将来的に同様のものに遭遇した場合に良い参照ポイントを持てます。

振り返り

1つの定期的な「マイルストーンごと」の振り返りと、特定のケースの分析、通常はイテレーションアプローチを見ることに重点を置いたアドホックな「機能ごと」の振り返りを行います。

マイルストーンごと

レトロスペクティブは 原文 (英語) を参照してください。

プロジェクトごと

特定の Issue、機能、または他の種類のプロジェクトが特に有益な学習体験になった場合、それから学ぶために同期または非同期の振り返りを行うことがあります。取り組んでいるものが振り返りに値すると感じる場合:

1. 振り返りを行いたい理由を説明し、同期か非同期かを示す Issue を作成する
2. EM と関与すべき他の人（PM、カウンターパートなど）を含める
3. 同期ミーティングを調整する（該当する場合）

振り返りからのすべてのフィードバックは、参照のために最終的に Issue に記録される必要があります。

コラボレーション

プロダクトとの協力

プロダクトマネージャーとエンジニアリングマネージャー（フロントエンドとバックエンド）間の週次コールは「Code Review グループ」カレンダーに記載されています。誰でも参加でき、これらのコールはグループに影響する障害、懸念事項、ステータス更新、成果物、またはその他の考えを議論するために使用されます。月次コールも同じカレンダーで行われ、グループ全体が参加することが奨励されています。達成・改善を強調し、将来のイテレーションについて議論し、振り返りの懸念事項とアクションアイテムを確認し、グループに影響するその他の一般的なアイテムについても話し合います。

他のカウンターパートとのコラボレーション

PM 以外の安定したカウンターパートと必要に応じて密接に協力することが奨励されます。私たちは特に、リリースキックオフ前、コードレビューや Issue の懸念事項中に必要に応じて、品質エンジニアリングとアプリケーションセキュリティのカウンターパートを参加させています。

品質エンジニアリングは Quad Planning プロセスを通じてワークフローに参加しています。

アプリケーションセキュリティは、チームにキックオフメールが送信されるのと同じタイミングでワークフローに参加し、今後のマイルストーンの作業を確認し、私たちが認識すべき懸念事項や潜在的なリスクを記録できるようにしています。

GitLab より広いコミュニティとの協力

私たちは非常に大きな機能セットをサポートしているため、チームはしばしば GitLab のより広いコミュニティからのコミュニティ貢献をレビューします。各コントリビューターに私たちの「ホワイトグローブ対応」を提供することが奨励されます。寄贈された時間への認識を示し、非常に役立つレビューを行い、貢献を励ますことはすべてコミュニティ意識を築く優れた方法です。レビューや提案への ping に応答する時間がない場合は、別の人に ping できるよう ping した人に素早く知らせてください。

ヘルプリクエスト（RFH）

Code Review グループはサポートチームによってオープンされたヘルプリクエスト（RFH）への対応に責任があります。 これらのリクエストは通常、顧客が直面している問題を解決するためのものです。

重要でないサポートリクエストが Slack 経由で届いた場合は、より良い透明性と効率的な追跡・解決のために、グループの RFH（テンプレートリンク）をオープンするよう報告者に案内してください。

RFH ワークフロー:

1. RFH プロジェクトに文書化された応答性とラベリングに関する共通のガイダンスに従う。
2. RFH Issue が作成されると、フロントエンドとバックエンドの EM が自動的に言及されます。EM は Issue を速やかにトリアージする必要があります。PM もトリアージのサポートができます。助けになれると思うエンジニアは自発的に自分自身を割り当てることができます。
3. Issue のトリアージ:
   1. Issue 作成者に明確化のための質問をする。
   2. gitlab-org/gitlab にある関連するオープンまたはクローズ済みの Issue を特定する。
   3. ドメインの専門知識および/または可用性に基づいて、チームのメンバーに RFH Issue を割り当てる。
4. EM は RFH ライフサイクルボード または EM ダッシュボードを通じて、オープン RFH Issue のステータスを定期的に確認します。
5. RFH Issue の担当者は、ブロッカーが生じたらすぐに表面化させる必要があります。
6. RFH が一般的な質問やドキュメントのギャップを明らかにした場合、将来の同様の問い合わせを防ぐために関連するハンドブックページやドキュメントの更新を検討してください。

成功のメトリクス

Code Review カテゴリの成功を測定するメトリクスは、コードレビューの目標、具体的には使いやすさ、愛されやすさ、効率性と整合しています。

主要メトリクス

私たちの_主要_メトリクスは: コードレビューの期間を短縮することです。これは最初のマージリクエストバージョンからマージまでの期間として測定されます。

MTTM はこのダッシュボードで確認できます。

二次メトリクス

_二次_メトリクスは主要メトリクスのサポートとして機能し、カテゴリがどれほど成功しているかについてより完全な絵を構築するのに役立ちます。

時折、様々なヒューリスティクスを通じてユーザー体験を追跡するために UX スコアカードを実施します — コードレビューのすべての UX スコアカードを見る。Create ステージレベルでは、ユーザビリティベンチマーキングスタディを実施します。

現在、知覚パフォーマンスの測定と改善に注力しています: 「ウェブサイトがユーザーにとってどれほど高速で、応答性が高く、信頼性があると感じるか。サイトのパフォーマンスに対する認識は、実際のロード時間と応答時間よりもユーザー体験に大きな影響を与える可能性があります。」知覚パフォーマンスは_技術的_パフォーマンス（つまりロード時間と応答時間）だけでなく、_ユーザー_パフォーマンス（つまりタスク完了の効率）も含み、以下のように定式化できます:

perceived performance = f(expected performance, UX, actual performance)
experience = f(perceived performance, task completion)

使用状況メトリクス

• ページビュー

探索と実験

Code Review グループは、チームメンバーが関心のあるプロダクト領域を探索・実験する権限を持つことが重要だと考えています。会話を始める最善の方法はマージリクエストからであることもあります。

時間を確保する

チームメンバーが関心のある領域を追求する機会をより適切に提供するため、エンジニアはスケジュールされたキャパシティの約10%を確保することが奨励されます。

期待の設定

これらの領域で作業したり新しいアイデアを探ったりする場合、全員が同じ認識を持てるようにいくつかの基本ルールがあります:

1. これらの領域での作業はマイルストーンの計画された成果物のコストとなってはいけません
2. これらの領域でのすべての努力がプロダクトにマージされるわけではありませんが、プロダクトとデザインと共有することで将来の作業の会話を方向付けるのに役立ちます
3. コードレビュー領域での作業は必要ないです; エンジニアは関心のある領域を探索することが奨励されます

インスピレーションの領域

どこから始めれば良いか分からないことがあるため、インスピレーションを求めるかもしれない場所のリストを提供します:

1. トップレベルのコードレビューエピック — このリストのエピックは重要度でおおよそソートされています
2. トップレベルの Editor Extension エピック — このリストのエピックは機能の全カテゴリを網羅していますが、グループは主に VS Code にのみ注力しています
3. グループレベルの gitlab-org Issue リスト — 関心のあるラベルでフィルタリングします
4. 開発の準備ができたコードレビューの Issue
5. パフォーマンスとパフォーマンスリファインメントの Issue
6. 簡単な勝利

ヒントとコツ

開発者向けドキュメントやハンドブックに追加するほど「準備が整っていない」ヒント、コツ、クイックシェルスクリプトには、Create ステージウィキを使用しています。

AI プロンプト

より効率的になるために使用する一般的な AI プロンプトのリストを維持しています。

マージリクエストレポートウィジェットの共同責任

マージリクエストのトピックはコードレビューに属しますが、マージリクエストレポートウィジェットを動かすコード（ワーキンググループを参照）はより大きなグループによって書かれ・維持されています。

これらのウィジェットに関するコミュニケーションとトラブルシューティングの目的で、DRI リストをご参照ください。

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