Traqueur de bogues

Remarque : la traduction de cet article n'est pas terminée. N'hésitez pas à traduire tout ou partie de cette page ou à la compléter. Vous pouvez aussi utiliser la page de discussion pour vos recommandations et suggestions d'améliorations.

Le suivi des bogues est une part 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çais 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 "Create New Issue" depuis le menu sous le logo du Traqueur Moodle
• Depuis le menu déroulant, sélectionnez le "Issue type": Bug, New Feature, Task or Improvement
• 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 'Create' en bas de page pour créer le bogue.

Champs du traqueur

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

Projet - Champ exigé. Tracker is made of of multiple projects. At present there are 2: 'moodle' and 'moodle.org sites'. Specify 'moodle' for issues/bugs related to moodle software; specify 'moodle.org sites' for issues/bugs related to tracker.moodle.org, docs.moodle.org, demo.moodle.org, download.moodle.org, or moodle.org.

Issue Type - Champ exigé. Bugs are classified as 1 of the following:

Bug - A problem which impairs or prevents Moodle from functioning correctly.

Improvement - An enhancement to an existing Moodle feature.

New Feature - A new Moodle feature which has yet to be developed.

Task - A task that needs to be completed. Tasks usually refer to work that must be done outside the product.

Sub-Task - Issues are sometimes broken into multiple sub-tasks.

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

Niveau de sécurité - Champ optionnel. Specify if this bug or change has security implications for Moodle. Bugs with serious security implications are restricted so that only members of the moodle-security group can see them.

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

Blocker - Blocks development and/or testing work, production could not run.

Critique - Crashes, loss of data, severe memory leak.

Majeur - Major loss of function.

Mineur - Minor loss of function, or other problem where easy workaround is available.

Trivial - Cosmetic problem like misspelled words or misaligned text.

Composante/s - Champ exigé. Select the area in Moodle which is affected by this bug. Select 'Unknown' if you are unsure.

Affects Version/s - Champ exigé. This is the Moodle version in which the bug has been found. It is entered by the person logging the bug, and typically only 1 version is specified. Enter your current version when logging an 'improvement', 'task', or 'new feature' as this will help assess the state of the product when the request was made.

Assigned To - This is the person who will fix (code) the problem. This field is completed by developers or Component Leads.

Correspondant - The person who logs the bug. This field is automatically filled by Tracker.

Environnement - Specify the operating system, software platform and/or hardware specifications if applicable to this bug.

Description - A full and complete yet concise description of the problem or improvement.

Base de données - Champ optionnel. If applicable to the bug, identify the database type.

URL - Champ optionnel. If possible, provide a URL address that demonstrates an example of this bug.

QA Assignee - Used to designate the person who will test this bug.

Fixed Version/s - This is the Moodle version the bug was or will be fixed in. This field is normally completed by the developer when the bug has been resolved or by lead developers allocating bugs for a specific release. Normally only one version is specified in this field. It symbolises the first version of Moodle where the change will be seen.

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 512Kb.

Commentaire - The comment field is a detailed register of all changes that relate to this bug.

Résolution - This field is only displayed when resolving or closing a bug. Specify a code that best describes how this bug was resolved.

Fixed - Bug has been fixed; a code change will be checked into CVS. Use this resolution code only when actual changes were made to Moodle code.

Won't Fix - The problem described is an issue which will never be fixed.

Not a bug - This issue is not a bug; was logged in error. Use this code if the bug was fixed by another bug report or in some earlier Moodle version.

Dupliquer - The problem is a duplicate of an existing issue.

Incomplète - More information is needed to understand this bug.

Ne peut être reproduit - All attempts at reproducing this issue failed, or not enough information was available to reproduce the issue. Reading the code produces no clues as to why this behavior would occur. If more information appears later, please reopen the issue.

Reporté - The resolution to this bug will be deferred to a later release.

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".

• Bugs are assigned by developers or Component Leads.
• Developers modify or add code and check into CVS.
• Appropriate comments are added in Tracker. The bug's status is changed to Resolved by using the "Resolve Issue" button.
• You must indicate which version of Moodle the change will be included in using the Fix Version/s. You should use this to indicate which branch(es) you checked the fix into (example below).
• The only exception to not moving a bug to Resolved is if a developer believes there is no value in testing the issue, in which case the bug status can be changed to 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.

If you resolved the bug as Cannot reproduce, or Won't fix, etc. Then leave the Fix version blank.

If you resolve the bug as Duplicate, then create a link to the duplicate issue.

