JiHu サポート

概要

ブログ記事 GitLab licensed its technology to new independent Chinese companyで発表したように、GitLab Inc. は技術を JiHu にライセンス供与しました。このページでは、GitLab Inc. チームが JiHu にサポートを提供する方法について説明します。

ブランド

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

コミュニケーション

ガイドラインを参照してください。GitLab チームメンバーに送られる gitlab-jh.slack.com Slack サーバーへの招待は正規のものです。このサーバーは GitLab Inc. と JiHu 間のコミュニケーションに使用されます。

セールス

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

GitLab の窓口

JiHu エンジニアリングのコンタクト

Shiyuan Chenは GitLab Inc. に対する JiHu エンジニアリングの窓口です。

プロジェクト

JiHu チームのプロジェクトは https://jihulab.com/gitlab-cn/ に配置されています。gitlab-org のツーリングおよびコンプライアンスチェック用のミラープロジェクトは https://gitlab.com/gitlab-org/gitlab-jh-mirrors/ で利用可能です。

JiHu プロジェクトのほとんどは JiHuLab.com に移動されましたが、一部のプロジェクトはまだ gitlab-jh グループの下にあります。

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

詳細は JiHu コントリビューションプロセスを参照してください。

JiHu main ブランチが壊れた場合の解決プロセス

main-jh ブランチが壊れていて、アップストリームのマージリクエストによる解決が必要になる場合があります。これが発生した場合、JiHu アップストリーム MR 作成から 2 営業日以内にタイムリーに解決するために、以下のプロセスが実施されます。

1. JiHu チームが解決策を含むアップストリーム MR をオープンする
2. JiHu エンジニアリング DRI が #main-jh-brokenでメッセージを投稿し、GitLab のメンテナーに MR がエスカレーションされたことを通知する
3. GitLab ファシリテーターがマージリクエストに ~"JiHu Broken Pipeline" ラベルを適用し、適切なドメイン（バックエンド、フロントエンド）からのレビューを依頼する
4. GitLab ファシリテーターが #jihu-engineering チャンネルで GitLab Inc のチームメンバーに通知する
5. JiHu が MR と失敗の根本原因を https://gitlab.com/gitlab-jh/gitlab-jh-enablement/-/issues/215 に追加する

JiHu 検証パイプラインが壊れたマージリクエスト

詳細は検証パイプラインが失敗したときの対処方法を確認してください。

セキュリティリリースプロセス

JiHu は、すべてのパッチおよびセキュリティリリースを含め、毎月 JiHu Edition をビルドおよびリリースする責任があります。セキュリティリリースについて、GitLab Inc. は引き続き既存のセキュリティリリースプロセスに従ってセキュリティリリースを公開します。JiHu がタイムリーにセキュリティリリースをビルドできるように、GitLab Inc. はセキュリティリリースが進行中の場合に JiHu に通知し、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 Application Security チームが、脆弱性の詳細や脆弱性の詳細の発見につながる可能性のある情報を開示しない限り、緩和手順を共有します。

• そのような緩和手順が存在する場合、GitLab Application Security チームは JiHu enablement プロジェクトに緩和手順を含む機密 Issue を作成して JiHu に通知します
• 緩和手順が存在しない場合、脆弱性は GitLab の通常のセキュリティ脆弱性開示プロセスに従って開示されます

セキュリティのベストプラクティス

GitLab は JiHu とセキュリティのベストプラクティスを共有することができます。これには、GitLab、JiHu、およびそれらの顧客を安全に保つことを目的として、多層防御策、ハードニング手法、その他の情報が含まれる場合があります。ただし、未修正の脆弱性または進行中のインシデントに関する情報を公開する可能性のある脆弱性の詳細や特定の修復策は含まれません。

コンサルティングプロセス

JiHu は GitLab の専門知識、特に GitLab を SaaS 製品として運用することに関する専門知識から恩恵を受けています。GitLab は、Slack での簡単な対応を超えるエンゲージメントを必要とする項目について JiHu にコンサルティング料金を請求することがあります。これにより、GitLab は予定外の作業から自分を守りつつ、JiHu がドメイン専門性を構築できるようにします。これは JiHu とのテクニカルサービス契約 - 社内でも合意されています。

コンサルティングの対象外のトピック

• MR のレビュー
• ロードマップの調整
• マネジメントの協業

プロダクト

プロダクト DRI の役割

プロダクト DRI は以下の責任を負います：

• JiHu の CTO およびプロダクトカウンターパートにプロダクトマネジメント実践のガイダンスを提供する
• GitLab プロダクトと JiHu プロダクトのアライメントを可能にする
  • 定期的に最新情報を提供し、GitLab の投資テーマとロードマップへの認識を高める
  • JiHu の計画とロードマップを適切な関係者に広める
• プロダクトデータについて JiHu CTO と連絡を取り合う
• JiHu または中国関連の要件に関連するソリューションを実装するために、ステージグループと協力する
• エンジニアリング DRI およびエンジニアリングファシリテーターと連携し、GitLab と JiHu の間の円滑な機能を確保するためのプロセスを定義および維持する

