WordPress 3

Participer à l'amélioration de WordPress
475
• Type. Trac permet de classer les tickets par type ; donc précisez bien si votre rapport
concerne un défaut que vous avez repéré (defect), une amélioration que vous suggérez
(enhancement), une fonctionnalité que vous voudriez voir apparaître (feature request),
ou une tâche générale à accomplir (task, réservée aux développeurs de WP).
• Description. C’est le rapport de bogue lui-même. N’hésitez pas à présenter les étapes
pour reproduire le problème, à donner les détails de votre hébergement si besoin est,
voire à faire un lien vers une page présentant le bogue. Détails, détails, détails…
• Priority. Accessible uniquement aux développeurs, il indique une estimation de l’urgence
du bogue : très basse (lowest), basse (low), normale (normal), haute (high), et
"très haute mondieu onvatousmourir" (highest omg bbq).
• Component. Indiquez à quel composant de WordPress s’applique votre ticket : il y en
a 61 à l’heure actuelle, et de nouveaux composants peuvent être ajoutés ou enlevés en
fonction des besoins du moment. Indiquez bien le composant le plus adéquat à votre
rapport, sans quoi il se verrait assigné au mauvais développeur, avec la perte de temps
que cela implique.
• Severity. Il s’agit ici d’indiquer la portée de votre rapport de bogue et la facilité du correctif
qu’il implique : très simple (trivial), facile (minor), normale (normal), demande
du travail (major), très important (critical), on ne peut pas sortir de nouvelle version de
WordPress tant que ce bogue n’est pas résolu (blocker). Il vaut mieux laisser à "normal",
que les développeurs évaluent eux-mêmes l’importance du bogue.
• Assign to. Désigne un développeur responsable de la résolution de ce bogue. Si vous
savez qui est en charge de la portion de code en question, mettez son pseudonyme. Si
vous voulez gérer le code vous-même, mettez le vôtre. Sinon laissez le champ vide.
• Milestone. Accessible uniquement aux développeurs, cette section indique la version de
WordPress dans laquelle ce bogue devrait être résolu. Cela permet de prévoir le travail
à accomplir pour une version – mais, si le bogue n’est pas corrigé, les développeurs
peuvent choisir de le reporter à une version suivante.
• Version. La version de WordPress dans laquelle vous avez découvert le bogue. Idéalement,
vous avez testé la toute dernière version stable de WordPress, ou la version en
cours de développement (trunk) ; si c’est le cas, mettez le numéro de version dans ce
champ ; sinon laissez-le vide.
• Keywords. Liste de mots-clefs permettant d’identifier rapidement le bogue. Les motsclefs
doivent être séparés par une virgule. Évitez d’en mettre plus de deux, et restez
concis. Par exemple, "posting" indique que le bogue s’applique aux fonctions relatives
à la mise en ligne. Les développeurs sont susceptibles d’ajouter d’autres mots-clefs, ce
qui leur permet de mieux trier les tickets : reporter-feedback (besoin de plus d’informations),
needs-patch (ce bogue a besoin d’un correctif), has-patch (un correctif est prêt),
needs-testing (le correctif doit être vérifié), 2nd-opinion (besoin d’un avis supplémentaire
sur le bogue ou le correctif), tested (un des correctifs a été testé), etc. De fait, si
vous avez un correctif à proposer pour un ticket, n’oubliez pas d’ajouter le mot-clef
has-patch, vous attirerez ainsi l’attention d’un développeur…
customer 27921 at Fri Mar 11 19:29:26 +0100 2011
Propriété de Albiri Sigue