Sous-Compétence Triage d'Issues Distribué

Cette sous-compétence reprend là où le bot de triage de niveau PT s'arrête. Elle traite les issues qui ont déjà le label oncall: distributed et effectue un triage de deuxième niveau : routage vers un sous-oncall distribué, classification par module, et marquage comme trié.

Contenu

• Outils MCP Disponibles
• Fichiers de Référence
• Étapes du Triage Distribué
  • Étape 0 : Déjà Triée par un Humain
  • Étape 1 : S'agit-il Vraiment d'une Issue Distribué ?
  • Étape 2 : Routage vers le Sous-Oncall Distribué
  • Étape 3 : Classification du Module
  • Étape 4 : Labels de Type
  • Étape 5 : Priorité Élevée — NÉCESSITE UN EXAMEN HUMAIN
  • Étape 6 : Reproduction Manquante
• Contraintes

Référence des labels distribués : Voir distributed-labels.json pour les labels que cette compétence est autorisée à appliquer. N'appliquez QUE les labels de ce fichier.

Rubrique de triage distribué : Voir distributed-rubric.md pour les directives détaillées de routage, les signaux de classification de module et l'étalonnage de confiance.

Modèles de réponse : Voir templates.json pour les modèles de commentaires spécifiques au distribué.

Outils MCP Disponibles

Utilisez ces outils GitHub MCP pour le triage :

Étapes du Triage Distribué

0) Déjà Triée par un Humain ?

Un humain a entièrement classé l'issue seulement quand elle a À LA FOIS :

1. N'importe quel label module: listé dans distributed-labels.json, ET
2. L'un des labels de sous-oncall : oncall: distributed parallelisms, oncall: distributed infra, ou oncall: distributed checkpointing.

Si les deux sont présents :

• Ajouter le label ptd-bot-triaged
• ARRÊTER — un humain a déjà classé cette issue.

Si seulement l'un est présent (un label de module sans sous-oncall, ou un sous-oncall sans label de module), le triage est incomplet — continuer à l'étape 1. Le bot de triage de niveau PT peut appliquer des labels de module distribué aux côtés de oncall: distributed, mais il ne choisit pas le sous-oncall ; c'est votre rôle.

Cette étape seule devrait clarifier une grande partie du backlog.

1) S'agit-il Vraiment d'une Issue Distribué ?

Lisez le titre, la description et les commentaires de l'issue. Déterminez si l'issue est vraiment liée à l'entraînement distribué.

Signes que ce N'EST PAS une issue distribué :

• Issue monoGPU sans code distribué (p. ex., torch.nn sur une GPU, CUDA OOM sur un seul appareil)
• Issue de build/packaging (p. ex., undefined symbol: ncclAlltoAll à import torch sans code distribué)
• Issue pure torch.compile sans composant distribué
• Issue concernant une bibliothèque de domaine (vision, texte, audio) qui mentionne simplement "distribué"

Si ce N'EST PAS une issue distribué :

1. Ajouter les labels triage review + ptd-bot-triaged
2. Publier un commentaire en utilisant le modèle not_distributed de templates.json
3. Ne PAS supprimer oncall: distributed — laisser l'oncall humain le réacheminer
4. ARRÊTER

2) Routage vers le Sous-Oncall Distribué

Chaque issue porte exactement UN label de sous-oncall. Si l'issue a déjà l'un des trois labels de sous-oncall (oncall: distributed parallelisms, oncall: distributed infra, ou oncall: distributed checkpointing), le conserver tel quel — ne PAS ajouter un deuxième sous-oncall, même si votre propre classification en aurait choisi un différent. Utiliser le sous-oncall existant pour décider l'étape suivante (continuer à l'étape 3 s'il s'agit de oncall: distributed parallelisms ; sinon ajouter ptd-bot-triaged et ARRÊTER selon les règles ci-dessous).

Si aucun sous-oncall n'est présent, appliquer exactement un en fonction des règles de routage dans distributed-rubric.md :

Utiliser l'arbre de décision de routage et les cas limites dans la section 1 de distributed-rubric.md pour déterminer le sous-oncall correct.

Après routage vers oncall: distributed infra ou oncall: distributed checkpointing :

• Ajouter ptd-bot-triaged
• ARRÊTER — l'équipe du sous-oncall est responsable du triage ultérieur

Après routage vers oncall: distributed parallelisms :

• Continuer à l'étape 3 pour la classification du module

3) Classification du Module

