Traqueur de bogues

Attention : vous consultez actuellement la documentation dédiée aux versions 1.x de Moodle. La documentation pour les versions 2.x de Moodle est consultable ici : Traqueur de bogues et celle pour Moodle 3.x est consultable là : Traqueur de bogues.

Le suivi des bogues est une partie importante du processus de contrôle qualité. Cela implique de signaler les problèmes (bogues), les idées pour les améliorations et les nouvelles fonctionnalités souhaitées. Contrairement à la plupart des programmes propriétaires, toutes ces informations sur le suivi de Moodle sont ouvertes à tous. Le système de suivi de Moodle est appelé Traqueur Moodle. Vos demandes de nouvelles fonctionnalités, d'améliorations, ou même des critiques constructives des fonctions existantes y sont les bienvenues (en anglais).

La beauté de l'open source est que chacun peut participer et aider à obtenir un meilleur produit que chacun pourra ainsi utiliser plus agréablement. Merci de nous aider en utilisant le Traqueur Moodle !

Se connecter au traqueur de bogues

  • Si vous êtes un nouvel utilisateur du traqueur de bogues, vous devez créer un compte ici. Il est fortement suggéré que votre nom d'utilisateur sur le traqueur soit le même que sur Moodle.org.
  • Si vous avez oublié votre mot de passe, allez ici et sélectionnez 'forgot password' qui est juste sous le bouton 'log in'. Suivez les instructions.

Utiliser le traqueur en français

Pour la plupart des lecteurs de cette page, il sera sans doute plus simple d'utiliser le traqueur de bogues avec une interface en français. Pour cela, il faudra, une fois connecté, suivre les étapes suivantes :

  1. Cliquez sur le lien "Profile" en haut à droite
  2. Cliquez sur le lien "Edit Preferences" en bas à gauche
  3. Sélectionnez la langue française dans le menu déroulant
  4. Validez votre choix en cliquant sur le bouton "Update"

La suite devrait être ainsi facilitée.

Comment signaler un bogue, demander une amélioration, ou une nouvelle fonctionnalité

Note : voyez la section "Champs du traqueur" ci-dessous pour une description complète des différents champs.

  • Connectez vous au Traqueur de bogues
  • Sélectionnez "CREER UNE DEMANDE" depuis le menu sous le logo du Traqueur Moodle
  • Depuis le menu déroulant, sélectionnez le "Type de demande" : Bug, New Feature, Task ou Improvement puis cliquez sur le bouton "Suivant>>"
  • Vous verrez une série de listes déroulantes et de champs de texte. Complétez en autant que possible. Certains champs sont obligatoires, et d'autres optionnels.
  • Cliquez sur le bouton 'Créer' en bas de page pour créer le bogue.

Attention : l'utilisation du traqueur étant internationale, les champs devront être remplis en anglais.

Champs du traqueur

Note : une courte explication apparait sous chaque champ du traqueur.

Projet - Champ requis. Le traqueur est utilisé pour plusieurs projets, deux pour l'instant : 'moodle' et 'moodle.org'. Indiquez 'moodle' pour les problèmes ou bogues concernant la plate-forme Moodle elle-même ; indiquer 'moodle.org' pour les problèmes ou bogues afférents aux sites tracker.moodle.org, docs.moodle.org, demo.moodle.org, download.moodle.org ou moodle.org.

Type de demande - Champ requis. Les bogues sont classés parmi ces types :

Bug - Un problème perturbant ou empêchant Moodle de fonctionner normalement.
Improvement - Une amélioration à apporter à une fonctionnalité existante de Moodle.
New Feature - Une fonctionnalité à ajouter à Moodle.
Task - une tâche à réaliser. Il s'agit généralement de travaux extérieurs au produit.
Sub-Task - Les sujets sont parfois décomposés en sous-tâches.

Résumé - Champ requis. Une description concise du problème.

Niveau de sécurité - Champ optionnel. Indiquez les implications du problème sur la sécurité de Moodle. Seuls les membres du groupe sécurité de Moodle peuvent consulter les bogues à fort enjeu de sécurité.

Priorité - Les bugs sont priorisés selon l'un des suivants :

