JiHu コントリビューションプロセス
JiHu チームからのコントリビューションは、JiHu 独自の変更があるかどうかに応じて2つの方法で行われます。
アップストリーム方式 - GitLab Inc. リポジトリへのマージリクエストから開 …
JiHu サポート
GitLab Inc チームが JiHu をどのようにサポートするか
概要
ブログ記事GitLab が新しい独立系中国企業に技術をライセンス供与で発表されたように、GitLab Inc. は JiHu に技術をライセンス供与しています。このページでは、GitLab Inc. チームが JiHu にどのようなサポートを提供するかについて概説します。
ブランド
ガイドラインをご参照ください
コミュニケーション
ガイドラインをご参照ください。GitLab チームメンバーに送られる gitlab-jh.slack.com Slack サーバーへの招待は正当なものです。このサーバーは GitLab Inc. と JiHu 間のコミュニケーションに使用されます。
セールス
ガイドラインをご参照ください。
プロフェッショナルサービス
ガイドラインをご参照ください（リンクは後日追加予定）。
カスタマーサポート
プロセスは後日追加予定です。
エンジニアリング
R&D 役割
| DRI | 役割 |
|---|---|
| Jerome Ng | エンジニアリング DRI |
JiHu エンジニアリング担当者
Shiyuan Chen は GitLab Inc. に対する JiHu のエンジニアリング担当者です。GitLab Inc. が JiHu にも変更を求める変更を行う際、MAO が調整をサポートします。
プロジェクト
JiHu チームのプロジェクトは https://jihulab.com/gitlab-cn/ にあります。gitlab-org のツールおよびコンプライアンスチェック用のミラープロジェクトは https://gitlab.com/gitlab-org/gitlab-jh-mirrors/ で利用できます。
ほとんどの JiHu プロジェクトは JiHuLab.com に移行しましたが、一部のプロジェクトはまだ gitlab-jh グループ配下にあります。 アクセスをリクエストするには、Kevin または Mek にプロビジョニングを依頼してください。
JiHu コントリビューションプロセス
詳細については JiHu コントリビューションプロセスをご参照ください。
JiHu main ブランチの障害解消プロセス
main-jh ブランチが壊れ、解消のためにアップストリームのマージリクエストが必要になることがあります。この場合、JiHu がアップストリーム MR を作成してから2営業日以内に迅速に解消するため、以下のプロセスが実施されます。
- JiHu チームが解消策を含むアップストリーム MR を作成する
- JiHu エンジニアリング DRI が #main-jh-broken に GitLab Inc への通知メッセージを投稿して、MR が GitLab メンテナーにエスカレーションされていることを示す
- GitLab ファシリテーターがマージリクエストに
~"JiHu Broken Pipeline"ラベルを適用し、適切なドメイン（バックエンド、フロントエンド）にレビューを依頼する - GitLab ファシリテーターが #jihu-engineering チャンネルで GitLab Inc チームメンバーに通知する
- JiHu が https://gitlab.com/gitlab-jh/gitlab-jh-enablement/-/issues/215 に MR と障害の根本原因を追加する
JiHu バリデーションパイプラインが壊れているマージリクエスト
詳細についてはバリデーションパイプラインが失敗した場合の対処法をご確認ください。
セキュリティリリースプロセス
JiHu は毎月すべてのパッチリリースおよびセキュリティリリースを含む JiHu エディションのビルドとリリースに責任を持ちます。セキュリティリリースについては、GitLab Inc は既存のセキュリティリリースプロセスに従ってセキュリティリリースを公開し続けます。JiHu が適時にセキュリティリリースをビルドできるよう、GitLab Inc はセキュリティリリースの進行中に JiHu へ通知し、チームが待機できるようにします。GitLab Inc はセキュリティリリースの内容や脆弱性については JiHu に通知しません。
JiHu への予定されているセキュリティリリースの通知は、次の場所にコメントを投稿するだけで行えます：https://gitlab.com/gitlab-jh/gitlab-jh-enablement/-/issues/112
脆弱性開示プロセス
GitLab Inc は文書化された脆弱性開示プロセスに従い、脆弱性の詳細情報を JiHu に直接提供しません。進行中のセキュリティリリースの前または最中に情報を共有することはありません。
GitLab セキュリティリリースの後にのみ、GitLab Inc は JiHu に以下を提供する場合があります：
- 公開セキュリティリリースブログ記事へのリンク
- 脆弱性を説明する GitLab Issue へのリンク（脆弱性がパッチされたリリースから30日後まで機密扱い）
この情報は Slack および JiHu との週次エンジニアリング同期を通じて伝えられます。
JiHu のコントリビューションによって導入されたセキュリティ脆弱性については、GitLab アプリケーションセキュリティチームが、脆弱性の詳細や脆弱性の詳細につながる情報を開示しない限りにおいて、緩和策を共有します。
- そのような緩和策が存在する場合、GitLab アプリケーションセキュリティチームは JiHu enablement プロジェクトで緩和策を含む機密 Issue を作成することで JiHu に通知します。
- 緩和策が存在しない場合、GitLab の通常のセキュリティ脆弱性開示プロセスに従って脆弱性が開示されます。
セキュリティベストプラクティス
GitLab は JiHu とセキュリティベストプラクティスを共有できます。これには深層防御策、ハードニング技術、および GitLab、JiHu、それぞれの顧客を安全に保つための情報が含まれる場合があります。ただし、未パッチの脆弱性や進行中のインシデントに関する情報を暴露する可能性のある脆弱性の詳細や具体的な修正策は共有できません。
コンサルティングプロセス
JiHu は特に SaaS 製品として GitLab を運用することに関して GitLab の専門知識を活用します。GitLab は Slack 上の簡単な回答を超えるエンゲージメントを必要とするアイテムについてコンサルティングを JiHu に請求する場合があります。これにより、JiHu がドメインの専門知識を積む間、GitLab は計画外の作業から保護されます。これは GitLab の JiHu との技術サービス契約（内部）でも合意されています。
コンサルティングの対象外トピック
- MR のレビュー
- ロードマップの調整
- マネジメントのコラボレーション
プロダクト
プロダクト DRI の役割
プロダクト DRI には以下の責務があります：
- JiHu CTO およびプロダクト担当者にプロダクトマネジメントのプラクティスガイダンスを提供する
- GitLab プロダクトと JiHu プロダクト間の調整を実現する
- GitLab の投資テーマとロードマップの定期的な更新と認知向上を図る
- JiHu の計画とロードマップを適切な関係者に周知する
- プロダクトデータについて JiHu CTO と連携する
- JiHu または中国関連の要件に関するソリューションを実装するためにステージグループと協力する
- エンジニアリング DRI およびエンジニアリングファシリテーターとパートナーを組んで、GitLab と JiHu 間のスムーズな運営を確保するプロセスを定義・維持する
プロダクトマネージャーの責任
JiHu のコントリビューションはコミュニティコントリビューションに似ています。違いは量と頻度が多い点です。JiHu が GitLab コードベースに習熟するにつれ、どこでどのように GitLab にコントリビューションできるかについての理解を深め、学ぼうとしています。プロダクトマネージャーは公開方針を共有し、JiHu チームと協力して JiHu が自立して効率的に働けるよう支援できます。
プロダクトマネージャーは JiHu からの具体的な提案に対してフィードバックを提供したり直接回答したりするよう求められることがあります。GitLab の PM は GitLab エンジニアと JiHu チーム間のコラボレーションの促進を支援する必要があります。つまり、プロダクトの方向性に関して不一致がある場合、JiHu が GitLab がマージする予定のないものに時間を費やさないよう、早期にその点を指摘することを意味します。
プロダクトマネージャーが JiHu の担当者とのつながりが必要な場合は、#jihu-product でプロダクト DRI にピングしてください。
プロダクトデザイナーの責任
GitLab プロダクトデザイナーはレビューとガイダンスに責任を持ち、JiHu がコントリビューションしたい Issue の完全なデザイン作業を引き受けるべきではありません。JiHu には実装に向けてこれらの Issue を準備する独自のプロダクトデザインチームがいます。
プロセス
プロダクトデザイナーが JiHu がアップストリームにコントリビューションする予定の Issue にピングされた場合、そのプロダクトデザイナーは、その Issue にPajamas ガイドライン、プロダクト原則、またはチームの計画中の作業と矛盾しない明確な提案がすでにあるかどうかをレビューします。
明確なデザイン提案がない場合、または Pajamas やプロダクト原則との矛盾がある場合、デザイナーは実装に進む前に必要なことについてコメントを残します。
JiHu とのマイルストーン製品計画プロセス
コラボレーションとフィードバックを促進するため、JiHu は GitLab のマイルストーン計画プロセスより先行して計画し、GitLab のプロダクトグループが実装前にフィードバックを提供する時間を確保します。各マイルストーンで以下が実施されます：
- JiHu が gitlab-jh-enablement プロジェクトにマイルストーン計画 Issue を作成する（例）。JiHu は通常、18日の2週間前に計画を提供する
- GitLab.org プロジェクトに Issue がまだない項目については、JiHu チームが Issue を作成する。既存の Issue がある場合は、マイルストーン計画 Issue からリンクされる。これにより GitLab プロダクトグループは日常業務が追跡される同じ場所で JiHu のコントリビューションを追跡できる
- プロダクト DRI が JiHu マイルストーンレビューテンプレートを通じて認知を促進しコラボレーションを奨励する
- 個々のプロダクトマネージャーとそのエンジニアリング担当者が必要に応じて JiHu にフィードバックを提供する
大規模プロダクトイニシアチブの計画
IP 創出の観点から、JiHu は複数のマイルストーンにわたる大規模なプロダクトイニシアチブに取り組みます。この種のプロダクトイニシアチブはより多くの調整が必要です。JiHu と GitLab の担当者はこれらのプロダクト計画に関して定期的に連携しています。目標は大型イニシアチブを早期に特定し、適切な DRI が参加できるようにすることです。この種のプロダクトイニシアチブの一例としてパイプラインエディタ用ビジュアルビルダーがあります。
プロダクトマネージャーの責任外事項
GitLab のプロダクトマネージャーは JiHu のプロダクト上の意思決定に責任を持ちませんが、JiHu のプロダクトマネージャーとのコラボレーションとフィードバックは奨励されており歓迎されます。
- PM がコミュニティコントリビューションの仲裁者でないのと同様、プロダクトマネージャーは JiHu チームが何に取り組むかの仲裁者ではありません
- プロダクトマネージャーは JiHu のプロダクト上の意思決定（ティアリング、価格設定など）に責任を持ちません
- JiHu のマイルストーン計画をレビューする際：
- あなたのプロダクトエリアにおける JiHu の計画を把握する
- GitLab のプロダクト方向性に沿ったガイダンスを提供する
- サプライズを回避し、JiHu が成功できるよう支援する。フィードバックに時間がかかる場合は事前に知らせてください
- フィードバックがない場合は提供する必要はありません。JiHu のコントリビューションは他のコミュニティコントリビューションと同様に扱えます
JiHu 独自機能の区別
JiHu ディストリビューション向けの独自機能は /jh ディレクトリに含めることで区別しています。ただし、JiHu チームメンバーによるコントリビューションの大部分は /jh ディレクトリの外に置くべきであり、これはほとんどのコントリビューションが GitLab Core 向けであり、特定の機能のみが /jh オファリング専用であるという期待を示しています。
リンク
JiHu セキュリティレビュープロセス
JiHu コントリビューションのセキュリティレビュープロセス JiHu コントリビューションを含むリリースを認定できるようにするため、AppSec チームのメンバーはすべての JiHu コントリビュー …
JiHu バリデーションパイプライン
JiHu バリデーションパイプライン 通常の開発で JiHu のパイプラインを壊さないよう、JiHu のパイプラインを壊す可能性が高いと判断されたマージリクエストで JiHu バリデーションパイプライ …
データベース変更に関する JiHu ガイドライン
データベース変更に関する JiHu ガイドライン データベースマイグレーション（PostgreSQL 向け）を含む JiHu コントリビューションには、2つの方法を検討できます：
完全アップストリーム …
リリース認定
リリース認定プロセス JiHu コントリビューションを含むすべてのリリースは、Federal Application Security チームのメンバーが認定する必要があります。 …
