JiHu コントリビューションプロセス

JiHu チームからのコントリビューションは、JiHu 独自の変更があるかどうかに応じて2つの方法で行われます。

  • アップストリーム方式 - GitLab Inc. リポジトリへのマージリクエストから開始する。
  • 独自仕様とアップストリーム混在方式 - すべての変更を GitLab JiHu プロジェクトに対するマージリクエストで開始し、独自仕様以外の変更をアップストリームプロジェクトに対するマージリクエストで行う。

JiHu からのコントリビューションを識別するため、JiHu チームからのすべてのアップストリームコントリビューションには ~"JiHu contribution" ラベルが自動的に付与されます。ラベルが正確に適用されるよう、gitlab-jh チームは gitlab-jh/jh-team のダイレクトメンバーを現在のチームメンバーで常に最新の状態に保つ必要があります。

JiHu enablement の効率性エージングとレビュー指標は、このダッシュボードで公開されています。

エンジニアリング生産性チームは JiHu エンジニアリング enablement 効率ツールと指標の DRI です。

アップストリームコントリビューションのガイドライン

JiHu 独自のコンテンツを含まないコントリビューションは、アップストリームプロジェクトに対して作成されます。

graph LR
  mr-->|アップストリームプロジェクトに対して作成|repo
  mr[/アップストリーム MR/]
  repo(GitLab Inc. リポジトリ)

アップストリーム機能コントリビューションのガイドライン

複数の MR が必要な大規模イニシアチブや広範な影響を持つイニシアチブの場合、事前の合同計画があると、アップストリーム機能コントリビューションはより効率的かつ予測可能になります。両チームが成功できるよう、以下のガイドラインに従う必要があります：

  1. 実装開始マイルストーンの少なくとも1マイルストーン前 - JiHu チームが英語で機能スコープの概要、使用目的、反復的な実装計画を提供するアップストリーム機能計画 Issue を作成する。JiHu は関連チームの PM、プロダクトデザイナー、EM に Issue と実装計画についてのフィードバックを求める。
    • 関連する GitLab プロダクトグループが機能、関連する反復的な実装計画についてフィードバックを提供し、JiHu にフィードバックを返す。
  2. 実装開始時 - JiHu チームが実装計画と以下のアップストリームガイドラインに従って MR を作成する。レビューは機能計画 Issue での合意に基づいて行われる。

アップストリーム計画 Issue の例：TBD

反復的なコントリビューションのガイドライン

大きなプロダクト機能のコントリビューションは、GitLab のイテレーション戦略に従う必要があります。

イテレーショントレーニングは、GitLab のイテレーションという価値観についてのコーチングに利用できます。これは GitLab プロダクトチームが機能のイテレーションに期待することを理解するのに役立ちます。

すべての機能が同じ戦略に従えるわけではありませんが、最初に試みる戦略は最小限の価値ある変更の作成であり、マージリクエストの作成においては常にマージリクエストを小さく保つことを心がけるべきです。

マージリクエストを小さく保つ上記のガイドラインで言及されているのは：

  • 水平スライシング
  • 垂直スライシング

JiHu のアップストリームコントリビューションは、開発者権限の不足から水平スライシングが難しいため、まず垂直にスライスする（つまり機能のスコープを縮小する）ことを常に試みてください。1つのマージリクエストに収まりきらないほど大きい場合にのみ、水平スライシングを検討してください。

機能を複数のイテレーションに分解する方法の例（水平・垂直どちらも）：

機能マージリクエスト（網羅的なリストではない）スライシング
GitLab Insightsベース部分は水平、その上は垂直の混在
状態による検索結果フィルタリング各 MR がスタンドアロン機能を提供する垂直スライシング

独自仕様とアップストリーム混在コントリビューションのガイドライン

独自仕様とアップストリームコントリビューションを持つプロジェクトへのコントリビューションは、効率的なレビューのために以下のガイドラインを使用します。

  1. JiHu エンジニアリングチームが2つの MR を作成する：
    1. JiHu プロジェクトのデフォルトブランチに対して、すべての変更を含む JiHu MR。
    2. GitLab Inc プロジェクトのデフォルトブランチに対して、jh/ 以外のすべての変更を含む GitLab Inc MR。
  2. GitLab Inc MR は GitLab Inc チームメンバーがレビューする。レビュアーはJiHu (JH) エディション関連マージリクエストのレビューガイドラインに従う必要がある。
  3. マージ後、プルミラーリング経由で更新が JiHu プロジェクトにミラーリングされ、code sync によって JiHu プロジェクトのデフォルトブランチ main-jh にマージされる。
  4. JiHu エンジニアリングチームが JiHu MR から jh/ 以外のすべての変更を削除する。
  5. JiHu エンジニアリングチームが JiHu プロジェクトで JiHu MR をレビューしてマージする。
  6. 2時間ごとのスケジュールパイプラインが compliance-verification で JiHu プロジェクトのプルミラー に対して実行され、package.json と yarn.lock の合意済みの差異を除いて jh/ ディレクトリ外にコードの差異がないことを検証する。

GitLab JiHu MR プロセスの図

JiHu コントリビューションの識別

JiHu チームメンバーからのコントリビューションは、以下によって JiHu contribution ラベルが付与されます：

マージリクエストレビュープロセス

  1. JiHu 作者がドラフト状態でアップストリームマージリクエストを提出する
  2. JiHu 作者のマネージャーがマージリクエストの説明でメンションされる
  3. JiHu チームがピアレビューを実施する
  4. JiHu チームのピアレビューが完了したら、JiHu R&D マネージャーまたはメンテナーが MR に LGTM または Looks good コメントを追加する
  5. マージリクエストが JiHu チームによって「準備完了」状態に設定される
  6. JiHu 作者が @gitlab-bot request_review を使ってレビューをリクエストし、マージリクエストコーチと協力して MR のマージを進める
  7. MR は以下を含む文書化されたレビュープロセスを経る：
    1. ドメイン専門家によるコードレビュー
    2. 特定のコードファイルのオーナーからのレビュー。JiHu マージリクエスト作者は MR 承認ウィジェットの必要な承認リストからチームメンバーをメンションする責任がある。現在以下のエリアが対象：
      1. 認証関連コード
    3. GitLab セキュリティレビュー（自動的にトリガーされる）

必要な承認

アップストリームマージリクエストは、他のすべてのマージリクエストと同じレベルのレビューと承認が必要です：

アップストリームマージリクエストは、変更されたファイルに基づいて追加の特定チームレビューが必要な場合があります。影響度の高いコードは CODEOWNERS ルールと特定ファイルの必要な承認で識別されます。例えば、マージリクエストに認証や認可に関連する変更が含まれる場合、Manage:Authentication and Authorization チームメンバーの承認が必要です

レビュー対象

  • jh/ 内の変更はレビューしない：
    • 特定の変更が JiHu にのみ必要な場合、JiHu プロジェクトリポジトリの jh/ ディレクトリに入れるべき。
  • jh/ ディレクトリ外の変更。例：

マージリクエストレビューのエスカレーション

ガイドラインをご参照ください。

リリース認定プロセス

アプリケーションセキュリティチームは JiHu のコントリビューションを含む各リリースの認定を実施します。このプロセスの詳細についてはこちらのドキュメントをご参照ください。

報告書を含む認定 Issue は、jh-upstream-report リポジトリの Issue トラッカーで確認できます。

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