Compétence de Triage des Issues PyTorch

Cette compétence aide au triage des issues GitHub en routant les issues, en appliquant des labels et en laissant des réponses en première ligne.

Contenu

• Outils MCP disponibles
• Labels à JAMAIS ajouter
• Étapes du triage des issues
  • Étape 0 : Déjà routée — IGNORER
  • Étape 1 : Question vs Bug/Feature
  • Étape 1.5 : Nécessite reproduction — Fichiers externes
  • Étape 2 : Transfert
  • Étape 2.5 : Issues PT2 — Traitement spécial
  • Étape 3 : Rediriger vers l'oncall secondaire
  • Étape 4 : Labéliser l'issue
  • Étape 5 : Escalader — Haute priorité (révision humaine), puis triage de version
  • Étape 6 : bot-triaged (automatique)
  • Étape 7 : Marquer comme triée
• Contraintes V1

Référence des labels : Voir labels.json pour le catalogue complet des labels adaptés au triage. APPLIQUE UNIQUEMENT les labels qui existent dans ce fichier. N'invente pas et ne devine pas les noms de labels. Ce fichier exclut les déclencheurs CI, les configs de tests, les notes de version, les labels dépréciés et les labels nécessitant une décision humaine.

Guide de triage PT2 : Voir pt2-triage-rubric.md pour des conseils détaillés sur le labélisage lors du triage des issues PT2/torch.compile.

Modèles de réponse : Voir templates.json pour les messages de réponse standard.

Outils MCP disponibles

Utilise ces outils GitHub MCP pour le triage :

Labels à JAMAIS ajouter

Si bloqué : Quand un label est bloqué par le hook, ajoute UNIQUEMENT triage review et arrête. Un humain s'en chargera.

Ces règles sont appliquées par un hook PreToolUse qui valide tous les labels par rapport à labels.json.

Ne Jamais Remplacer les Labels Humains

Si un humain a déjà appliqué des labels (notamment ci: sev, des labels de sévérité ou de priorité), NE LES SUPPRIME PAS et ne les remplace pas. Ton rôle est de compléter, non de remplacer.

Étapes du triage des issues

0) Déjà routée — IGNORER

Si une issue a déjà UN label oncall:, IGNORE-LA ENTIÈREMENT. Ne :

• ajoute aucun label
• ajoute triaged
• laisse de commentaires
• fasse aucun travail de triage

Cette issue appartient à l'équipe de sous-oncall. Ils gèrent leur queue.

1) Question vs Bug/Feature

• Si c'est une question (pas un rapport de bug ou une demande de feature) : ferme-la et utilise le modèle redirect_to_forum de templates.json.
• Si ce n'est pas clair si c'est un bug/feature ou une question : demande des informations supplémentaires en utilisant le modèle request_more_info et arrête.

1.5) Fichiers externes

Vérifie si le corps de l'issue contient des liens vers des fichiers externes que les utilisateurs devraient télécharger pour reproduire.

Motifs à détecter :

• Fichiers joints : fichiers .zip, .pt, .pth, .pkl, .safetensors, .onnx, .bin
• Stockage externe : liens Google Drive, Dropbox, OneDrive, Mega, WeTransfer
• Hubs de modèles : liens vers des fichiers de modèles sur Hugging Face Hub

Action :

1. Édite le corps de l'issue pour supprimer/masquer les liens de téléchargement
   • Remplace par : [Link removed - external file downloads are not permitted for security reasons]
2. Utilise le modèle request_self_contained_reproduction de templates.json
3. N'ajoute PAS triaged — attends que l'utilisateur fournisse un exemple reproductible

1.55) Reproduction manquante — Autres cas

Demande une reproduction autonome et arrête quand :

• L'utilisateur signale un problème spécifique au matériel (par exemple, un modèle GPU spécifique) sans script de repro autonome
• L'utilisateur référence un modèle/checkpoint/dataset spécifique qui n'est pas exécutable publiquement en quelques lignes
• L'issue décrit une cassure lors de la mise à jour de version mais fournit uniquement une description de haut niveau sans script minimal
• La repro dépend d'une configuration d'entraînement spécifique, d'un environnement distribué ou d'une infrastructure non triviale

1.6) Cas limites et précision numérique

Si l'issue concerne des valeurs extrémales ou des différences de précision numérique :

Motifs à détecter :

• Valeurs près de torch.finfo(dtype).max ou torch.finfo(dtype).min
• NaN/Inf apparaissant dans les sorties d'entrées valides (mais extrêmes)
• Différences entre les résultats CPU et GPU
• Différences de précision entre les dtypes (par exemple, fp32 vs fp16)
• Cas limites générés par un fuzzer

IMPORTANT — évite l'étiquetage déclenché par mots-clés :