Blocker - Empêche le développement et/ou les tests ; paralyse les travaux.
Critical - Crashs, pertes de données, graves fuites de mémoire.
Major - Perte de fonctionnalité majeure.
Minor - Perte de fonctionnalité mineure, ou autre problème facilement corrigible.
Trivial - Problème cosmétique comme une faute d'orthographe, ou un problème d'alignement de texte.

Composants - Champ requis. Sélectionnez la/les partie(s) de Moodle affectée(s) par ce bogue. Sélectionnez 'Unknown' si vous n'êtes pas sûr.

Affecte la/les version(s) - Champ requis. Indiquez la version de Moodle où le bogue est apparu. Renseigné par la personne rapportant le bogue, ce champ indique généralement une seule version. Pour signaler des 'improvements', 'tasks', ou des 'new features' il convient d'indiquer la dernière version. Ceci aidera à évaluer le produit pour lequel la demande est faite.

Attribution - La personne qui corrigera le problème. Ce champ est rempli par les développeurs ou le responsable du composant.

Rapporteur - La personne qui a signalé ce bogue. Ce champ est automatiquement rempli par le Traqueur.

Environnement - Indiquez le système d'exploitation, le contexte logiciel et/ou matériel dans lequel le bogue est apparu.

Description - Une description complète, précise et concise du problème ou de l'amélioration.

Base de données - Champ optionnel. Si applicable à ce bogue, spécifie le type de base de données.

URL - Champ optionnel. Si possible, fournir une adresse URL qui montre un exemple de ce bogue.

QA Assignee - Utilisé pour spécifier la personne qui testera (la correction de) ce bogue.

Version(s) corrigée(s) - Spécifie la version de Moodle dans laquelle le bogue à été ou sera corrigé. Ce champ est habituellement rempli par le développeur lorsque le bogue a été corrigé, ou par les développeurs principaux qui recensent les bogues d'une version spécifique. Habituellement, une seule version est indiquée ici. C'est la première version de Moodle incluant la correction.

Pièce jointe - Optionnel. Inclure une pièce jointe aidera les développeurs et les testeurs à mieux comprendre les bugs. La limite maximale d'une pièce jointe est 512 Ko.

Commentaire - Ce champ comprend la liste détaillée de tous les changements afférents à ce bogue.

Résolution - Ce champ est affiché uniquement lors de la résolution ou de la fermeture d'un bogue. Portez ici la mention qui décrit le mieux la façon dont le bogue a été cortraité :

Fixed - Le bogue a été corrigé ; le code modifié sera intégré au CVS. Utilisez cette mention uniquement lorsque le code de Moodle a effectivement été modifié.
Won't Fix - Le problème décrit ne sera pas réglé.
Not a bug - Ce problème ne résulte pas d'un bogue et a été rapporté par erreur. Utilisez aussi cette mention si le bogue a déjà été résolu par une version précédente de Moodle.
Duplicate - Ce rapport de bogue vient en doublon avec un problème précédemment décrit.
Incomplete - Le traitement du bogue nécessite des informations complémentaires.
Cannot Reproduce - Toutes les tentatives de reproduction du bogues ont échoué, ou le rapport de bogue n'est pas assez complet pour le reproduire. La relecture du code n'apporte aucun indice sur les causes du bogue. Si des informations complémentaires apparaissent ultérieurement, veuillez relancer le sujet.
Deferred - La correction du bogue est reportée à une version ultérieure.

Résolution des bogues dans le traqueur

Note : seuls les développeurs principaux et les testeurs peuvent modifier le statut des bogues à "resolved" ou "closed".

  • Les bogues sont assignés par les développeurs ou les "Component Leads".
  • Les développeurs modifient ou ajoutent du code, et l'intègrent au CSV
  • On ajoute au traqueur les commentaires utiles. L'état du bogue est porté à Resolved en cliquant sur le bouton "Resolved Issue".
  • Il convient d'indiquer quelle(s) version(s) incluera le correctif dans le champ Fix Version/s. Il faut y indiquer dans quelle(s) branche(s) la modification est apportée (cf. infra).
  • La seule raison pour ne pas déclarer le bogue "Resolved" est que le développeur considère sans intérêt de tester le problème : le bogue est alors directement porté à l'état "Closed".

Plus d'information pour remplir le champ Fix Version/s

