Translation MR レビューワークフロー
Tech Docs およびマーケティングサイトのワークフローをまたいで、翻訳マージリクエストの担当者・レビュアーの役割、ドラフトステータス、レビュープロセスを定義します。
このページでは、翻訳マージリクエストにおける担当者およびレビュアーの役割、ドラフトステータス、レビュープロセスを定義します。
一般的なガイダンスについては、GitLab コードレビューガイドライン および Engineering Workflow: Code Review を参照してください。
Tech Docs（アップストリーム）
Tech Docs の Translation MR は 2 段階のレビューを経ます: 1 段階目は gitlab-com（フォーク）、2 段階目は gitlab-org（アップストリーム）です。フォーク側ではプロセスは柔軟で、厳格な承認ルールはありません。アップストリーム側では以下の構造が適用されます。
担当者
- コンフリクトを解決します。 コンフリクトを解決できない場合は、他の人に引き継ぎます。
mainにおける各ファイルのコミット履歴を確認することで、どのターゲット変更がコンフリクトを引き起こしているかが分かります。これらは以下によって引き起こされる可能性があります:- 私たちが本番で翻訳を変更したこと
- TW がショートコードやリンティング等を変更したこと
- パイプラインの問題を修正します。
- 必要に応じてリベースします。
- レビューアプリを確認します（Duo は URL のリストの作成が得意です。例）。
- MR のドラフト状態を解除します。 これにより、GitLab Duo による初回レビューがトリガーされます。
- GitLab Duo のレビューフィードバックに対応します。 Duo のレビューにより 日本語コンテンツメンテナー によるレビューが必要となる翻訳エラーが指摘された場合、担当者はメンテナーにメンションを送り、レビュアーとして追加します。注意: メンテナーがコミットを追加した後は、その人が MR を承認できなくなります。
- レビュー担当者に引き継ぎます: Tech Docs メンテナー に引き継ぎます。
レビュアー
- 変更をレビューします。
- ビルドパイプラインを確認します。
- 承認後にマージします。
マーケティングサイト
マーケティングサイトでは、gitlab-com で「コミットを追加するユーザーによる承認を防止する」のような承認ルールが強制されていないため、レビュアーはコミットを追加した上でも承認・マージできます。Translation MR は現在、デフォルトでドラフトモードで作成されます。
担当者
- コンフリクトを解決します。
mainにおける各ファイルのコミット履歴を確認することで、どのターゲット変更がコンフリクトを引き起こしているかが分かります。これらは以下によって引き起こされる可能性があります:- 私たちが本番で翻訳を変更したこと
- DEX チームがスキーマの変更や新しいコンポーネントの追加といった更新を行ったこと（例）
- パイプラインを壊しているリンティング上の問題を修正します。
- 必要に応じてリベースします。
- 影響を受けるすべてのページについてレビューアプリを確認し、視覚的に QA します。
- MR のドラフト状態を解除します。 これにより、GitLab Duo による初回レビューがトリガーされます。
- GitLab Duo のレビューコメントに対応します: 可能な限り直接対応します。
- レビュー担当者に引き継ぎます。 ここでの考え方は、MR がレビューに引き継がれた時点で、マージ可能な状態になっているということです。承認が 1 件得られた時点でマージできます。
レビュアー
- 翻訳をレビューします。
- 必要に応じて翻訳に変更を加えます。
- 承認後にマージします。レビュアーがマージしない場合、担当者ができるだけ早くマージします。
