« 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
Aucun résumé des modifications
 
(5 versions intermédiaires par 3 utilisateurs non affichées)
Ligne 1 : Ligne 1 :
[[Catégorie:Accessibilité]]
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.
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.


Ligne 7 : Ligne 8 :
Il y a donc deux manières de procéder:
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 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.
* 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:
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.
* 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 se produit, c'est-à-dire le comportement erroné
- ce qui aurait dû se produire, c'est-à-dire le comportement attendu.
* 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.
* é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 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. Vous n'êtes pas obligé d'affecter le bug à une personne ou choisir les observateurs: les animateurs, une fois qu'ils ont connaissance de votre demande, se chargeront de cette tâche. Remplissez simplement le sujet et la description, on peut se charger du reste.


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.

Dernière version du 4 août 2011 à 00:40

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. Vous n'êtes pas obligé d'affecter le bug à une personne ou choisir les observateurs: les animateurs, une fois qu'ils ont connaissance de votre demande, se chargeront de cette tâche. Remplissez simplement le sujet et la description, on peut se charger du reste.

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