マージリクエスト体験における協業
背景
マージリクエスト (MR) は、GitLab におけるユーザー間のコラボレーションの中心点です。 ここでコードがレビューされ、パイプラインが実行され、テストおよびスキャンの結果が提供され、最終的にコントリビューションがマージされます。
MR 体験に対する変更は、たとえ小さな変更であっても、コードレビューの所要時間 に影響を与える可能性があります。コードレビュー時間の短縮は、Code Review グループの主要な成功指標 です。この指標は、GitLab のすべてのユーザーのコード品質と速度に影響します。
ここ Code Review グループ では、MR 体験を深く大切にしています。多くの他のグループも MR 体験に利害関係を持ちますが、私たちはその主要なコントリビューターです。長年にわたり、ガイダンスやビジョンなしに異なる関係者からなされたコントリビューションが、大量の技術的負債と先送りされた UX を生み出してきました。このページでは、「誰でもコントリビュートできる」精神を持続可能な形で MR 体験に反映させるための、待望のガイダンスを提供します。
MR 体験にコントリビュートしたいですか?
それは素晴らしいことです! 私たちは他のグループがコントリビュートしてくれるのを歓迎しています。このページの使い方を以下のステップで簡単に説明します:
- まだ読んでいない場合は、上記の 背景 セクションを読んでください。
- プロセスの導入 を読み、その後 はじめ方 を読んでください。
- あなたのグループが解決したい問題が、確立された コントリビューションフレームワーク と整合するかどうかを確認してください。
- もし整合するなら、それは素晴らしいことです! 確立されたフレームワークのプロセス に従ってください。
- 整合しなくても、心配しないでください。私たちがサポートします。確立されたフレームワークがない場合のプロセス に従ってください。
質問がある場合は #g_create_code-review で私たちに尋ねてください。
コントリビューションフレームワーク
MR 体験のいくつかの領域は、さまざまなグループからインパクトのある、あるいは頻繁にコントリビューションが寄せられる対象になっています。そうした領域には コントリビューションフレームワーク が必要です。これは、ユーザーおよび技術の両方の観点から、現在の体験と一貫性のあるソリューションを計画・設計・構築するためのガイドラインです。コントリビューションフレームワークは、高品質のユーザー体験を維持しながら、技術的負債と先送りされた UX を減らし、協業コストを下げ、速度を高めながら「誰でもコントリビュートできる」精神を実現します。
あなたのグループが行おうとしているコントリビューションのタイプに応じて、Code Review グループとさまざまな確認や情報の調整が必要になることがあります。これは、私たちがコントリビュートできる/できないものの判定者になることを意図するものではなく、GitLab 体験の中核領域における広範な整合性を確保するためのものです。
コントリビューションフレームワークの必要性を私たちが特定した、最も重複の多い領域は以下のとおりです:
コントリビューションフレームワークの必要性
あなたのグループが取り組もうとしている問題と解決策が、将来的に進化・拡張され、他のグループにも活用される可能性がある場合、コントリビューションフレームワークが必要になることがあります。これは、確立されたフレームワークが存在しない 場合に該当することがあります。Code Review グループは、新しいコントリビューションフレームワークを開始する上で役立つ決定を下すために、開発フロー全体を通してあなたのグループと協業します。新しいフレームワークには 複合的な効果 があります: あなたのグループはより良く仕事ができ、私たちはより良く協業でき、他のグループ (あなたのグループ自身を含む) も将来そのフレームワークを使って皆の成果の上に積み上げていけます。Win-Win の 2 乗です!
プロセス
以下の責任分担マトリクスは RACI モデル (Responsible、Accountable、Consulted、Informed) を使用しており、私たちの 製品開発フロー のフェーズにマッピングされます。各フェーズには、プロダクトデザイナーのような重要な参加者がいますが、簡潔さのために責任を負うグループのみを示しています。
- Responsible: フェーズを完了するための活動を実施する。活動に対して責任を負う具体的な役割は 製品開発フロー に定義されています。
- Accountable: 活動の成果を承認する。フェーズの正確かつ徹底的な完了に対して最終的な責任を負います。
- Consulted: 主題の専門家として、あるいは作業の影響を受ける立場として、活動に入力を提供する。双方向のコミュニケーションがあります。
- Informed: すべての活動の詳細に巻き込むのではなく、進捗を常に把握しておく必要がある。一方向のコミュニケーションのみです。
はじめ方
すべてのコントリビューションは、Validation backlog および Problem validation フェーズから始まります。これらのフェーズでは、Code Review グループは今後の検証活動について Informed であるべきで、Problem validation 中は Consulted であるべきです。これらは、私たちと協業し、MR がその問題を解決するのに最適な場所であるかどうかを確認するための重要な機会です。
| フェーズ | あなたのグループ | Code Review グループ | 説明 |
|---|---|---|---|
| Validation backlog | R,A | I | 問題が MR 体験で解決する価値があるかどうかを判断するには早すぎるため、あなたのグループは Responsible および Accountable として適切な裁量を持ちます。ただし、あなたのグループが MR 体験 が 当該問題に対処する正しい手段 かもしれない と 仮定する 場合には、私たちは Informed であることを求めます。つまり一方向のコミュニケーションです。 |
| Problem validation | R,A | C | 私たちは Consulted であり、既存の調査や類似の問題などを案内できます。私たちがこのフェーズを大切にするのは、潜在的なソリューションによって MR 体験のどれだけの部分が影響を受けるかに影響を与えられる機会だからです。あなたのグループは Problem validation に入る際にバイアスを持っており、MR がソリューションを置く場所だと仮定する可能性があり、これが検証結果を歪める恐れがあります。 |
このフェーズの終わりに、私たちはあなたのグループと協力して、あなたの進む道が 確立されたフレームワーク に合うのか、確立されたフレームワークが存在しない のかを判断します。
確立されたフレームワーク
あなたのグループが解決したい問題が、確立された コントリビューションフレームワーク に整合する場合。これらのケースでは協業オーバーヘッドを最小限に保ち、あなたのグループがほとんどのフェーズで Accountable になります。Code Review グループは Design および Develop & Test フェーズでのみ Consulted となり、あなたのグループがフレームワークを最大限活用できるよう支援します。
製品開発フローの最中または後で、あなたのグループは学びや変更を確立されたコントリビューションフレームワークに還元する Responsible を持ちます。私たちはこれらの変更を承認し、将来のコントリビューターが持続可能に活用できることを確保します。
| フェーズ | あなたのグループ | Code Review グループ |
|---|---|---|
| Design | R,A | C |
| Solution validation | R,A | I |
| Plan | R,A | I |
| Develop & Test | R,A | C |
| Launch | R,A | I |
| Improve | R,A | I |
| 確立されたコントリビューションフレームワークへの還元 | R | A |
確立されたフレームワークなし
あなたのグループが解決したい問題が、確立された コントリビューションフレームワーク に 整合しない 場合、それで構いません。すべての問題がコントリビューションフレームワークに沿うわけではなく、必要なわけでもありません。ただしこのようなケースでは、Code Review グループはあなたのグループの作業においてより多く Consulted および Accountable である必要があります。
これは協業オーバーヘッドを少し増やしますが、必要な場合もあります。ただし多くの場合、コントリビューションフレームワークによって緩和できます。だからこそ私たちは (あなたのグループと Code Review が一緒に) コントリビューションフレームワークの必要性 について議論します。
| フェーズ | あなたのグループ | Code Review グループ | 説明 |
|---|---|---|---|
| Design | R | A | あなたのグループはこのフェーズで必要な作業を行う Responsible ですが、私たちは成果に対して Accountable です。つまり成果を承認します。これは、私たちが最終的に、ユーザー だけでなく、変更によって影響を受けたり将来それを活用したい 他のコントリビューター にとっても、一貫性のある MR 体験に責任を負っているからです。 |
| Solution validation | R | A | 前のフェーズと同じです。 |
| Plan | R,A | C | 私たちはあなたのグループが物事を分解し、他のグループとの調整を行うのを支援します (例えば、別のグループが同時に「競合する」変更を入れている可能性があります)。 |
| Develop & Test | R | A | Design フェーズと同様に、私たちは 開発者 体験にも責任を負っているため、このフェーズでも Accountable です。これは、私たちが「ドメインエキスパート を持つメンテナーへの要請をデフォルトにする」ためです (コードレビューガイドライン より)。 |
| Launch | R,A | I | |
| Improve | R,A | I | |
| (オプション) 新しいコントリビューションフレームワークの開始 | R | A | 製品開発フローの最中または後で、新しいコントリビューションフレームワークが必要な場合、あなたのグループはそれを開始する Responsible を持ちます。私たちはフレームワークを承認し、将来のコントリビューターが持続可能に活用できることを確保します。 |
c955a93f)