エディター拡張機能: マルチプラットフォームグループ

. シンプルさを保つため、以下の主要なステータスに焦点を当て、必要に応じて他のステータスも使用します。

• New → まだ優先順位付けや絞り込みがされていません。

• Planning breakdown → 近い時期（約1〜2か月以内）にチームの注目が必要。スコープ・リスク・依存関係・受け入れ条件を集めます。

• Ready for development → 即時優先。スコープが明確で、次に着手すべきもの。理想的には約2週間以内に完了します。

• In dev → DRI が割り当てられ、マイルストーンも設定済みで、作業中。

• In review → 実装完了。MR がオープンされ、レビュー・検証中。

• Blocked → 依存関係や外部要因によって進められない状態。ブロッカーと次の確認日をコメントしてください。

• Closed → 完了（または重複・wontfix としてクローズ）し、結果を記録します。

注: Issue とタスクの両方に存在するステータスである Planning breakdown と Ready for development を選んでいるため、単一のステータスフィルターで統一されたボードと埋め込みテーブルを簡単に構築できます。

ローリングバックログ Wiki ページ

この ローリングバックログページ はこの絞り込みプロセスのアウトプットであり、私たちが所有するすべてのスコープ（次の1〜2か月の作業になり得る）について、可視化され優先順位付けされチームでレビュー済みのバックログ上位リストとして機能します。

注: コミュニティのフィードバックも捉えるため、最も多くのサムアップを受けた Issue も考慮します。

フロー

1. EM と PM の非同期週次プリパス: 次の2ステップに向けた準備

   1. 検討する Issue のソースの例
      • ローリングバックログ
      • Slack の通知、チームでの議論
      • 最近の トリアージレポート の Issue。例: バグの優先順位付け、トリアージレポート、注意が必要な Feature flags
   2. ステップ #3（EM ＋ PM 同期コール）で議論する Issue に workflow::scheduling ラベルを追加します
   3. ローリングバックログ を最新に保つため、必要に応じて Issue を更新します。

2. チーム非同期隔週レビュー（タイムボックス約1時間）:

   • EM はこのレビューを トリガーする Issue を作成 し、すべてのエンジニアにアサインします（Issue 例）。レビューを終えたら自分自身のアサインを解除してください
   • チームの集中を毎週奪わないよう、2週間ごと に開催します。
   • 目標:
     • チーム全員が優先度に意見を述べられるようにする。
     • 技術改善や技術的負債の Issue を進める。
     • より重要視すべき Issue にフラグを立てる。
     • もう必要ない、または優先度を下げるべき Issue を特定する。
   • 参加方法:
     1. ローリングバックログ で現在の優先度を確認します
     2. 意見を述べる: 必要に応じて以下を追加・変更します（プッシュしたい新規 Issue にも適用）:
        1. ステータス: Planning breakdown: レーダー上にあるべき。今後2〜3マイルストーン以内のもの
        2. ステータス: Ready for development: 理想的にはこのマイルストーンで完了させるもの
        3. ラベル: workflow::schedulingt: 即時優先。次に着手すべき（あるいは少なくとも今週議論すべき）
        4. ~“workflow::scheduling”
     3. 上記のいずれかを変更する場合は、理由を添えて EM ＋ PM をメンションしてコメントしてください
   • 注意点:
     1. この時点では Issue の深掘り調査に時間をかけず、優先度の高レベルな概観で十分です
     2. 該当 Issue 自体、またはコメントがそちらでより適切ならローリングバックログ Issue にコメントしてください
     3. 発見可能性を高めるため、特定の GitLab リソースへの 参照 をリンクしてください。

3. EM ＋ PM 週次同期コール: workflow::scheduling ラベルに焦点を当て、チームのコメントを読み、ランキングを確認し、トレードオフを判断し、次の1〜2週間のターゲットデリバラブルを選定します。

   • ミーティングは チーム共有カレンダー にスケジュールし録画します。Zoom のトランスクリプトも使用するため、Issue の優先度や順序を変更した理由・議論の透明性をチームが得られ、計画 Issue に追加できます。
   • 月に1回はこのコールでマイルストーン計画 Issue を作成します（次回の絞り込みで変更される可能性があります）
   • EM は合意・更新されたデリバラブルのアサインを担当します
   • アウトプット: マイルストーン計画 Issue を週次で更新 ＋ EM が更新された優先度の Issue をアサイン
     • 月に1回、マイルストーン開始前に、新しい マイルストーン計画 Issue の作成準備として、より多くのチケットにわたる議論を行います

参加方法（チームメンバー以外向け）

チームに Issue を注目してほしい場合は、Issue を作成してください。Issue がまだ存在しない場合は、#g_editor-extensions でご連絡ください。

マイルストーン計画 Issue

私たちは マイルストーン計画 Issue を使用して、現在/今後のマイルストーンの目標を定義します。 PM と EM が目標のすり合わせを担当します。 計画 Issue は毎月 自動的に作成 されます。

フロー

1. マイルストーン計画 Issue の初期記入
   • PM が EM と整合を取りながらマイルストーンの目標をドライブします
   • 直前の Issue 絞り込み のすべてのアウトプットを考慮します
   • マイルストーン開始前 に行います
2. 週次の Issue 絞り込み 後の 週次更新
   • EM ＋ PM は必要に応じて マイルストーン計画 Issue を更新し、最新の変更を反映します。例えば以下のような内容です:
     • 発生した緊急のバグ
     • 別の AI エンジニアリングチームの作業を IDE に取り込む必要がある
     • フラグが立った技術的負債
   • EM はチームと連携して Deliverable ラベルと Stretch ラベルを付与し、Issue のステータス・ウェイト・マイルストーンが最新の優先度を反映していることを確認します
     • 週次の 1:1 や非同期で行うこともあります