distributed-triage

分散システムの課題トリアージサブスキル

このサブスキルは、PT レベルのトリアージボットが対応した後の処理を引き継ぎます。すでに oncall: distributed ラベルが付いている課題を処理し、分散システム担当のサブオンコールへの振り分け、モジュールによる分類、トリアージ済みのマーク付けという二次トリアージを行います。

目次

• 利用可能な MCP ツール
• 参照ファイル
• コメントの重複チェック
• 分散システムのトリアージ手順
  • ステップ 0：人間によるトリアージがすでに完了しているか
  • ステップ 1：本当に分散システムの課題か
  • ステップ 2：分散システム担当のサブオンコールに振り分ける
  • ステップ 3：モジュールを分類する
  • ステップ 4：種類のラベル
  • ステップ 5：優先度が高い場合 — 人間によるレビューが必要
  • ステップ 6：再現手順が不足している場合
• 制約

分散システムのラベル一覧： このスキルで適用できるラベルについては、distributed-labels.json を参照してください。このファイルに記載されたラベルのみを適用してください。

分散システムのトリアージ基準： 振り分けの詳細なガイダンス、モジュール分類の判断材料、確信度の調整については、distributed-rubric.md を参照してください。

返信テンプレート： 分散システム固有のコメントテンプレートについては、templates.json を参照してください。

---

利用可能な MCP ツール

トリアージには、以下の GitHub MCP ツールを使用してください。

ツール	用途
mcp__github__get_issue	課題の詳細と既存のラベルを取得する
mcp__github__get_issue_comments	既存の課題コメントを取得する
mcp__github__update_issue	ラベルを適用する、または課題をクローズする
mcp__github__add_issue_comment	コメントを追加する（再現手順の依頼または誤ったラベルの報告に限る）
mcp__github__search_issues	参考情報として類似する課題を検索する

---

コメントの重複チェック

課題にコメントを追加する前に、次の手順を実行してください。

1. mcp__github__get_issue_comments を使って既存のコメントを確認します。
2. トリアージボットが同じテンプレート、または実質的に同等の依頼や説明をすでに投稿していないか確認します。
3. 重複するコメントがある場合は、追加のコメントを投稿しないでください。ラベル付けなど、引き続き必要なコメント以外の処理を行います。

文面が少し異なる場合や、古いバージョンのテンプレートが使われている場合も、コメントは重複として扱ってください。分散システムのトリアージでは、分散システムの再現手順の依頼や、「分散システムの課題ではない」という既存の通知も対象です。

---

分散システムのトリアージ手順

0）人間によるトリアージがすでに完了しているか

課題が人間によって完全に分類済みとみなされるのは、次の両方を満たす場合に限ります。

1. distributed-labels.json に記載された module: ラベルが少なくとも 1 つ付いていること
2. 次のサブオンコールラベルのいずれかが付いていること：oncall: distributed parallelisms、oncall: distributed infra、oncall: distributed checkpointing

両方が付いている場合：

• bot-triaged と triaged のラベルを追加します（人間による分類が完了しており、確信度も高いため）。
• 停止します — この課題は人間がすでに分類済みです。

片方しか付いていない場合（サブオンコールラベルのないモジュールラベル、またはモジュールラベルのないサブオンコールラベル）は、トリアージが未完了です。ステップ 1 に進んでください。PT レベルのトリアージボットは oncall: distributed と合わせて分散システムのモジュールラベルを適用できますが、サブオンコールは選択しません。それはあなたの担当です。

このステップだけで、バックログの大部分を解消できるはずです。

1) これは本当に分散処理の問題ですか？

問題のタイトル、説明、コメントを読み、実際に分散トレーニングに関連する問題かどうかを判断します。

分散処理の問題ではない兆候：

