triaging-issues

PyTorch Issue トリアージスキル

このスキルは、イシューの振り分け、ラベルの適用、初回応答を行い、GitHub イシューのトリアージを支援します。

目次

• 利用可能な MCP ツール
• 絶対に追加してはいけないラベル
• イシューのトリアージ手順
  • ステップ 0：振り分け済み — スキップ
  • ステップ 1：質問か、バグ／機能要望か
  • ステップ 1.5：再現が必要 — 外部ファイル
  • ステップ 2：移管
  • ステップ 2.5：PT2 イシュー — 特別な対応
  • ステップ 3：二次オンコールへのリダイレクト
  • ステップ 4：イシューにラベルを付ける
  • ステップ 5：エスカレーション — 高優先度（人間によるレビュー）、その後リリーストリアージ
  • ステップ 6：bot-triaged（自動）
  • ステップ 7：トリアージ済みとしてマーク
• V1 の制約

ラベルのリファレンス： トリアージに適したラベルの全一覧は、labels.json を参照してください。このファイルに存在するラベルのみを適用してください。 ラベル名を作り出したり、推測したりしないでください。このファイルには、CI トリガー、テスト設定、リリースノート、非推奨ラベル、人間の判断が必要なラベルは含まれていません。

PT2 トリアージガイド： PT2／torch.compile イシューのトリアージ時にラベルを付ける詳しい方法については、pt2-triage-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	関連するイシューを検索して参考情報を得る

---

絶対に追加してはいけないラベル

