Bug management/Bug report life cycle/fr

Cette page décrit la vie d'une tâche (rapport de bogue, demande de fonctionnalité, etc.) dans.


 * Lorsqu'une tâche est créée initialement, elle est à l'état Open, c'est à dire ouverte.
 * Quand vous commencez à travailler activement sur cette tâche, l'état peut être mis à In Progress pour indiquer qu'elle est en cours.
 * Si un développeur décide de travailler sur une tâche, idéalement cette tâche lui est assignée.
 * If an initial patch for a task has been put into the Gerrit code review tool, the project Patch-For-Review is automatically added to the task. (Voir .)
 * Fermer une tâche :
 * Une tâche reçoit l'état Resolved quand elle est résolue c'est à dire une fois que la modification de code qui corrige la tâche a été fusionnnée dans Gerrit. Cela ne veut pas dire que la correction soit immédiatement disponible sur un site Wikimedia car cela peut prendre jusqu'à deux semaines.
 * A task is given the Declined status when the problem can not be reproduced, when missing information has not been provided, or when an acceptable workaround exists to achieve a similar outcome as requested. Cet état est également utilisé quand il y a eu un consensus pour implémenter une tâche particulière et que c'était une mauvaise idée. For example, when a task contradicts a particular project's scope or the principles of the project and fixing would be barred from approval by the project's maintainers (or product managers, if existing). Depending on the specifics, a user preference, a global configuration variable, a re-implementation, or forking the code can be alternatives to marking a task as declined.
 * A task is given the Invalid status when the task does not describe an actual wrong behavior, or when it is a change that is outside the power of the component's developers. For example, tasks proposing changes to third-party software or third-party website settings are INVALID, as well as requests contrary to legal or contractual obligations.
 * Une tâche reçoit l'état Duplicate lorsqu'elle présente un doublon avec une tâche qui a déja été rapportée précédemment et qui a été fusionnée dans une autre tâche, peu importe si celle-ci a déja été résolue ou pas.
 * Le mot-clé Verified est facultatif et il est mis pour indiquer qu'un testeur qualité, ou que l'auteur de la tâche, a confirmé la correction fusionnée dans Gerrit après son déploiement.
 * If a task was marked as Resolved and it turns out that this was incorrect, the task's status can be changed back to Open.
 * If a task is waiting for further input (e.g. from the task author or a third party like upstream) and can currently not be acted on, the Stalled status is temporarily given. The Stalled status can also be given when a task is waiting for its subtask(s) to be resolved first.



Finaliser des tâches
Different teams complete the work on tasks differently, see. Some move it to a Done column on a project workboard after QA and product management have reviewed the change, and only change the task status to Resolved when they complete the current "sprint" or when the code is available in production. Others change the task status to Resolved the moment a code change that completes a task is merged, leaving its tags and workboard column unchanged.



Quand utiliser la correction
Une réponse courte pour les sites Wikimedia est : entre une et trois semaines après que la tâche soit passée à l'état Resolved. Pour les détails, voir Deployments.