Triage des bugs et curation des problèmes #

Le suivi des problèmes est important pour la communication dans le projet car il sert d'emplacement centralisé pour faire des demandes de fonctionnalités, signaler des bogues, identifier les principaux projets sur lesquels travailler et discuter des priorités. Pour cette raison, il est important d'organiser la liste des problèmes, d'ajouter des étiquettes aux problèmes et de fermer les problèmes résolus ou non résolus.

Le tri des problèmes ne nécessite aucune expertise particulière dans les composants internes de Matplotlib, est extrêmement précieux pour le projet, et nous invitons toute personne à participer au tri des problèmes ! Cependant, les personnes qui ne font pas partie de l'organisation Matplotlib n'ont pas les autorisations nécessaires pour modifier les jalons, ajouter des étiquettes ou fermer un problème . Si vous n'avez pas assez d'autorisations GitHub pour faire quelque chose (par exemple, ajouter une étiquette, fermer un problème), veuillez laisser un commentaire @matplotlib/triageteamavec vos recommandations !

Travailler sur les problèmes pour les améliorer #

L'amélioration des problèmes augmente leurs chances d'être résolus avec succès. Des directives sur la soumission de bons problèmes peuvent être trouvées ici . Un tiers peut donner des commentaires utiles ou même ajouter des commentaires sur le problème. Les actions suivantes sont généralement utiles :

  • documenter les problèmes auxquels il manque des éléments pour reproduire le problème, tels que des exemples de code

  • suggérant une meilleure utilisation de la mise en forme du code (par exemple, triple back ticks dans le démarquage).

  • proposer de reformuler le titre et la description pour les rendre plus explicites sur le problème à résoudre

  • établir des liens vers des questions ou des discussions connexes tout en décrivant brièvement comment ils sont liés, par exemple "Voir aussi #xyz pour une tentative similaire" ou "Voir aussi #xyz où la même chose a été signalée" fournit un contexte et aide la discussion

  • vérifier que le problème est reproductible

  • classer le problème comme une demande de fonctionnalité, un bogue de longue date ou une régression

Équipe de triage #

Si vous souhaitez rejoindre l'équipe de triage :

  1. Trier correctement 2-3 problèmes.

  2. Demandez à un membre de l' équipe de triage (en public ou en privé) de vous recommander à l'équipe de triage . Si vous avez travaillé avec quelqu'un sur le problème trié, ce serait une bonne personne à qui demander.

  3. Exercez votre nouveau pouvoir de manière responsable !

Toute personne disposant de droits de validation ou de triage peut également désigner un utilisateur à inviter à rejoindre l'équipe de triage.

Opérations de triage pour les membres des équipes de base et de triage #

En plus de ce qui précède, les membres de l'équipe de base et de l'équipe de triage peuvent effectuer les tâches importantes suivantes :

  • Mettez à jour les étiquettes pour les problèmes et les PR : consultez la liste des étiquettes github disponibles .

  • Problèmes de tri :

    • reproduire le problème , si le code posté est un bogue, étiquetez le problème avec "statut : bogue confirmé".

    • identifier les régressions , déterminer si le bogue signalé fonctionnait comme prévu dans une version récente de Matplotlib et, le cas échéant, déterminer la dernière version fonctionnelle. Les régressions doivent être jalonnées pour la prochaine version de correction de bogues et peuvent être étiquetées comme « Version critique ».

    • fermez les questions d'utilisation et indiquez poliment au journaliste qu'il doit utiliser discours ou Stack Overflow à la place et étiqueter comme "soutien communautaire".

    • fermez les problèmes en double , après avoir vérifié qu'ils sont bien en double. Idéalement, l'auteur initial déplace la discussion vers l'ancien problème en double

    • fermer les problèmes qui ne peuvent pas être reproduits , après avoir laissé du temps (au moins une semaine) pour ajouter des informations supplémentaires

Un flux de travail typique pour trier les problèmes #