Supposez que les versions stables soient 1.8.4, 1.7.4, 1.6.6 et que 1.9 possède une branche faisant que nous ayons 1.9 beta+ et 2.0dev. Supposez que vous corrigiez un bogue sur MOODLE_17_STABLE, MOODLE_18_STABLE, MOODLE_19_STABLE et HEAD. Alors, marquez ce bogue corrigé pour 1.7.5, 1.8.5 et 1.9.

Une fois Moodle 1.9 sorti en version stable, si vous corrigez un bogue sur les branches MOODLE_19_STABLE et HEAD, marquez ce bogue corrigé pour 1.9.1 et 2.0.

Dans les situations "Cannot reproduce", "Won't fix" (etc...), laissez le champ "Fix version" vide.

Lorsque le bogue est un doublon ("Duplicate"), créez un lien vers le doublon.

Les informations portées à "Fix version/s" sont automatiquement reprises pour rédiger les notes de mises à jour (voir http://tracker.moodle.org/browse/MDL). C'est pourquoi il est utile de renseigner ce champ... mais n'y passez pas non plus vos nuits !

Le champ "Fix version/s" peut également être rempli avant que le bogue soit corrigé. Il indique alors la version de Moodle pour laquelle vous avez l'intention de régler le problème. Vous pouvez alors y indiquer toute version future. Par exemple, dans le cas précédent, si vous pensez résoudre le problème dans la branche 1.9 stable sans que cela soit une urgence, vous pouvez indiquer la version 1.9.2. Lorsque le bogue sera effectivement corrigé, mettez ce champ à jour si nécessaire.

Tester les bogues

Tous les utilisateurs de Moodle sont encouragés à participer activement au test de Moodle, et à son amélioration. Quiconque ayant un compte sur le traqueur peut rapporter, voir, commenter, suivre ou voter pour des bogues. Si vous constatez des problèmes ou des bogues, si vous avez des idées d'améliorations ou souhaitez que de nouvelles fonctionnalités soient ajoutées à Moodle, alors ajoutez un bogue au traqueur.

Un groupe de testeurs a été mis en place pour le traqueur. Il est chargé de vérifier l'efficacité des modifications apportées par les développeurs. Ces testeurs ont, dans le traqueur, une autorité et des responsabilités accrues. Ces personnes ont généralement une bonne connaissance de Moodle et sont actifs dans la communauté. Évidemment, les testeurs sont sensés avoir les compétences et connaissances suffisantes pour réaliser les tests - l'expérience compte - mais il ne faut pas perdre de vue que d'autres membres de la communauté peuvent prêter main forte. Si vous souhaitez rejoindre l'équipe de testeurs, faites vous connaitre en déposant une demande à travers le traqueur. Nous vous accueillerons dans l'équipe avec plaisir ! Vous pouvez déposer votre demande sur le site du traqueur de Moodle.

Tester un bogue dans le traqueur

Remarque : voici la procédure à suivre par les membres de l'équipe des testeurs avant de basculer les bogues de l'état "Resolved" à l'état "Closed".

  • Les testeurs testent les bogues dont l'état est 'Resolved'. Des filtres ont été créés pour chaque version (tel que 1.7 Resolved) pour simplifier leur recherche.
  • Utilisez le champ QA Assignee pour vous identifier comme testeur d'un bogue en particulier.
  • Il serait bon d'ajouter votre nom à la liste de suivi pour tous les bogues que vous testez (voir Liste de suivi infra)
  • Si le bogue réussit le test, alors vous pouvez le clôturer grâce au bouton "Close Issue". Dans le champ Comments il vous faut décrire votre méthode de test, les problèmes rencontrés, etc...
  • Si le bogue échoue au test ou si le correctif vous semble incomplet, réouvrez le bogue grâce au bouton Reopen Issue. Vérifiez que le bogue est bien assigné au bon développeur. Travaillez ensuite avec ce dernier pour trouver une solution acceptable.
  • Une version est considérée prête quant tous ses bogues sont clôturés.
  • Tous les bogues corrigés doivent être testés. Les bogues "fixed" sont ceux pour lesquels le code a été mis à jour. Leur traitement est plus ardu que ceux portant la mention "duplicate", "won't fix", "not a bug" ou "can't reproduce".
  • Avant de clôturer un bogue, assurez-vous qu'il porte bien la mention de résolution qui convient. En effet, il n'est pas aisé de modifier cette mention une fois que le bogue est clôturé (il faut alors le ré-ouvrir).
  • N'hésitez pas à discuter de vos tests avec le développeur en charge du bogue. Comme il reçoit une notification des changements effectués sur le traqueur, le simple ajout d'un commentaire devrait attirer son attention.

Plus d'informations sur les fonctionnalités du traqueur

  • Vous recevrez un courriel après avoir signalé un nouveau bogue ou mis à jour ceux que vous avez précédemment signalés. Vous recevrez également une notification des mises à jour des bogues que vous suivez (voir infra les explications sur le suivi des bogues).
  • Vous pouvez effectuer un suivi des bogues signalés par d'autres. Pour ce faire, consultez le bogue puis choisissez "Watch it", sur le panneau de navigation à gauche de l'écran. Vous recevrez alors une notification par courriel des mises à jour apportées à ce bogue.
  • Le traqueur permet à ses utilisateurs de lier les bogues entre eux. Il existe plusieurs types de liens :
duplicates - Les doublons sont inévitables dans un projet de la taille de Moodle. Ils apparaissent lorsqu'on décrit un problème sans savoir qu'il fait déjà l'objet d'un bogue identifié. Utilisez duplicates pour lier le bogue soit à celui déjà enregistré, soit à celui le mieux le problème. Tous les doublons devraient être liés entre eux.
blockers - Utilisez ce lien pour identifier des bogues empêchant de corriger d'autres bogues.
cloners - Parfois, les doublons sont volontairement créés pour retracer les correctifs du bogue apportés dans une branche particulière du code. Ceci n'est pratiquement jamais utilisa pour Moodle.
relates - A utiliser pour identifier un bogue en relation avec un autre bogue.
Les liens sont bidirectionnels, ils ont donc des "origines" et des "destinations". C'est pourquoi vous verrez les indications "blocks/is blocked by" (bloque/est bloqué par) ou "duplicates/isduplicates by" (doublonne/est doublonné par) dans la liste déroulante des liens Link Issue. Ne vous préoccupez pas trop de savoir quel est le "bon" sens du lien ; ils fonctionnent de façon similaire.
N'hésitez pas à lier les bogues entre eux. Les développeurs et les testeurs apprécient d'avoir un tableau complet du problème.
  • Votez pour les bogues que vous souhaitez souligner. Tout utilisateur peut voter. Pour ce faire, rendez-vous sur le bogue en question et choisissez "Vote for it" dans le panneau de navigation de gauche. Les développeurs tiennent compte du nombre de votes pour comparer l'importance des bogues.
  • Le tableau blanc du traqueur est flexible et adaptable selon vos centres d'intérêt. Pour les instructions de configuration du tableau blanc, cliquez ici (anglais).
  • L'explorateur du traqueur permet de filtrer et de trouver les bogues. Pour les instructions à ce sujet, cliquez ici (anglais).
  • La fonction de recherche rapide du traqueur est expliquée ici (anglais).

Groupes et permissions du traqueur

Les utilisateurs standard [groupname=jira-user] - Il s'agit du groupe par défaut. Les nouveaux utilisateurs y sont rattachés dès la création de leur compte. Réciproquement, il faut appartenir à ce groupe pour s'identifier sur le traqueur. Les membres de ce groupe peuvent parcourir les bogues, en ajouter de nouveaux, les commenter, ajouter des pièces jointes, créer des sous-tâches, créer les filtres, suivre les bogues, et voter. Ils peuvent également résoudre les bogues (préalable nécessaire à leur clôture) qui ne sont plus pertinents (doublons, signalements par erreurs). Les membres de ce groupe configurer leur espace de travail dans le traqueur grâce au bouton "Configure your Issue Navigator". Ceci leur permet de voir les listes de suivi et les listes de votes, ainsi que de gérer leurs préférences, leur profil et leur mot de passe.


Les développeurs [groupname=jira-developer] - Les développeurs peuvent faire tout ce que les utilisateurs standard peuvent faire. En outre, ils disposent de fonctionnalités supplémentaires sur les bogues : ils peuvent les dupliquer, les clôturer, les modifier, les lier et les assigner. Les membres de ce groupe ont également accès à une fonction de modification en masse, qui permet de mettre à jour plusieurs bogues simultanément.


Les testeurs [groupname=moodle-testers] - Les testeurs peuvent faire tout ce que peuvent faire les développeurs.


Le groupe de sécurité Moodle [groupname=moodle-security] - Il comporte des développeurs et administrateurs de confiance qui travaillent sur les problèmes de sécurité de Moodle.


Remarque : vous pouvez tout à fait parcourir le traqueur sans y être identifié. En revanche, il vous sera impossible de modifier ou de commenter les bogues.

Comment bien signaler les bogues

Les bons rapports de bogue incluent ces éléments (dans le champ Description), en anglais afin d'être compris par les développeurs :

  1. Steps to reproduce. Une liste détaillée d'étapes à effectuer pour reproduire le problème. Il est très difficile de corriger un bogue que l'on ne peut pas reproduire. Si possible, fournissez une URL qui permettrait de voir le problème d'un seul click.
  2. What I expected to happen. Ce que vous vous attendiez à obtenir comme résultat, en fournissant encore autant de détails que possible. Vos explications peuvent mettre en évidence des explications insuffisantes, ou une interface utilisateur à améliorer.
  3. What actually happened le résultat qui a été effectivement obtenu (avec des détails).

Voici quelques exemples de bons rapports de bogue : MDL-6030, MDL-5688 et MDL-12505.

  • Si vous avez un message d'erreur, ou d'information dans vos fichiers journaux de PHP ou du serveur Web, faites-en une copie dans le rapport de bogue. Si vous pouvez, activez "debug" dans la page d'administration avant de reproduire le problème pour obtenir le meilleur message d'erreur possible.
  • Les captures d'écran sont très utiles pour certains bogues, mais veuillez tout de même écrire une description textuelle du problème.
  • Assurez vous de fournir tous les éléments que nous devons connaitre sur votre configuration, y compris le système d'exploitation, la bases de données... Si vous manquez de place dans la section de l'environnement, ajoutez plus de détails dans la description. Les informations qui pourraient être utiles :
    • Système d'exploitation du serveur (et numéro de version)
    • Serveur Web utilisé (et numéro de version)
    • Version PHP utilisée (et si vous utilisez un accélérateur)
    • Base de données utilisée (et numéro de version)
    • Version de Moodle (il y a un menu déroulant en haut du formulaire, si vous ne trouvez pas ce que vous voulez, ajoutez le dans la description)
    • Système d'exploitation utilisé côté client (et numéro de version)
    • Navigateur Web utilisé (et numéro de version)

Vous n'avez pas toujours besoin de donner tous ces détails. Par exemple, pour un problème de rendu, seuls le système d'exploitation et le navigateur utilisés côté client sont nécessaires. S'il s'agit un problème côté serveur, les informations détaillées du serveur peuvent être nécessaires. A vous de juger. Voici quelques exemples (laissés en anglais) :

I see this bug with the latest Moodle HEAD running on PHP5.1.2/Apache 2.2.3 on Linux. My database is Postgres 8.1.
This rendering problem happens using Internet Explorer 6.0 on Windows XP.

En résumé, tenez vous en aux faits, et présentez suffisamment de détails pour que le problème soit reproductible par quelqu'un d'autre.

Commentaires des développeurs

"Qu'est-ce qui est le plus difficile avec un rapport de bogue ?" La plupart du temps, résoudre le problème est le plus simple, le plus compliqué étant d'arriver à reproduire le bogue. En effet, le développeur doit pouvoir bien comprendre d'où vient le problème, pour le corriger. Si les développeurs ne peuvent pas reproduire les bogues, ils ne pourront pas les corriger !

Les bons rapports de bogues comportent autant de détails que possible et sont précis. Ne généralisez pas ou ne tirez pas de conclusion hâtive.

Par exemple , un rapport de bogue disant simplement "Le flux RSS ne supporte par l'UTF-8" est inutile. Le développeur sait que l'UTF-8 et les flux RSS sont incompatibles. Mais il n'a aucune idée de ce que la personne voit et de pourquoi elle signale ce bogue. Il a donc plus de mal à déterminer le problème rencontré.

Préférez donc un rapport de bogue indiquant que, dans le flux XYZ@abc, s'affichent des caractères illisibles et non ceux prévus.

Voir aussi