プロダクトマネージャーの責任

JiHu のコントリビューションは、コミュニティコントリビューションと類似しています。違いは、ボリュームと頻度が高いことです。JiHu が GitLab コードベースに習熟するにつれて、JiHu は GitLab にどこでどのようにコントリビュートできるかを理解し学ぼうとしています。プロダクトマネージャーは、公開されている方向性を共有し、JiHu チームと連携して JiHu が自給自足で効率的になれるよう支援できます。

時々、プロダクトマネージャーは JiHu からの具体的な提案に対するフィードバックを提供したり、直接対応したりするように求められます。GitLab の PM は GitLab のエンジニアと JiHu チームのコラボレーションを促進する支援を行うべきです。これは、プロダクトの方向性に不一致がある場合は、JiHu が GitLab がマージするつもりのないものに時間を費やすことのないように、早期に指摘することを意味します。

プロダクトマネージャーが JiHu のカウンターパートとの接続にヘルプを必要とする場合は、#jihu-productでプロダクト DRI にメンションしてください。

プロダクトデザイナーの責任

GitLab のプロダクトデザイナーは、レビューとガイダンスの責任を負いますが、JiHu がコントリビュートしたい Issue の完全なデザイン作業を引き受けるべきではありません。JiHu にはこれらの Issue を実装の準備が整うように手伝う独自のプロダクトデザインチームがあります。

プロセス

JiHu がアップストリームにコントリビュートしようとする Issue にプロダクトデザイナーがメンションされたら、プロダクトデザイナーは、その Issue に Pajamas ガイドライン、プロダクト原則、またはチームの計画作業と矛盾しない明確な提案がすでにあるかどうかを確認します。

明確なデザイン提案がまだない場合、または Pajamas やプロダクト原則と矛盾がある場合、デザイナーは Issue が実装に進む前に必要なものについてコメントを残します。

JiHu とのマイルストーン製品計画プロセス

コラボレーションとフィードバックを促進するため、JiHu は GitLab のマイルストーン計画プロセスに先行して計画し、GitLab プロダクトグループが実装前にフィードバックを提供する時間を確保します。毎マイルストーンで次のことが発生します：

1. JiHu は gitlab-jh-enablement プロジェクトでマイルストーン計画 Issue を作成します。これはこの例のようなものです。JiHu は通常、月の 18 日の 2 週間前に計画を提供します。
2. GitLab.org プロジェクトにすでに Issue がない項目については、JiHu チームが Issue を作成します。既存の Issue がある場合、それはマイルストーン計画 Issue からリンクされます。これにより、GitLab プロダクトグループは他の日々の作業が追跡されている同じ場所で JiHu のコントリビューションを追跡できます。
3. プロダクト DRI は JiHu マイルストーンレビューテンプレートを通じて、認識を促進しコラボレーションを奨励します
4. 個々のプロダクトマネージャーとそのエンジニアリングのカウンターパートは、必要に応じて JiHu にフィードバックを提供します

大規模プロダクトイニシアチブの計画

IP を作成することを目的として、JiHu は複数のマイルストーンにまたがる大規模なプロダクトイニシアチブを引き受けます。このタイプのプロダクトイニシアチブはより多くの調整を必要とします。JiHu と GitLab の代表者は、これらのプロダクト計画について定期的に同期を取ります。目標は大規模なイニシアチブを早期に特定し、適切な DRI をループに入れることです。このタイプのプロダクトイニシアチブの一例はパイプラインエディタの Visual Builderです。

プロダクトマネージャーが責任を負わないもの

GitLab のプロダクトマネージャーは JiHu のプロダクト判断に責任を負いませんが、JiHu のプロダクトマネージャーとのコラボレーションとフィードバックは推奨され歓迎されます。

• PM がコミュニティコントリビューションの裁定者ではないのと同様に、プロダクトマネージャーは JiHu チームが取り組むものの裁定者ではありません
• プロダクトマネージャーは、ティアや価格設定など、JiHu のプロダクト判断には責任を負いません
• JiHu のマイルストーン計画をレビューする際は：
  1. 自分のプロダクト領域における JiHu の計画を認識する
  2. GitLab のプロダクト方針に従ってガイダンスを提供する
  3. サプライズを避け、JiHu の成功を支援する。フィードバックに時間がかかる場合は、事前に知らせる
  4. 与えるべきフィードバックがなければ、フィードバックを提供する必要はない。JiHu のコントリビューションは他のコミュニティコントリビューションと同じであり得る

JiHu 独自機能の差別化

JiHu ディストリビューション向けの独自機能は、/jh ディレクトリに含めることで差別化します。ただし、JiHu チームメンバーからのコントリビューションの大部分は /jh ディレクトリの外側にあるべきであり、これは大部分のコントリビューションが GitLab Core 向けであり、特定の機能のみが /jh オファリング独自であるという期待を示しています。

リンク

• GitLab licensed its technology to new independent Chinese company
• GitLab licensing technology to independent Chinese company FAQ
• China Service Working Group

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