AI Framework グループ

AI Framework グループは、AI Abstraction Layer と GitLab AI 機能の開発を通じて、GitLab の他のプロダクトグループをどのように支援するかに注力しています。

ビジョン

AI Framework グループは、AI Abstraction Layer と GitLab AI 機能の開発を通じて、GitLab の他のプロダクトグループをどのように支援するかに注力しています。

👌 チーム OKR

チームの Objectives and Key Results（OKR）に興味がある方は、GitLab で確認できます。

🚀 チームメンバー

以下のメンバーは AI Framework Group の正規メンバーです。

チームメンバー情報は原文 (英語) を参照してください。

Stable Counterpart

以下の他職能チームのメンバーが私たちの stable counterpart です。

氏名	役割
Ashraf Khamis	Senior Technical Writer
Amanda Rueda	Senior Product Manager MCP Server

共有責任

☕ チームの責任

チームの責任には次のものが含まれます。

AI Abstraction Layer と AI Gateway を活用し、GitLab 全体への AI 機能の統合を促進する。
包括的なグローバル可観測性、モニタリング、ドキュメント、レイテンシ改善が整備されていることを保証する。
AI チャットシステムフレームワークに対する重要なサポートを提供する。
必要に応じて新しい AI プロバイダーのサポートを組み込む。
AI Gateway のプロダクションサポートと準備状態の確保を支援する。
プロンプトエンジニアリング、応答評価、ファインチューニング、評価などを含む LLM 推論サポート。

☎️ 連絡方法

文脈に応じて、IDE グループへの最適な連絡方法は以下のとおりです。

Slack チャンネル: #g_ai_framework
Slack グループ: @ai-framework（チーム全体）および @ai-framework-engs（エンジニアのみ）

📦 チームのプロセス

📆 定期的なチームミーティング

❗️重要: すべてのミーティングで、AI Framework チームのミーティングドキュメントを使用し、議事メモと、最近行われた他の同期ミーティングのアジェンダ／メモ／録画への参照を記入してください。これにより、ミーティングのメモを後から探しやすくなります。

チームミーティング

週次リファインメントアサインメントミーティング
- いつ: 毎週月曜日、14:00 GMT+1 と 19:00 GMT+1 を交互に開催
- 内容: 以前の Work Assignment Meeting に代わるミーティングで、Issue のリファインメントに焦点を当てます。エンジニアリングマネージャーとプロダクトマネージャーがすべての Issue が適切にリファインされていることを確認します。

共有カレンダー

AI Framework PTO（カレンダー ID: c_eca9440729dba2cbd88b3117fa70839836fb5811cb072132b94c52f912a31bf5@group.calendar.google.com）
AI-Powered Stage Calendar（カレンダー ID: [email protected]）

AI Framework のチームメンバーは、PTO イベントを同期して、AI Framework PTO カレンダーに反映してください。

🖖 週次 EM アップデート

毎週、チームの EM はチームが把握しておくべき最重要項目を捉えた週次ステータスアップデート Issue を提供しています。これらはこちらで確認できます。

📚 AI Framework ボード概要

私たちのワークフロープロセスでは、毎週ボードウォークを行い、Deliverable ラベルの付いた Issue をレビューします。ボードは次のように整理しています。

担当者は何に取り組むべきかをどう知るか?

Issue は、次のすべてが揃った時点で担当者に引き取られる準備ができたと見なされます。

Deliverable ラベル
現在のマイルストーン
workflow::ready for development または workflow::refinement のいずれかのラベル

ボードのリスト

Open 📝: 識別されたすべての Issue を含むリストです。マイルストーンまたは「workflow::ready for development」ラベルが欠けている場合、エンジニアリングマネージャーがアサインされます。
workflow::design ✏️: このフェーズでは、Issue がデザインリファインメントを受けます。デザイン上の考慮事項が組み込まれた後、「ready for development」ラベルが適用されます。
workflow::refinement 🧪: このステージにある Issue は、提案された解決策がすべての要件を満たすことを確認するためのエンジニアリングリファインメント中です。リファインメントが完了すると、「ready for development」ラベルが適用されます。
workflow::ready for development 🎯: 優先度が付けられ、特定のマイルストーンにアサインされた Issue はこのリストに移動され、「ready for development」ラベルが適用されます。
workflow::in dev 👩‍💻: 開発者が Issue の作業を開始したら、このリストに移動して「in dev」ラベルを適用する必要があります。
workflow::in review 👀: 開発が完了したら、Issue はこのリストに移動し、「in review」ラベルが適用されます。
workflow::verification ✅: コードと UX レビューが成功した後、Issue はこのリストに移動して「verification」ラベルが適用されるべきです。
workflow::complete 🎉: Issue が検証され、正しく動作することが確認されたら、このリストに移動して「complete」ラベルを適用し、Issue をクローズすべきです。

🔄 プロセス

✍️ バックログリファインメント