• 分散コードを使わない単一 GPU の問題（例：1 台の GPU での torch.nn、1 台のデバイスでの CUDA OOM）
• ビルド／パッケージングの問題（例：分散コードがない状態で import torch を実行すると undefined symbol: ncclAlltoAll が発生する）
• 分散コンポーネントを含まない torch.compile のみの問題
• 「distributed」という語が出てくるだけの、ドメインライブラリ（ビジョン、テキスト、オーディオ）に関する問題

分散処理の問題ではない場合：

1. triage review と bot-triaged のラベルを追加します
2. 同等の「分散処理ではない」というコメントがすでに存在しない限り、templates.json の not_distributed テンプレートを使ってコメントを投稿します
3. oncall: distributed は削除しないでください — 人間のオンコール担当者が振り分け直せるようにします
4. 終了します

2) 分散処理のサブオンコールに振り分ける

各問題には、サブオンコールラベルが必ず 1 つだけ付与されます。問題に 3 つのサブオンコールラベル（oncall: distributed parallelisms、oncall: distributed infra、oncall: distributed checkpointing）のいずれかがすでに付いている場合は、そのまま維持します — 自分の分類で別のラベルが適切だと判断した場合でも、2 つ目のサブオンコールを追加しないでください。既存のサブオンコールを使って次の手順を決めます（oncall: distributed parallelisms の場合は手順 3 に進み、それ以外の場合は以下のルールに従って bot-triaged を追加して終了します）。

サブオンコールが付いていない場合は、distributed-rubric.md の振り分けルールに基づいて、該当するものを 1 つだけ適用します。

サブオンコールラベル	適用する場合
oncall: distributed parallelisms	FSDP、DDP、DTensor、テンソル並列、コンテキスト並列、パイプライン並列。判断に迷う場合のデフォルトです
oncall: distributed infra	c10d、プロセスグループ、コレクティブ、NCCL/Gloo/MPI バックエンド、elastic/torchrun、RPC、ストア、分散処理ツール、DeviceMesh、対称メモリ
oncall: distributed checkpointing	分散チェックポイントの保存／読み込み、DCP、state_dict ユーティリティ、非同期チェックポイント

適切なサブオンコールを判断するには、distributed-rubric.md のセクション 1 にある振り分けの決定木と例外ケースを使います。

oncall: distributed infra または oncall: distributed checkpointing に振り分けた後：

• bot-triaged を追加します（サブオンコールへの振り分けにより、確実かつ完全な対応が完了しています）
• 終了します — 以降のトリアージはサブオンコールチームが担当します

oncall: distributed parallelisms に振り分けた後：

• モジュール分類のため、手順 3 に進みます

3) モジュールを分類する

問題の説明、コメント、コードスニペット、スタックトレースから、該当する分散処理モジュールを 1 つ以上分類します。distributed-rubric.md に記載されているモジュール分類の手がかりを参照します。

確信度に基づく対応：

確信度	基準	対応
高または中	モジュールへの明示的な言及、明らかな API の使用、または文脈から推測できるモジュール	module: ラベルを 1 つ以上追加し、bot-triaged と triaged を追加します
低	モジュールを特定できない — 曖昧な説明、コードなし、スタックトレースなし	triage review と bot-triaged を追加します（triaged は追加しません — 人間に判断を委ねます）

ルール：

• 複数のモジュールにまたがる問題には、複数のモジュールラベルを適用できます（例：DTensor のバグに関係する FSDP2 の問題には、module: fsdp と module: dtensor を付けます）。
• 問題に oncall: pt2 がすでに付いている場合は、削除しないでください。分散処理のモジュールラベルを追加します。
• モジュールが不明確な場合は、triage review と bot-triaged を追加します — モジュールラベルを推測して付けないでください。

4) タイプラベル

問題がバグ報告でない場合は、適切なタイプラベルを追加してください：

• feature — 現在いかなる形でも存在しない、まったく新しい機能
• enhancement — すでに動作しているものへの改善（例：パフォーマンス最適化、より良いエラーメッセージ、フォールバック経由ですでに実行されている演算に対するネイティブバックエンドの追加）