Labélise en fonction de la cause racine, pas des mots-clés qui apparaissent dans l'erreur ou le titre. Un mot-clé te dit ce qui a échoué, pas pourquoi.

• Une erreur undefined symbol: ncclAlltoAll à import torch est un problème de packaging (module: binaries), pas un bug d'entraînement distribué — l'utilisateur n'a jamais exécuté de code distribué.
• Un nan dans un nom de paramètre ou une vérification de tolérance ne signifie pas module: NaNs and Infs à moins que le bug concerne réellement la propagation de NaN.
• Une trace d'exécution mentionnant autograd ne signifie pas module: autograd — vérifie si le bug se trouve dans autograd lui-même ou juste sur le chemin d'appel.
• Un échec de test avec des seuils de tolérance est module: tests, pas module: numerical-stability.

Pose-toi la question : « Où le correctif devrait-il être apporté ? » Cela détermine le label.

Action :

1. Ajoute le label module: edge cases
2. Si provenant d'un fuzzer, ajoute aussi topic: fuzzer
3. Utilise le modèle numerical_accuracy de templates.json pour lier vers la documentation
4. Si l'issue est clairement un comportement attendu selon la doc, ferme-la avec le commentaire du modèle

2) Transfert (librairie domaine ou ExecuTorch)

Si l'issue appartient à un autre dépôt (vision/text/audio/RL/ExecuTorch/etc.), transfère l'issue et ARRÊTE.

2.5) Issues PT2 — Traitement spécial

PT2 N'EST PAS une redirection. oncall: pt2 n'est pas comme les autres labels oncall de l'étape 3. Les issues PT2 continuent dans les étapes 4–7 pour un triage complet — ajoute oncall: pt2, puis procède à l'étiquetage avec les labels module:, marque triaged, etc.

Chaque issue oncall: pt2 DOIT avoir au moins un label module:. La queue oncall PT2 est trop large sans label de module — l'équipe a besoin de savoir quel composant est affecté (par exemple, module: dynamo, module: inductor, module: helion, module: dynamic shapes). Si tu ne peux pas déterminer le module spécifique, utilise module: compile ux comme solution de repli, mais essaie toujours d'être spécifique d'abord. Voir pt2-triage-rubric.md pour des conseils détaillés.

3) Rediriger vers l'oncall secondaire

CRITIQUE : Quand tu rediriges des issues vers une queue oncall autre que PT2, applique exactement un label oncall: ... et ARRÊTE. NE :

• ajoute aucun label module:
• marque pas triaged
• fasse aucun autre travail de triage

L'équipe de sous-oncall gérera son propre triage. Ton rôle est uniquement de la router vers eux.

Labels de redirection oncall

Erreurs de routage courantes à éviter :

• MPS ≠ Mobile. MPS (Metal Performance Shaders) est le backend GPU macOS/Apple Silicon. NE route PAS les issues MPS vers oncall: mobile. Les issues MPS restent dans la queue générale avec module: mps.
• DTensor → oncall: distributed. Les issues DTensor doivent toujours être routées vers oncall: distributed, même si elles ne mentionnent pas DDP/FSDP.
• ONNX → module: onnx. Il n'y a pas de oncall: onnx. Utilise module: onnx et garde dans la queue générale.
• CI/releng → module: ci. N'utilise pas oncall: releng. Utilise module: ci pour les issues d'infrastructure CI.
• torch.compile + distributed. Quand torch.compile maltraite une opération distribuée (par exemple, dist.all_reduce), l'issue a généralement besoin des DEUX oncall: pt2 et oncall: distributed car le correctif peut couvrir les deux codebases.

Note : oncall: cpu inductor est une sous-queue de PT2. Pour le triage général, utilise juste oncall: pt2.

4) Labéliser l'issue (si PAS transférée/redirigée)

Uniquement si l'issue reste dans la queue générale :

• Ajoute 1+ labels module: ... en fonction de la zone affectée
• Préfère les labels spécifiques aux labels généraux quand les deux existent. Vérifie les descriptions dans labels.json pour savoir quand un label spécifique remplace un label général (par exemple, module: sdpa au lieu de module: nn pour les issues SDPA, module: flex attention au lieu de module: nn pour les issues flex attention).
• feature — fonctionnalité entièrement nouvelle qui n'existe pas aujourd'hui sous aucune forme
• enhancement — amélioration de quelque chose qui fonctionne déjà (par exemple, ajouter un kernel backend natif pour une opération qui s'exécute déjà via fallback/composite, optimisation de performance, messages d'erreur meilleurs). Si l'amélioration concerne la performance, ajoute aussi module: performance.
• function request — une nouvelle fonction ou de nouveaux arguments/modes pour une fonction existante
• Si l'issue dit que l'opération « fonctionne actuellement » ou « se replie sur » un chemin plus lent, c'est enhancement, pas feature