These Fix version/s are used to automatically build release notes (see the tabs on http://tracker.moodle.org/browse/MDL) so it is helpful if you can get this right, but don't lose sleep over it.

The Fix version/s filed can also be used before the issue is fixed, as a way of planning when you intend to fix the bug. In this case, you can use any future release. For example, in the situation above, if you have a bug that you think should be fixed on the 1.9 stable branch, but is not urgent, you could set the fix version to 1.9.2 - then when the bug is actually fixed, update that field as necessary.

Tester les bogues

Tous les utilisateurs de Moodle sont encouragés à être des participants actifs du test de Moodle, et de son amélioration. Anyone with a Tracker user account can log, view, comment on, vote, and watch bugs. If you find bugs or problems, have ideas for improvements, or want additional functionality added to Moodle, please log a bug in Tracker.

We've formalised a group of testers in Tracker who are responsible for verifying the accuracy of changes made by developers. These testers have responsibilities and authority in Tracker beyond that of standard users. Testers normally have a good understanding of Moodle, and are active in the Moodle community. Obviously testers should have the skills and knowledge to sufficiently test the issue - experience is important - but don't forget there are others in the Moodle community who may be willing to lend a hand. If you are interested in becoming a member of the Moodle Testing team, make yourself known by logging a request through Tracker. We'd love to have you join the team! Log your request at the Moodle.org Sites Tracker project.

Tester un bogue dans le traqueur

NB This is the process members of the moodle-testers group should follow to move bugs from 'resolved' to 'closed'.

• Testers test bugs with Status=Resolved. Global filters have been created based on upcoming releases (eg 1.7 Resolved) to make identification simple.
• Use the QA Assignee field to identify yourself as the tester of a particular bug.

• It's a good idea to add your name to the watch list for all bugs you test. (see "Tracker watch list", below.)
• If the bug passes testing, close the bug using the "Close Issue" button. You must add appropriate comments describing your testing methods, any issues that were found, etc.
• If the bug fails testing or if you feel the fix is incomplete, reopen the bug using the "Reopen Issue" button. Ensure the bug is assigned to the correct developer. Work with the developer to find a mutually agreeable resolution to the bug.
• A release will be deemed ready when all bugs fixed for a particular version have been closed.
• All resolved bugs should be tested. Bugs with a resolution code of "fixed" represent bugs where code has been updated, and probably represent more of a challenge than bugs with resoluton codes of duplicate, won't fix, and not a bug, and can't reproduce. Please ensure bugs have been closed with a proper resolution code. Unfortunately it's not easy to change a resolution code in Tracker once the bug has been resolved (the only way is to reopen, then re-resolve).
• Don't be afraid to discuss your testing with the developer assigned to the bug. Simply adding a comment should get the attention of the developer as they are notified of all changes.

Plus d'informations sur les fonctionnalités du traqueur

• You will receive an email when you log a new bug or make updates to bugs you've reported. You'll also receive notification when updates are made to bugs you're watching. Read on for more information on watching a bug.
• You can monitor, or "watch" bugs reported by others. To do this, open the bug, then select "Watch it" from the left hand navigation panel. To add others to the watchlist for your bug, open the bug, select the option "Watching" from the left hand navigation panel. These people will receive email notification when updates are made to this bug.
• Tracker provides a facility to Link bugs. Any user logged onto Tracker may link issues. Multiple link types are defined in the system; you will be required to select one when linking bugs. The following link types are available:

duplicates - duplicates are inevitable in a project the size of Moodle. They occur when a logger is unaware of an existing bug that describes the same problem. Use duplicates to link to the first or most comprehensively described instance of the problem. All duplicates should be linked together.

blockers - use this to identify bugs that block others from being fixed.

cloners - in some instances a duplicate bug is intentionally created in order to track the fix in another branch of the code - this almost never is used in the Moodle project.

dependency - often a fix is dependent on another bug being resolved first, on in a specific order.

relates - used to identify a bug that is somehow related to another bug.

Links are bi-directional meaning that there's a concept of 'inward' and 'outward' - it affects how linked bugs are displayed. This is why you'll see "blocks/is blocked by" or "duplicates/is duplicated by" in the drop down list of the Link Issue dialog. Don't become too concerned about using the "correct" link type - all link types work similarly.

Don't be afraid to link bugs. It's very helpful to developers and testers to get a complete picture of a problem.

• Vote for bugs you want to see addressed in Moodle. Any user can vote. To vote for a specific bug, browse to the bug, then select "Vote for it" from the left-hand navigation panel. Developers may consider the number of votes a bug has when weighing the merits of two or more bugs.

• The Tracker Dashboard is flexible and customisable depending on your area of interest. For instructions on configuring the Tracker dashboard click here.

• The Tracker Issue Navigator is used to find and filter bugs. For instructions on configuring the Issue Navigator click here.

• Tracker's Quick Search function is explained here

Groupes et permissions du traqueur

Standard Users [groupname=jira-user] - This is the default group. New user accounts are placed in this group at the time of creation, and users must be a member of this group in order to log into Tracker. Members of this group can browse bugs, create new bugs, comment on bugs, create attachments, create sub-tasks, create filters, watch bugs, and vote for bugs. Members of this group can also resolve bugs, which is primarily a way of closing bugs that are no longer relevant (eg duplicates, or logged in error). Standard Users can configure their Tracker workspace by using the "Configure your Issue Navigator" button. This feature allows users to view watch and voting lists and to manage preferences, profile, and password.

Developers [groupname=jira-developer] - Developers can do everything Standard Users can do. In addition they can clone bugs, close bugs, edit bugs, link bugs, and assign bugs. Members of this group can also use the Bulk Edit function which allows bulk updated to multiple bugs.

Testers [groupname=moodle-testers] - Testers can do everything a Developer can do.

Moodle Security groups [groupname=moodle-security] - Trusted developers and administrators who need to work on and learn about security issues.

NB You can browse a project while not logged in to Tracker, however you will be unable change/edit/comment on bugs.

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 !

Good bug reports contain as much detail as possible and are specific. Don't generalise or leap to conclusions.

For example, a bug report that only says "The RSS feed doesn’t support UTF-8" is not helpful. The developer knows that UTF-8 and RSS feeds are compatible. The developer has no idea of what the person sees and why they reported this bug. In this case more time and effort needs to be expended to determine the problem.

Consider a bug report which says that the descriptions for the specific RSS feed XYZ@abc shows unrecognisable characters rather than expected characters.

Voir aussi

• Jira Tracker is a slightly customised version of Atlassian's product
• Using Moodle How to manipulate Moodle developers forum discussion
• Wikipedia Definition of a bug
• en:Tracker development
• en:Getting Started with the Tracker