Sous-Compétence de Triage des Issues Distribuées

Cette sous-compétence poursuit le travail du bot de triage de niveau PT. 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ées.

Contenu

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

Référence des labels distribués : Consultez distributed-labels.json pour les labels que cette compétence est autorisée à appliquer. APPLIQUEZ UNIQUEMENT les labels de ce fichier.

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

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

Outils MCP Disponibles

Utilisez ces outils GitHub MCP pour le triage :

Déduplication des Commentaires

Avant d'ajouter un commentaire à une issue :

1. Lisez les commentaires existants avec mcp__github__get_issue_comments.
2. Vérifiez si le bot de triage a déjà publié le même modèle ou une demande/explication substantiellement équivalente.
3. Si un doublon existe, n'ajoutez pas d'autre commentaire. Continuez avec les actions non-commentaires qui sont encore nécessaires, comme les labels.

Considérez un commentaire comme un doublon même si la formulation diffère légèrement ou qu'une version plus ancienne du modèle a été utilisée. Pour le triage distribué, cela inclut une demande de reproduction distribuée existante ou un avis « non distribué » existant.

Étapes du Triage Distribué

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

Un humain a pleinement classifié l'issue uniquement quand elle a LES DEUX :

1. Un 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 :

• Ajoutez les labels bot-triaged + triaged (la classification humaine est complète et fiable)
• ARRÊTEZ — un humain a déjà classifié cette issue.

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

Cette seule étape devrait traiter une grande partie du carnet de commandes.

1) Est-ce Vraiment une Issue Distribuée ?

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

Signes que ce n'est PAS une issue distribuée :

• Issue mono-GPU sans code distribué (p. ex., torch.nn sur un GPU, CUDA OOM sur un appareil)
• Issue de build/empaquetage (p. ex., undefined symbol: ncclAlltoAll lors de import torch sans code distribué)
• Issue pure de 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ée :

1. Ajoutez les labels triage review + bot-triaged
2. Publiez un commentaire en utilisant le modèle not_distributed de templates.json, sauf si un commentaire équivalent « non distribué » existe déjà
3. Ne supprimez PAS oncall: distributed — laissez l'oncall humain la rediriger
4. ARRÊTEZ

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), gardez-le tel quel — n'ajoutez PAS un deuxième sous-oncall, même si votre propre classification en aurait choisi un différent. Utilisez le sous-oncall existant pour décider de l'étape suivante (continuez à l'Étape 3 s'il s'agit de oncall: distributed parallelisms ; sinon, ajoutez bot-triaged et ARRÊTEZ selon les règles ci-dessous).

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

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

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

• Ajoutez bot-triaged (le routage du sous-oncall est un résultat fiable et complet)
• ARRÊTEZ — l'équipe du sous-oncall possède le triage ultérieur

Après routage vers oncall: distributed parallelisms :

• Continuez à 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 s'étend sur 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 le supprimez PAS. Ajoutez les labels de module distribués à côté.
• Quand le module n'est pas clair, ajoutez triage review + bot-triaged — ne deviinez PAS un label de module.

4) Labels de Type

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

• feature — nouvelle 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 s'exécute déjà via fallback)

La plupart des issues distribuées sont des signalements de bugs — n'ajoutez pas 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 une enhancement, pas une feature. Si l'amélioration concerne les performances, ajoutez aussi module: performance.

5) Priorité Haute — NÉCESSITE UN EXAMEN HUMAIN

CRITIQUE : Si vous pensez qu'une issue est de haute priorité, vous DEVEZ :

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

N'ajoutez PAS directement high priority sans confirmation humaine.

Critères de priorité haute pour les issues distribuées :

• Crash / segfault / accès illégal à la mémoire dans le code distribué
• Issue de correction silencieuse (résultats erronés des collectives, synchronisation incorrecte des gradients)
• Régression par rapport à une version antérieure (p. ex., FSDP fonctionnait dans 2.x, cassé dans 2.y)
• Blocage affectant l'entraînement multi-nœud (timeout NCCL, deadlock dans les collectives)
• Corruption de données lors du checkpointing distribué
• Défaillance interne d'assert 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. Ajoutez les labels needs reproduction + bot-triaged
2. Publiez un commentaire en utilisant le modèle needs_distributed_reproduction de templates.json, sauf si une demande de reproduction distribuée équivalente existe déjà

Ne demandez PAS 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 FAITES PAS :

• Fermer des 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 étiquetée
• Supprimer oncall: pt2 — s'il est déjà présent, gardez-le
• Supprimer bot-triaged ou triaged — ils sont appliqués par la compétence parente et doivent rester
• Ajouter triaged quand vous n'êtes PAS confiant dans la classification — c.-à-d. chaque fois que l'action applique aussi triage review ou needs reproduction, ou dans le flux §5 de priorité haute
• Ajouter des labels ne figurant pas dans distributed-labels.json
• Ajouter des commentaires aux issues sauf en utilisant les modèles à l'Étape 1 (mal-étiquetage) ou à l'Étape 6 (reproduction)
• Ajouter un commentaire quand le bot a déjà publié le même modèle ou un message substantiellement équivalent sur l'issue
• Assigner des issues à des utilisateurs
• Ajouter high priority directement — utilisez triage review et laissez les humains décider

FAITES :

• Soyez conservateur — en cas de doute, ajoutez triage review pour l'attention humaine
• Ajoutez bot-triaged chaque fois que le bot a traité l'issue, indépendamment de la confiance. Associez-le à triage review pour les cas BASSE confiance ou incertains afin que le balayage cron ne la reprenne pas. (Exception : le flux §5 de priorité haute omet intentionnellement bot-triaged.)
• Ajoutez triaged UNIQUEMENT quand vous atteignez une classification confidente et complète : un humain l'a déjà classifiée (Étape 0), un routage de sous-oncall confiant (Étape 2), ou une classification de module HAUTE/MOYENNE confiance (Étape 3).
• Ajoutez toujours un label de sous-oncall (Étape 2) avant les labels de module (Étape 3)
• Lisez l'issue complète en incluant les commentaires avant de classer
• Lisez les commentaires existants avant chaque action de commentaire et ignorez les messages de bot en doublon
• Vérifiez la section « Common Mislabel Traps » de la rubrique avant de finaliser