プレフィックス／カテゴリ	理由
labels.json にないラベル	許可リストにあるラベルのみを適用してください
ciflow/*	PR 専用の CI ジョブトリガー
test-config/*	PR 専用のテストスイートセレクター
release notes: *	リリースノート用に自動で割り当てられる
ci-*、ci:*	CI インフラストラクチャの制御
sev*	重大度ラベルには人間の判断が必要
merge blocking	人間の判断が必要
actionable、needs design、needs reproduction、needs research	人間のレビュアーがイシューをレビューした後に使用するためのもの
「deprecated」を含むラベル	廃止済み
oncall: releng	トリアージのリダイレクト先ではありません。代わりに module: ci を使用してください

ブロックされた場合： フックによってラベルがブロックされた場合は、triage review のみを追加し、そこで停止してください。人間が対応します。

これらのルールは、すべてのラベルを labels.json と照合する PreToolUse フックによって適用されます。

人間が付けたラベルを上書きしない

人間がすでにラベルを適用している場合（特に ci: sev、重大度ラベル、優先度ラベル）は、削除したり置き換えたりしないでください。役割はラベルを補足することであり、上書きすることではありません。

---

イシューのトリアージ（各イシューについて）

0）振り分け済み — スキップ

イシューに oncall: ラベルが 1 つでも付いている場合は、完全にスキップしてください。 次のことは行わないでください。

• ラベルを追加する
• triaged を追加する
• コメントを残す
• トリアージ作業を行う

そのイシューはサブオンコールチームの担当です。チームが自分たちのキューを管理します。

1）質問か、バグ／機能要望か

• 質問（バグ報告でも機能要望でもない）の場合は、クローズし、templates.json の redirect_to_forum テンプレートを使用してください。
• バグ／機能要望なのか質問なのかが不明な場合は、request_more_info テンプレートを使用して追加情報を求め、そこで停止してください。

1.5) 外部ファイル

イシュー本文に、再現のためにユーザーがダウンロードする必要のある外部ファイルへのリンクが含まれているか確認します。

検出するパターン：

• ファイル添付：.zip、.pt、.pth、.pkl、.safetensors、.onnx、.bin ファイル
• 外部ストレージ：Google Drive、Dropbox、OneDrive、Mega、WeTransfer のリンク
• モデルハブ：モデルファイルへの Hugging Face Hub のリンク

対応：

1. イシュー本文を編集して、ダウンロードリンクを削除または伏せ字にします
   • 次のように置き換えます：[Link removed - external file downloads are not permitted for security reasons]
2. templates.json の request_self_contained_reproduction テンプレートを使用します
3. ユーザーから再現可能な例が提供されるまで、triaged は追加しないでください

1.55) 再現手順がない場合 — その他のケース

次の場合は、自己完結型の再現手順を求めて対応を終了します。

• ユーザーがハードウェア固有の問題（例：特定の GPU モデル）を報告しているものの、自己完結型の再現スクリプトがない
• ユーザーが、数行で公開実行できない特定のモデル／チェックポイント／データセットに言及している
• イシューでバージョンアップグレードによる不具合が説明されているものの、最小限のスクリプトがなく、概要しか記載されていない
• 再現に特定のトレーニング環境、分散環境、または複雑なインフラストラクチャが必要となる

1.6) エッジケースと数値精度

イシューが極端な値や数値精度の差に関係する場合：

検出するパターン：

• torch.finfo(dtype).max または torch.finfo(dtype).min に近い値
• 有効だが極端な入力からの出力に NaN／Inf が現れる
• CPU と GPU の結果の差
• dtype 間の精度の差（例：fp32 と fp16）
• ファザーが生成したエッジケース

重要 — キーワードだけで誤ったラベルを付けないでください：

エラーやタイトルに含まれるキーワードではなく、根本原因に基づいてラベルを付けます。キーワードからわかるのは何が失敗したかであり、なぜ失敗したかではありません。

• import torch 時の undefined symbol: ncclAlltoAll エラーは、パッケージングの問題（module: binaries）であり、分散トレーニングの不具合ではありません。ユーザーは分散コードを実行していません。
• パラメーター名や許容誤差のチェックに nan が含まれていても、実際の不具合が NaN の伝播に関するものでない限り、module: NaNs and Infs ではありません。
• スタックトレースに autograd が記載されていても、module: autograd とは限りません。不具合が autograd 自体にあるのか、単に呼び出し経路に含まれているだけなのかを確認してください。
• 許容誤差のしきい値に関するテスト失敗は module: tests であり、module: numerical-stability ではありません。

「修正はどこで行う必要があるか？」と考えてください。それによってラベルが決まります。

対応：

1. module: edge cases ラベルを追加します
2. ファザーが原因の場合は、topic: fuzzer も追加します
3. templates.json の numerical_accuracy テンプレートを使用して、ドキュメントへのリンクを掲載します
4. ドキュメント上、明らかに想定どおりの動作である場合は、テンプレートのコメントを付けてイシューをクローズします

2) 移管（ドメインライブラリまたは ExecuTorch）

イシューが別のリポジトリ（vision／text／audio／RL／ExecuTorch など）に属する場合は、イシューを移管して対応を終了します。

2.5) PT2 のイシュー — 特別な対応

PT2 はリダイレクトではありません。 oncall: pt2 はステップ 3 の他の oncall ラベルとは異なります。PT2 のイシューでは、完全なトリアージのため、引き続きステップ 4～7 を実施します。oncall: pt2 を追加した後、module: ラベルを付け、triaged を設定するなどの対応を続けてください。

oncall: pt2 のイシューには、少なくとも 1 つの module: ラベルが必須です。 モジュールラベルがないと PT2 のオンコールキューの範囲が広すぎるため、チームは影響を受けているコンポーネント（例：module: dynamo、module: inductor、module: helion、module: dynamic shapes）を把握する必要があります。該当するモジュールを特定できない場合は、代替として module: compile ux を使用できますが、まずは具体的なモジュールの特定を必ず試みてください。詳細については、pt2-triage-rubric.md を参照してください。

3) セカンダリオンコールへの振り分け

重要： イシューをPT2 以外のオンコールキューに振り分ける場合は、oncall: ... ラベルをちょうど 1 つ付けて、対応を終了してください。以下の対応は行わないでください。

• module: ラベルを追加する
• triaged を設定する
• それ以外のトリアージ作業を行う

サブオンコールチームが独自にトリアージを行います。担当するのは、イシューをそのチームに振り分けることだけです。

オンコールの振り分けラベル

ラベル	使用するタイミング
oncall: jit	TorchScript の問題
oncall: distributed	分散トレーニング（DDP、FSDP、RPC、c10d、DTensor、DeviceMesh、対称メモリ、コンテキスト並列処理、パイプライン処理）。特別な対応： このラベルを適用した後、二次トリアージのために分散トリアージのサブスキル（この issue で /distributed-triage）を実行してください。サブオンコールへの振り分け、モジュールラベルの追加、トリアージ済みのマークが行われます。
oncall: export	torch.export の問題
oncall: quantization	量子化の問題
oncall: mobile	モバイル（iOS／Android）。ExecuTorch は除きます
oncall: profiler	プロファイラーの問題（CPU、GPU、Kineto）
oncall: visualization	TensorBoard との統合

よくある振り分けミス：

• MPS ≠ モバイル。 MPS（Metal Performance Shaders）は macOS／Apple Silicon の GPU バックエンドです。MPS の問題を oncall: mobile に振り分けないでください。MPS の問題は module: mps を付けて一般キューに残します。
• DTensor → oncall: distributed。 DDP／FSDP に言及していなくても、DTensor の問題は必ず oncall: distributed に振り分けてください。
• ONNX → module: onnx。 oncall: onnx はありません。module: onnx を使用し、一般キューに残してください。
• CI／releng → module: ci。 oncall: releng は使用しないでください。CI インフラストラクチャの問題には module: ci を使用してください。
• torch.compile と分散処理。 torch.compile が分散処理の演算（例：dist.all_reduce）を誤って処理する場合、修正が両方のコードベースにまたがる可能性があるため、通常は oncall: pt2 と oncall: distributed の両方が必要です。

注： oncall: cpu inductor は PT2 のサブキューです。一般的なトリアージでは、oncall: pt2 のみを使用してください。

4) Issue にラベルを付ける（転送・リダイレクトされない場合）

Issue が一般キューに残る場合に限り：

• 影響を受ける領域に基づいて、1 つ以上の module: ... ラベルを追加します
• 一般的なラベルと具体的なラベルの両方がある場合は、具体的なラベルを優先します。具体的なラベルが一般的なラベルより優先されるケース（例：SDPA の Issue には module: nn ではなく module: sdpa、flex attention には module: nn ではなく module: flex attention）について、labels.json の説明を確認してください
• feature — これまでどのような形でも存在していなかった、まったく新しい機能
• enhancement — すでに動作しているものの改善（例：フォールバック／コンポジット経由ですでに実行される演算へのネイティブバックエンドカーネルの追加、パフォーマンス最適化、エラーメッセージの改善）。パフォーマンスに関する改善の場合は、module: performance も追加します
• function request — 新しい関数、または既存の関数への新しい引数／モードの追加
• Issue に、その演算が「現在は動作する」または「より遅い経路にフォールバックする」と書かれている場合は、feature ではなく enhancement です

見落としやすいラベル — 必ず確認してください：

条件	ラベル
セグメンテーションフォルト、不正なメモリアクセス、SIGSEGV	module: crash
パフォーマンスの問題：性能の退行、速度低下、最適化の要望	module: performance
Windows での Issue	module: windows
以前は動作していた機能が現在は壊れている	module: regression
以前は機能していたドキュメント／リンクが壊れている	module: docs + module: regression（enhancement ではありません）
機能そのものではなく、テストの失敗に関する Issue	module: tests
バックワードパス／勾配計算のバグ	module: autograd（演算のモジュールラベルに加えて）
torch.linalg の演算、または線形代数の演算（solve、svd、eig、inv など）	module: linear algebra
has workaround	回避策が簡単ではなく、自明でもない場合に限り追加します。Issue が「非連続テンソルでは X が動作しない」という内容の場合、.contiguous() の呼び出しはバグの説明から自明に導かれる逆操作であり、回避策ではありません。実際の回避策とは、特定バージョンのパッケージをインストールする、同期ポイントを追加する、gc.collect() を挿入する、またはバグの説明から自明には導かれない別の API を使用する、といったものです。

キーワードではなく、実際のバグに基づいてラベルを付けてください。 Issue を読んで、実際に何が壊れているのかを理解してください。パラメーター名に「nan」が含まれているだけで、ブロードキャストに関するバグが NaN／Inf のバグになるわけではありません。これはフロントエンドのバグです。

5) エスカレーション — 優先度高（人によるレビュー）、その後リリーストリアージ

独立した 2 つの判断を、この順序で行います。まず 5a に取り組み、その後、すべての Issue について 5b を行ってください。5b は 5a でエスカレーションした Issue に限りません。また、Issue には両方のラベル、片方のラベル、またはどちらのラベルも付かない場合があります。

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

重要： Issue の優先度が高いと判断した場合は、必ず以下を行ってください：

1. triage review ラベルを追加し、triaged は追加しないでください

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

優先度が高いと判断する基準：

• クラッシュ／セグメンテーションフォルト／不正なメモリアクセス
• エラーを出さずに誤った結果を返す、サイレントな正当性の問題
• 以前のバージョンからの退行
• 内部アサートの失敗
• 影響を受けるユーザーが多い
• 中核コンポーネントまたは人気モデルへの影響

5b) release triage — 最新リリースで確認済み

release triage は対象を絞ったフラグであり、あらゆるケースに使えるものではありません。リリースの担当者に課題を知らせるためのものであり、チェリーピックの依頼でも、何かを決定するものでもありません。

現在のバージョンは指示されます。決して推測しないでください。 プロンプトには、最新のリリース済みマイナーバージョンを示す RELEASE CONTEXT ブロックが含まれています。ブロックに unknown とある場合は、release triage を追加しないでください。

次の2つの条件のいずれかを満たす場合に限り、追加してください。

条件1 — 最新のリリース済みマイナーバージョンで確認済み。 課題に PyTorch のバージョンが記載されており、そのバージョンが RELEASE CONTEXT に記載されたマイナーバージョン、またはそのパッチリリースのいずれかであること。「バージョンが記載されている」とは、課題内にバージョンが明記されていることを意味します。環境ダンプの torch.__version__ 行、pip install 行、または報告者が文章で述べている場合が該当します。課題から読み取り、トレースバックや課題の日付、あるいは現在のバージョンについての推測から判断しないでください。

条件2 — すでに high priority のラベルが付いている。 課題を確認した時点で、人が以前の確認時に付けたラベルが存在すること。これは既存のラベルに限り、あなた自身による 5a の判断ではありません。あなたが課題を高優先度だと考える場合は、5a に従って triage review を追加して終了してください。それだけでは release triage を付ける条件を満たしません。

次のいずれかに該当するだけでは、追加しないでください。

状況	追加しない理由
main、ナイトリー、または RC でのみ再現する	リリースで確認されていません。重大な問題であれば、5a の triage review が適切な経路です。
課題内にバージョンがどこにも記載されていない	確認されていません。推測しないでください。
記載されたバージョンが RELEASE CONTEXT のマイナーバージョンより古い	すでにリリース済みです。今回のリリース系列には該当しません。
クラッシュ、サイレントな正確性の問題、BC 破壊、パッケージングやインストールの不具合	重大度は条件ではありません。条件1または条件2も満たす場合に限り該当します。
壊れた状態でリリースされそうに見える	推測にすぎません。
機能リクエスト、機能拡張、またはドキュメントのみの課題	どちらの条件でも、release triage は付けません。

判断に迷ったら、付けないでください。 このラベルは、リリースマネージャーが手作業で確認する短いリストとして使われるため、見落とすより誤検出のほうが大きな問題になります。曖昧な課題でリストが埋まると読まれなくなり、何も拾えなくなります。本当に緊急の課題は、5a の triage review を通じて人に届きます。

release triage は 5a の判断とは独立しているため、課題に両方のラベルが付くこともあります。また、これはあくまでフラグであり、結論ではありません。チェリーピックするかどうかを決めるのは、決してボットではありません。

6) bot-triaged（自動）

bot-triaged ラベルは、課題に変更が加えられた後のポストフックによって自動的に付与されます。手動で追加する必要はありません。

7) トリアージ済みとしてマークする

移管・リダイレクトされず、レビュー対象としてフラグ付けもされていない場合は、triaged を追加してください。

---

V1 の制約

してはいけないこと:

• バグ報告や機能リクエストを自動的にクローズする
• ステップ1に従った明確な使い方に関する質問を除き、課題をクローズする
• 課題をユーザーに割り当てる
• 人による確認なしに high priority を直接追加する
• oncall にリダイレクトする際にモジュールラベルを追加する
• 分類が不明確な場合に情報を1回だけ求める場合を除き、バグ報告や機能リクエストにコメントする

すること:

• 明確な使い方に関する質問はクローズし、discuss.pytorch.org を案内する（ステップ1に従う）
• 慎重に対応する。不確かな場合は、人の確認を求めるために triage review を追加する
• 課題が最新のリリース済みマイナーバージョンで確認済みの場合、またはすでに high priority が付いている場合に限り release triage を追加する（ステップ5b）。判断に迷ったら付けない
• 確信がある場合は、種類を示すラベル（feature、enhancement、function request）を適用する
• 分類が完了したら triaged ラベルを追加する

注: bot-triaged は、課題に変更が加えられた後のポストフックによって自動的に付与されます。