Bug management/Cycle de vie du rapport de bogue

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

• 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.
• Si un patch initial pour une tâche a été mis dans l'outil de relecture de code de Gerrit, le projet Patch-For-Review est automatiquement ajouté à la tâche. (Voir Gerrit/guide des messages Commit .)
• 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.
  • Une tâche reçoit l'état Declined quand elle est rejetée; c'est le cas lorsque le problème ne peut être reproduit, ou lorsqu'il n'y a pas assez d'informations en entrée, ou encore lorqu'il existe déjà une solution acceptable de contournement permettant d'obtenir un résultat similaire. 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. Par exemple, quand une tâche contrarie le but d'un projet particulier ou les principes du projet et que le correction est refusée pour relecture par les maintaineurs du projet (ou les gestionnaires du produit s'ils existent). En fonction des caractéristiques, une préférence utilisateur, une variable de configuration globale, un recodage, ou un fork du code peuvent être des alternatives pour marquer une tâche Declined.
  • Une tâche reçoit l'état Invalid lorsqu'elle décrit un mauvais fonctionnement qui ne corespond pas au fonctionnement actuel, ou lorsqu'elle demande une modification en dehors des possibilités des développeurs du composant; elle est alors dite non-valide. Par exemple, les tâches qui proposent des modifications dans les logiciels tiers ou dans les paramètres des sites web tiers sont INVALID, tout comme les requêtes contraires aux obligations légales ou contractuelles.
  • 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.
• Si une tâche a été marquée Resolved et qu'il s'avère que la correction est fausse, son état peut être remis à Open.
• Sur une tâche en attente d'informations complémentaires (par exemple de l'auteur de la tâche, ou d'une partie tierce telle que le flux upstream) il n'est pas possible d'intervenir et l'état Stalled est utilisé temporairement. L'état Stalled peut aussi être utilisé quand une tâche attend que sa ou ses sous-tâches soient d'abord résolues.

Finaliser des tâches

Chaque équipe réalise le travail sur les tâches à sa manière, voir Phabricator/Project management . Certaines équipes vont déplacer la tâche réalisée dans une colonne Done sur le tableau de bord du projet après que la qualité QA et la gestion du produit ont relu la modification, et passer uniquement l'état de la tâche à Resolved quand le sprint courant sera terminé ou que le code sera passé en production. D'autres équipes passent l'état de la tâche à Resolved dès l'instant qu'une modification de code qui finalise un tâche est fusionnée, laissant inchangées ses balises et la colonne du tableau des tâches.

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 wikitech:Deployments.