Répondre à une issue GitHub

Aider un mainteneur à rédiger une réponse de haute qualité à une issue GitHub d'un contributeur externe.

Workflow

1. Comprendre l'issue

• Récupérer l'issue en utilisant gh issue view <number> --repo NVIDIA/Megatron-LM --json title,body,comments,labels,state.
• Lire le titre, le corps et tous les commentaires existants pour comprendre le contexte complet.
• Identifier le type : signalement de bug, demande de fonctionnalité, question ou discussion.

2. Étudier la codebase

• En fonction de ce que demande l'issue, chercher dans la codebase Megatron-LM le code pertinent.
• Lire les fichiers source concernés pour comprendre le comportement actuel.
• Si l'issue référence des fichiers ou fonctions spécifiques, les lire directement.
• Vérifier git log --oneline -20 -- <relevant-files> pour voir s'il y a eu des changements récents qui traitent ou se rapportent à l'issue.
• Utiliser git log -S "<symbol>" --oneline pour retracer quand du code a été ajouté ou supprimé — ceci est particulièrement utile pour les questions sur du code inutilisé/deprecated ou des fonctionnalités manquantes.
• Si l'issue porte sur un bug, essayer de confirmer que le comportement signalé correspond au code.
• Vérifier qu'une PR existante n'adresse pas déjà l'issue : gh pr list --repo NVIDIA/Megatron-LM --search "<keywords>" --limit 5.

3. Vérifier avant de citer

Avant d'inclure des détails spécifiques dans la réponse, les vérifier :

• En citant un hash de commit, confirmer que le message de commit et la diff correspondent à ce que vous affirmez (git show <hash> --stat).
• En citant un chemin de fichier et un numéro de ligne, relire le fichier pour confirmer que le contenu de la ligne est correct.
• En affirmant qu'un code est inutilisé ou manquant, faire une recherche grep approfondie pour s'assurer qu'aucune référence n'a été omise.

4. Rédiger la réponse

Écrire une réponse qui :

• Est techniquement exacte et fondée sur le code réel (citer les chemins de fichiers et numéros de ligne quand utile).
• Est respectueuse et accueillante envers les contributeurs externes.
• Répond directement à la question ou la préoccupation soulevée.
• Si le contributeur a identifié une lacune ou un bug réel, le reconnaître clairement.
• S'il y a une solution de contournement, la mentionner.
• Si un travail est planifié ou si une correction serait bienvenue, le dire et suggérer les étapes suivantes (par ex. « une PR pour aborder ceci serait bienvenue »).
• Maintient un ton professionnel mais amical.
• Est concise — les contributeurs apprécient les réponses directes, pas des murs de texte.

5. Suggérer les actions de suivi

Si l'issue identifie quelque chose de clairement actionnable (code mort à supprimer, un petit bug à corriger, une fonctionnalité manquante), l'indiquer au mainteneur et proposer de créer une branche et une PR pour l'aborder — ne pas se contenter de rédiger un commentaire.

6. Présenter au mainteneur

Montrer la réponse rédigée à l'utilisateur (le mainteneur) pour relecture. NE PAS la poster sur GitHub automatiquement. Le mainteneur décidera de la poster, de l'éditer ou de demander des modifications.

Formater le brouillon en bloc markdown cité pour qu'il soit facile à copier.

Directives importantes

• Ne jamais poster de commentaires sur GitHub sans approbation explicite de l'utilisateur.
• Si vous n'êtes pas sûr de la réponse, le dire clairement dans votre brouillon et signaler l'incertitude au mainteneur.
• Si l'issue dépasse le cadre de ce que vous pouvez déterminer à partir du code, indiquer au mainteneur ce que vous avez trouvé et ce qui reste peu clair.
• Vérifier l'existence d'issues similaires qui pourraient être pertinentes : gh issue list --repo NVIDIA/Megatron-LM --search "<keywords>" --limit 5.