« Faire remonter les rapports de bugs d'accessibilité » : différence entre les versions

De April MediaWiki
Aller à la navigationAller à la recherche
Aucun résumé des modifications
(correction lien)
Ligne 19 : Ligne 19 :
Il vaut mieux se créer un compte sur le gestionnaire de bugs, pour recevoir par mail les nouvelles à propos des bugs que l'on a soumis, ou que l'on a demandé à suivre.
Il vaut mieux se créer un compte sur le gestionnaire de bugs, pour recevoir par mail les nouvelles à propos des bugs que l'on a soumis, ou que l'on a demandé à suivre.


Il y a un [Didacticiel Redmine] pour vous aider à prendre l'outil en main.
Il y a un [[Didacticiel Redmine]] pour vous aider à prendre l'outil en main.

Version du 13 juillet 2011 à 09:05

Un des aspects importants d'un logiciel libre est de faire remonter les problèmes jusqu'aux développeurs, pour qu'ils soient au courant de ces problèmes et les corrigent "en amont", c'est-à-dire à la racine du code source, pour qu'ensuite toutes les distributions Linux puissent en profiter automatiquement.

Idéalement, la personne qui a un problème va rapporter le bug directement sur le gestionnaire de bugs du logiciel en question. Cependant, cette personne n'a pas forcément les compétences techniques ou linguistique (l'écrasante majorité des gestionnaires de bugs exigent un rapport en anglais). Il est donc utile de se mettre à plusieurs pour rapporter les bugs: pour apporter des détails techniques, ou faire passerelle français - anglais.

Pour gérer cela, nous avons notre propre gestionnaire de bugs.

Il y a donc deux manières de procéder:

- Si l'on est anglophone, on rapporte le bug directement dans le gestionnaire de bug du logiciel en question. On crée ensuite un nouveau bug dans notre gestionnaire de bugs, et l'on y met l'adresses du bug que l'on vient de soumettre, pour pouvoir le retrouver facilement - Si l'on n'est pas anglophone, on rapporte le bug en français dans notre propre gestionnaire de bugs, et l'on envoie l'adresse de ce bug sur la liste, pour lancer un appel à faire passerelle français - anglais.

Pour rappel, un rapport de bug idéal décrit:

- comment reproduire le bug, en expliquant en détails très précis toutes les actions effectuées. Ce n'est pas grave si c'est long: c'est moins pénible pour le lecteur de parcourir un long texte que de devoir réclamer des détails et attendre la réponse. - ce qui se produit, c'est-à-dire le comportement erroné - ce qui aurait dû se produire, c'est-à-dire le comportement attendu. - éventuellement, si l'on a trouvé un moyen de contourner le bug, à la fois pour les gens qui rencontrent le même problème, pour qu'ils puissent eux aussi le contourner en attendant qu'il soit corrigé, et éventuellement pour aider le développeur à trouver la source du bug.

Il vaut mieux se créer un compte sur le gestionnaire de bugs, pour recevoir par mail les nouvelles à propos des bugs que l'on a soumis, ou que l'on a demandé à suivre.

Il y a un Didacticiel Redmine pour vous aider à prendre l'outil en main.