Le flux de travail suivant [ 1 ] est un bon moyen d'aborder le tri des problèmes :

  1. Remercier le journaliste d'avoir ouvert un sujet

    Le suivi des problèmes est la première interaction de nombreuses personnes avec le projet Matplotlib lui-même, au-delà de la simple utilisation de la bibliothèque. En tant que tel, nous voulons que ce soit une expérience accueillante et agréable.

  2. Est-ce une question d'utilisation ? Si c'est le cas, fermez-le avec un message poli.

  3. Les informations nécessaires sont-elles fournies ?

    Vérifiez que l'affiche a rempli le modèle de problème. Si des informations cruciales (la version de Python, la version de Matplotlib utilisée, le système d'exploitation et le backend) sont manquantes, demandez poliment à l'auteur de l'affiche d'origine de fournir les informations.

  4. Le problème est-il minime et reproductible ?

    Pour les rapports de bogues, nous demandons au rapporteur de fournir un exemple reproductible minimal. Voir cet article utile de Matthew Rocklin pour une bonne explication. Si l'exemple n'est pas reproductible, ou s'il n'est clairement pas minimal, n'hésitez pas à demander au journaliste s'il peut fournir un exemple ou simplifier celui fourni. Reconnaissez que l'écriture d'exemples reproductibles minimaux est un travail difficile. Si le journaliste a du mal, vous pouvez essayer d'en écrire un vous-même.

    Si un exemple reproductible est fourni, mais que vous voyez une simplification, ajoutez votre exemple reproductible plus simple.

    Si vous ne pouvez pas reproduire le problème, veuillez le signaler avec les versions de votre système d'exploitation, Python et Matplotlib.

    Si nous avons besoin de plus d'informations à partir de cette étape ou de l'étape précédente, veuillez étiqueter le problème avec "statut : besoin d'éclaircissements".

  5. Est-ce une régression ?

    Alors que nous nous efforçons d'obtenir une bibliothèque sans bogue, les régressions sont la plus haute priorité. Si nous avons cassé le code utilisateur qui fonctionnait auparavant , nous devrions le corriger dans la prochaine version du correctif !

    Essayez de déterminer quand la régression s'est produite en exécutant le code de reproduction sur les anciennes versions de Matplotlib. Cela peut être fait par les versions publiées de Matplotlib (pour obtenir la dernière version dans laquelle il a fonctionné) ou en utilisant git bisect pour trouver le premier commit où il a été cassé.

  6. Est-ce un problème de doublon ?

    Nous avons de nombreux problèmes ouverts. Si un nouveau problème semble être un doublon, pointez sur le problème d'origine. S'il s'agit clairement d'un doublon, ou si le consensus est qu'il est redondant, fermez-le. Assurez-vous de toujours remercier le journaliste et encouragez-le à intervenir sur le problème d'origine, et peut-être à essayer de le résoudre.

    Si le nouveau problème fournit des informations pertinentes, comme un meilleur exemple ou un exemple légèrement différent, ajoutez-le au problème d'origine sous forme de commentaire ou de modification du message d'origine.

    Étiquetez le problème fermé avec "statut : doublon"

  7. Assurez-vous que le titre reflète fidèlement le problème. Si vous disposez des autorisations nécessaires, modifiez-le vous-même s'il n'est pas clair.

  8. Ajoutez les libellés pertinents, comme "Documentation" lorsque le problème concerne la documentation, "Bug" s'il s'agit clairement d'un bug, "Nouvelle fonctionnalité" s'il s'agit d'une demande de nouvelle fonctionnalité, ...

    Si le problème est clairement défini et que le correctif semble relativement simple, étiquetez le problème comme "Bon premier problème" (et éventuellement une description du correctif ou un indice sur l'endroit dans la base de code où chercher pour commencer).

    Une étape supplémentaire utile peut être de taguer le module correspondant, par exemple le label "GUI/Qt" le cas échéant.

Travailler sur les relations publiques pour aider à réviser #

La révision du code est également encouragée. Les contributeurs et les utilisateurs sont invités à participer au processus de révision en suivant nos directives de révision .

Remerciements #

Cette page est légèrement adaptée du projet scikit-learn .