毎週、エンジニアリングチームは今後の Issue をレビューするバックログリファインメントプロセスを完了させます。この取り組みの目的は、すべての Issue にウェイトを付けて、見積もりされたチームのキャパシティと Issue ウェイトを使って各マイルストーンをより正確に計画できるようにすることです。

このバックログリファインメントプロセスに加えて、チームのエンジニアは、シンプルでバックログリファインメントを必要としない Issue にウェイトを付けることもできます。

このプロセスは 3 つのステップで進みます。

ステップ 1: リファインメント対象の Issue を特定する

エンジニアリングマネージャーは毎週リファインする Issue を選びます。合計で 5 件を目標としています。良い候補だと思う Issue があれば、その Issue 上で言及してください。

コンテキストスイッチを抑えるため、リファインメントはテーマを揃えるよう努めています。候補を探すのに適した場所:

選定後、エンジニアリングマネージャーは ai-framework::ready for next refinement ラベルを適用し、Refinement Bot を使用して、すべての候補をまとめたリファインメント Issue を生成します。

ステップ 2: Issue のリファインメント

1 週間を通して、チームの各エンジニアはバックログリファインメント用に選ばれた Issue リストを確認します。現在のバックログリファインメント Issue。

各 Issue について、各チームメンバーは Issue をレビューし、以下の情報を提供します。

見積もりウェイト。
Issue を別の Issue やマージリクエストにどう分割するか。

注意点:

議論は元の Issue 上で行います。
このプロセス中に、より多くの情報が集まるにつれて Issue の説明とラベルを更新する必要があります。
効率のため、すでに得られているフィードバックに応じて、リファインメントをスキップしても構いません。ただし、Issue が定義済みの「準備完了」基準を満たしている場合に限ります。
修正が明確で簡単な場合は、その Issue を自分にアサインし、ウェイト 1 を割り当てて修正をプッシュできます。
1 つの Issue が複数のインポーターに影響する場合は、Epic を作成するか、複数のリンクされた Issue や、各インポーターごとの MR を検討します。

定義済みの「準備完了」基準を満たしている Issue は、開発に向けてスケジュールされる可能性が高くなります。

📝 Issue ガイドライン

これらのガイドラインは、私たちのグループ内で計画とスケジューリングに使用するすべての Issue に適用されます。エンジニアは必要に応じて具体的な実装 Issue を定義できますが、Issue 全体の目標は次のとおりです。

成果物となる結果を表す意味のある タイトル を付けます。
- ✅ Add the new GitLab Duo chat package as a Vue2 extension
- ✅ Chat: move away from using OpenAI embeddings
- ❌ Make Chat better
Issue の目的を明確に説明する意味のある説明を提供し、必要に応じて技術的な詳細を加えます。
Issue の一部として小さなタスクを作成する重要な実装ステップやその他有用な方法がある場合は、Issue の説明にチェックリストとして含めてください。
Issue には Deliverable ラベル、マイルストーン、ワークフローラベルが付いている必要があります。
デザインとフロントエンドエンジニアリングは 1 つの Issue を共用します。同じ Issue が workflow::design から workflow::refinement、workflow::ready for development へと移動します。これにより、顧客向けの Issue について単一の真実の情報源を確保できます。デザイン Issue が大きすぎて実装できない場合は、Epic に昇格させることがあります。

より複雑な機能のために、特定のエンジニアリング駆動の実装 Issue を作成することは問題ありません。これらは Child Issue と呼ばれ、常に親 Issue にリンクし戻されている必要があります。1 つの Issue が多数の child Issue を生むようなら、Epic の作成を検討してください。

🏋 ウェイト付けと見積もりプロセス

ウェイトガイドライン

Issue はフィボナッチ数列（0, 1, 2, 3, 5, 8, 13+）でウェイト付けされます。

ウェイト 0: 最小の Issue（タイポ、軽微なフォーマット、テストなしの単純なコード変更）
ウェイト 1: 不確実性が最小限のシンプルな Issue（新規コントリビューターに最適）
ウェイト 2: 複数のコード／テスト更新を必要とするシンプルな Issue
ウェイト 3: ある程度の複雑さはあるが、扱える範囲のより大きな Issue
ウェイト 5: 通常は分割すべき。リスクの低い大きな手動更新には許容
ウェイト 8/13+: 分割が必要であることを示すプレースホルダーのウェイト。即時実装には大きすぎるか不確実

ウェイト更新プロセス

次マイルストーンにアサインされたすべての Issue は、エンジニアリングマネージャーが Deliverable ラベルを付ける前にウェイト付けされる必要があります。エンジニアリングマネージャーはウェイトが割り当てられているかをチェックし、ウェイトが 5 以上の場合は Issue を小さく分割する作業を行います。

エンジニアリングマネージャーとプロダクトマネージャーは、週次チームミーティング中に、次マイルストーンにアサインされた Issue のウェイト付けを依頼する責任があります。エンジニアにはミーティング前に Issue 説明を読んでもらい、ウェイト付けの準備をして、必要なら質問できるようにしてもらいます。複数のミーティングに分割しても構いません。