À partir de la description de l'issue, des commentaires, des extraits de code et des traces de pile, classez dans un ou plusieurs modules distribués. Consultez les signaux de classification de module dans distributed-rubric.md.

Actions basées sur la confiance :

Règles :

• Vous pouvez appliquer plusieurs labels de module quand l'issue couvre plusieurs modules (p. ex., module: fsdp + module: dtensor pour les issues FSDP2 qui rencontrent des bugs DTensor).
• Quand une issue a déjà oncall: pt2 appliqué, ne PAS le supprimer. Ajouter les labels de module distribué à côté.
• Quand le module est flou, ajouter triage review + ptd-bot-triaged — ne PAS deviner un label de module.

4) Labels de Type

Si l'issue n'est pas un rapport de bug, ajouter le label de type approprié :

• feature — fonctionnalité entièrement nouvelle qui n'existe pas aujourd'hui sous aucune forme
• enhancement — amélioration de quelque chose qui fonctionne déjà (p. ex., optimisation des performances, meilleurs messages d'erreur, ajout d'un backend natif pour une opération qui fonctionne déjà par fallback)

La plupart des issues distribués sont des rapports de bug — ne PAS ajouter de label de type pour les bugs. Si l'issue dit que l'opération « fonctionne actuellement » ou « revient à » un chemin plus lent, c'est enhancement, pas feature. Si l'amélioration concerne les performances, ajouter aussi module: performance.

5) Priorité Élevée — NÉCESSITE UN EXAMEN HUMAIN

CRITIQUE : Si vous croyez qu'une issue a une priorité élevée, vous DEVEZ :

1. Ajouter le label triage review et ne PAS ajouter ptd-bot-triaged

Ne PAS ajouter directement high priority sans confirmation humaine.

Critères de priorité élevée pour les issues distribués :

• Crash / segfault / accès mémoire illégal dans le code distribué
• Issue de correction silencieuse (résultats erronés à partir de collectives, synchronisation de gradient incorrecte)
• Régression par rapport à une version antérieure (p. ex., FSDP fonctionnait en 2.x, cassé en 2.y)
• Blocage affectant l'entraînement multi-nœud (timeout NCCL, blocage dans les collectives)
• Corruption de données lors du checkpointing distribué
• Échec d'assertion interne dans le code c10d ou du groupe de processus
• Nombreux utilisateurs affectés ou composant distribué central impacté

6) Reproduction Manquante

Si l'issue manque un script de reproduction minimal :

1. Ajouter les labels needs reproduction + ptd-bot-triaged
2. Publier un commentaire en utilisant le modèle needs_distributed_reproduction de templates.json

Ne PAS demander de reproduction quand :

• L'issue a déjà un extrait de code, un script ou des étapes que quelqu'un pourrait suivre pour reproduire
• L'issue est une demande de fonctionnalité (pas besoin de repro)
• Un script multi-nœud est fourni (cela compte comme une reproduction même si vous ne pouvez pas l'exécuter localement)

Contraintes

NE PAS :

• Fermer les issues (seul le bot de niveau PT ou les humains ferment les issues)
• Supprimer les labels existants — seulement ajouter des labels
• Supprimer oncall: distributed — il reste même si l'issue est mal labelisée
• Supprimer oncall: pt2 — s'il est déjà présent, le conserver
• Supprimer bot-triaged — il est appliqué par la compétence parente et doit rester
• Ajouter des labels ne figurant pas dans distributed-labels.json
• Ajouter des commentaires aux issues sauf en utilisant les modèles à l'étape 1 (mauvais label) ou à l'étape 6 (reproduction)
• Assigner des issues aux utilisateurs
• Ajouter directement high priority — utiliser triage review et laisser les humains décider

FAIRE :

• Être conservateur — en cas de doute, ajouter triage review pour une attention humaine
• Ajouter ptd-bot-triaged chaque fois que le bot a traité l'issue, indépendamment de la confiance. L'associer à triage review pour les cas de confiance FAIBLE ou incertains pour que la balayage cron ne la reprenne pas. (Exception : le flux de priorité élevée de la §5 omet intentionnellement ptd-bot-triaged.)
• Toujours ajouter un label de sous-oncall (étape 2) avant les labels de module (étape 3)
• Lire l'issue complète y compris les commentaires avant de classer
• Vérifier la section « Pièges de Mauvaise Labelisation Courants » de la rubrique avant de finaliser

Note : bot-triaged est automatiquement appliqué par le post-hook de la compétence parente après toute mutation d'issue. Vous n'avez pas besoin de l'ajouter manuellement.