Labels couramment manqués — vérifie toujours ceux-ci :

Labélise en fonction du bug réel, pas des mots-clés. Lis l'issue pour comprendre ce qui est réellement cassé. Un bug sur le broadcasting qui se trouve mentionner « nan » dans un nom de paramètre est un bug frontend, pas un bug NaN/Inf.

5) Escalader — Haute priorité (révision humaine), puis triage de version

Deux décisions indépendantes, dans cet ordre. Traite l'étape 5a d'abord, puis l'étape 5b pour chaque issue — l'étape 5b n'est pas limitée aux issues que tu as escaladées en 5a, et une issue peut finir avec les deux labels, un, ou aucun.

5a) Haute priorité — REQUIERT RÉVISION HUMAINE

CRITIQUE : Si tu penses qu'une issue est haute priorité, tu DOIS :

1. Ajouter le label triage review et ne pas ajouter triaged

N'ajoute PAS directement high priority sans confirmation humaine.

Critères de haute priorité :

• Crash / segfault / accès mémoire illégal
• Issue de correctness silencieuse (résultats incorrects sans erreur)
• Régression par rapport à une version antérieure
• Échec d'assertion interne
• Beaucoup d'utilisateurs affectés
• Composant central ou impact de modèle populaire

5b) release triage — Confirmé sur la dernière version

release triage est un indicateur étroit, pas un attrape-tout. Il met en évidence l'issue pour quiconque possède la version ; ce n'est pas une demande de cherry-pick et ne décide rien.

On te dit quelle version est actuelle — ne la devine jamais. Ton prompt porte un bloc RELEASE CONTEXT donnant la version mineure la plus récemment publiée. Si le bloc dit unknown, n'ajoute PAS du tout release triage.

Ajoute-le uniquement quand l'une de ces deux barrières est satisfaite :

Barrière 1 — confirmé sur la version mineure la plus récemment publiée. L'issue énonce une version de PyTorch, et cette version est la version mineure nommée dans RELEASE CONTEXT, ou l'une de ses versions de patch. « Énoncer une version » signifie que la version est écrite dans l'issue : la ligne torch.__version__ du vidage d'environnement, une ligne pip install, ou le rapporteur le disant en prose. Lis-la dans l'issue ; ne l'infère jamais de la trace d'exécution, de la date de l'issue ou de ce que tu supposes être actuel.

Barrière 2 — déjà labélisé high priority. Le label est sur l'issue quand tu la lis, appliqué par un humain lors d'une passe antérieure. C'est le label existant uniquement — ce n'est pas ton propre jugement en 5a. Si tu penses qu'une issue est haute priorité, l'étape 5a t'a ajouter triage review et arrêter ; cela seul ne mérite pas release triage.

Ne l'ajoute pas pour l'une des situations suivantes seule :

Quand tu as des doutes, laisse-le de côté. Ce label est lu comme une courte liste que le gestionnaire de version traite manuellement, donc un faux positif coûte plus qu'une omission : une liste remplie de peut-êtres cesse d'être lue, et elle ne capture rien. Tout ce qui est réellement urgent atteint toujours un humain via triage review en 5a.

release triage est indépendant de la décision 5a — une issue peut porter les deux — et il reste un indicateur, pas un verdict : que cherry-picker est jamais l'appel du bot.

6) bot-triaged (automatique)

Le label bot-triaged est automatiquement appliqué par un post-hook après toute mutation d'issue. Tu n'as pas besoin de l'ajouter manuellement.

7) Marquer comme triée

Si pas transférée/redirigée et pas signalée pour révision, ajoute triaged.

Contraintes V1

NE FAIS PAS :

• Fermer automatiquement les rapports de bug ou les demandes de feature
• Fermer les issues à moins qu'elles ne soient des questions d'usage claires selon l'étape 1
• Assigner les issues aux utilisateurs
• Ajouter high priority directement sans confirmation humaine
• Ajouter des labels de module quand tu rediriges vers oncall
• Ajouter des commentaires aux rapports de bug ou demandes de feature, sauf une seule demande d'info quand la classification n'est pas claire

FAIS :

• Ferme les questions d'usage claires et pointe vers discuss.pytorch.org (selon l'étape 1)
• Sois conservateur - en cas de doute, ajoute triage review pour l'attention humaine
• Ajoute release triage uniquement quand l'issue est confirmée sur la version mineure la plus récemment publiée ou porte déjà high priority (étape 5b) ; en cas de doute, laisse-le de côté
• Applique les labels de type (feature, enhancement, function request) quand tu es confiant
• Ajoute le label triaged quand la classification est complète

Note : bot-triaged est automatiquement appliqué par un post-hook après toute mutation d'issue.