配布される問題のほとんどはバグ報告です — バグにタイプラベルを追加しないでください。問題がその演算について「現在動作している」または「より遅いパスにフォールバックする」と述べている場合、それは feature ではなく enhancement です。その改善がパフォーマンスに関するものである場合は、module: performance も追加してください。

5) 高優先度 — 人によるレビューが必要

重要: 問題が高優先度であると判断した場合、必ず以下を行ってください：

1. triage review ラベルを追加し、bot-triaged は追加しない

人による確認なしに high priority を直接追加しないでください。

配布される問題の高優先度基準：

• 分散コードにおけるクラッシュ / セグメンテーションフォールト / 不正なメモリアクセス
• サイレントな正確性の問題（コレクティブからの誤った結果、不正確な勾配同期）
• 以前のバージョンからのリグレッション（例：FSDP が 2.x では動作していたが、2.y で壊れた）
• マルチノードトレーニングに影響するハング（NCCL タイムアウト、コレクティブのデッドロック）
• 分散チェックポイント中のデータ破損
• c10d またはプロセスグループのコードにおける内部アサート失敗
• 多くのユーザーが影響を受けている、またはコアな分散コンポーネントが影響を受けている

6) 再現手順の欠如

問題に最小限の再現スクリプトがない場合：

1. needs reproduction + bot-triaged ラベルを追加する
2. 同等の分散再現リクエストがすでに存在しない限り、templates.json の needs_distributed_reproduction テンプレートを使用してコメントを投稿する

以下の場合は再現を要求しないでください：

• 問題にすでにコードスニペット、スクリプト、または誰かが再現に従うことができる手順がある
• 問題が機能リクエストである（再現は不要）
• マルチノードスクリプトが提供されている（ローカルで実行できなくても、それは再現としてカウントされます）

---

制約

禁止事項：

• 問題をクローズする（PT レベルのボットまたは人だけが問題をクローズします）
• 既存のラベルを削除する — ラベルの追加のみ行います
• oncall: distributed を削除する — 問題が誤ってラベル付けされていても、それは残ります
• oncall: pt2 を削除する — すでに存在する場合は、それを保持します
• bot-triaged または triaged を削除する — それらは親スキルによって適用され、残す必要があります
• 分類に自信がない場合に triaged を追加する — つまり、アクションが triage review または needs reproduction も適用する場合、または §5 の高優先度フローの場合
• distributed-labels.json にないラベルを追加する
• ステップ 1（誤ったラベル）またはステップ 6（再現）のテンプレートを使用する場合を除き、問題にコメントを追加する
• ボットがすでに同じテンプレートまたは実質的に同等のメッセージを問題に投稿している場合にコメントを追加する
• 問題をユーザーに割り当てる
• high priority を直接追加する — triage review を使用し、人に判断を委ねます

実施事項：

• 保守的に行動する — 迷った場合は、人による対応のために triage review を追加します
• ボットが問題を処理した場合は常に、確信度に関係なく bot-triaged を追加します。LOW 確信度または不確実なケースでは triage review と組み合わせて、cron スイープがそれを再び拾わないようにします。（例外：§5 の高優先度フローでは bot-triaged を意図的に省略します。）
• triaged は、確信を持った完全な分類に達した場合にのみ追加します：人がすでに分類した場合（ステップ 0）、確信を持ったサブオンコールルーティング（ステップ 2）、または HIGH/MEDIUM 確信度のモジュール分類（ステップ 3）。
• モジュールラベル（ステップ 3）の前に、常にサブオンコールラベル（ステップ 2）を追加します
• 分類する前に、コメントを含む問題全体を読む
• すべてのコメントアクションの前に既存のコメントを読み、重複するボットメッセージをスキップします
• 最終決定する前に、ルーブリックの「Common Mislabel Traps」セクションを確認します