https://wiki.april.org/api.php?action=feedcontributions&user=89.234.168.40&feedformat=atomApril MediaWiki - Contributions de l’utilisateur [fr]2024-03-29T06:59:23ZContributions de l’utilisateurMediaWiki 1.35.13https://wiki.april.org/index.php?title=Faire_remonter_les_rapports_de_bugs_d%27accessibilit%C3%A9&diff=41465Faire remonter les rapports de bugs d'accessibilité2011-07-13T09:05:55Z<p>89.234.168.40 : correction liste</p>
<hr />
<div>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.<br />
<br />
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.<br />
<br />
Pour gérer cela, nous avons [https://agir.april.org/projects/accessibilite notre propre gestionnaire de bugs].<br />
<br />
Il y a donc deux manières de procéder:<br />
<br />
* 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<br />
* 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.<br />
<br />
Pour rappel, un rapport de bug idéal décrit:<br />
<br />
* 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.<br />
* ce qui se produit, c'est-à-dire le comportement erroné<br />
* ce qui aurait dû se produire, c'est-à-dire le comportement attendu.<br />
* é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.<br />
<br />
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.<br />
<br />
Il y a un [[Didacticiel Redmine]] pour vous aider à prendre l'outil en main.</div>89.234.168.40https://wiki.april.org/index.php?title=Faire_remonter_les_rapports_de_bugs_d%27accessibilit%C3%A9&diff=41464Faire remonter les rapports de bugs d'accessibilité2011-07-13T09:05:06Z<p>89.234.168.40 : correction lien</p>
<hr />
<div>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.<br />
<br />
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.<br />
<br />
Pour gérer cela, nous avons [https://agir.april.org/projects/accessibilite notre propre gestionnaire de bugs].<br />
<br />
Il y a donc deux manières de procéder:<br />
<br />
- 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<br />
- 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.<br />
<br />
Pour rappel, un rapport de bug idéal décrit:<br />
<br />
- 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.<br />
- ce qui se produit, c'est-à-dire le comportement erroné<br />
- ce qui aurait dû se produire, c'est-à-dire le comportement attendu.<br />
- é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.<br />
<br />
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.<br />
<br />
Il y a un [[Didacticiel Redmine]] pour vous aider à prendre l'outil en main.</div>89.234.168.40https://wiki.april.org/index.php?title=Faire_remonter_les_rapports_de_bugs_d%27accessibilit%C3%A9&diff=41463Faire remonter les rapports de bugs d'accessibilité2011-07-13T09:04:32Z<p>89.234.168.40 : </p>
<hr />
<div>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.<br />
<br />
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.<br />
<br />
Pour gérer cela, nous avons [https://agir.april.org/projects/accessibilite notre propre gestionnaire de bugs].<br />
<br />
Il y a donc deux manières de procéder:<br />
<br />
- 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<br />
- 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.<br />
<br />
Pour rappel, un rapport de bug idéal décrit:<br />
<br />
- 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.<br />
- ce qui se produit, c'est-à-dire le comportement erroné<br />
- ce qui aurait dû se produire, c'est-à-dire le comportement attendu.<br />
- é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.<br />
<br />
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.<br />
<br />
Il y a un [Didacticiel Redmine] pour vous aider à prendre l'outil en main.</div>89.234.168.40https://wiki.april.org/index.php?title=Faire_remonter_les_rapports_de_bugs_d%27accessibilit%C3%A9&diff=41462Faire remonter les rapports de bugs d'accessibilité2011-07-13T08:58:25Z<p>89.234.168.40 : Nouvelle page : 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...</p>
<hr />
<div>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.<br />
<br />
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.<br />
<br />
Pour gérer cela, nous avons [[https://agir.april.org/projects/accessibilite|notre propre gestionnaire de bugs]].<br />
<br />
Il y a donc deux manières de procéder:<br />
<br />
- 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<br />
- 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.<br />
<br />
Pour rappel, un rapport de bug idéal décrit:<br />
<br />
- 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.<br />
- ce qui se produit, c'est-à-dire le comportement erroné<br />
- ce qui aurait dû se produire, c'est-à-dire le comportement attendu.<br />
- é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.</div>89.234.168.40https://wiki.april.org/index.php?title=Accessibilit%C3%A9_et_logiciels_libres&diff=41461Accessibilité et logiciels libres2011-07-13T08:47:29Z<p>89.234.168.40 : /* Contribuer dans le groupe */</p>
<hr />
<div>[[Image:April-logo-accessibilite_carre.png|center|130px|Logo carré du groupe de travail April accessibilité et logiciels libres au format PNG, 77ko]]<br />
<br />
{{Introduction|Le groupe de travail April accessibilité et logiciels libres vise à promouvoir l'accessibilité numérique dans le monde du Libre et à encourager l'utilisation de logiciels libres auprès des utilisateurs handicapés et des professionnels du handicap. Il est ouvert à tous. Voir le portail [http://libre-et-accessible.org libre-et-accessible.org]}}<br />
<br />
__TOC__<br />
<br />
== Présentation du groupe de travail "Accessibilité et logiciels libres" ==<br />
Le groupe de travail a commencé à prendre vie au cours des Rencontres Mondiales du Logiciel Libre à Nantes en juillet 2009. Partant du constat d'une méconnaissance mutuelle entre le monde du Libre et celui du handicap, le groupe de travail a été imaginé dans une perspective d'échanges pluridisciplinaires pour réconcilier ces deux univers et accroître la diffusion de '''logiciels libres et accessibles à tous'''.<br />
<br />
Un des objectifs est d'aborder la question du Libre et du handicap dans toute sa diversité et sa complexité et d'y associer la participation du plus grand nombre, issus de tous horizons, membres ou non de l'April.<br />
<br />
Pour participer, vous pouvez vous inscrire sur notre liste de discussion et participer aux échanges sur [http://www.april.org/wws/info/accessibilite la liste accessibilite].<br />
Nous vous invitons à lire les [[Charte liste de discussion | règles de bon usage des listes de discussion]] pour participer au mieux.<br />
<br />
=== En bref : Infos sur le groupe ===<br />
* Page de présentation du [http://www.april.org/groupes/accessibilite groupe Accessibilité et logiciels libres sur le site de l'April]<br />
* [http://www.april.org/wws/arc/accessibilite Archives de la liste de discussion accessibilite@april.org]<br />
* [[Charte du groupe de travail Accessibilité et logiciels libres]]<br />
* [http://www.april.org/fr/quatre-questions-a-armony-altinier-sur-le-groupe-accessibilite-et-logiciels-libres Quatre questions à Armony Altinier]<br />
<br />
* [[Nomenclature_des_groupes_de_travail#DT08_:_Accessibilit.C3.A9.2Fhandicap|Nomenclature et responsables]]<br />
** Animatrice : Armony Altinier<br />
** Suppléants : Christelle Thomas, Sylvain Grille, Jean-Philippe MENGUAL<br />
** Coordinateur au Conseil d'administration de l'April : François Poulain<br />
==== Nous contacter ====<br />
Par courriel : [mailto:accessibilite@april.org accessibilite@april.org]<br />
<br />
=== Activités du groupe de travail===<br />
* [[Bilans du groupe de travail accessibilité]] : Retrouvez une liste des actions menées par le groupe de travail, classées par année.<br />
* [[Conférences April sur l'accessibilité et le logiciel libre]] : liste des conférences données par des membres du groupe et présentant l'accessibilité, le logiciel libre et les activités du groupe de travail April.<br />
<br />
== Contribuer dans le groupe==<br />
* [[Liste de discussion du groupe accessibilité | Partager ses infos, questions et connaissances sur la liste accessibilite@april.org]] : '''Merci de lire cette page avant toute contribution sur la liste.'''<br />
* [[Wiki du groupe de travail accessibilité et logiciels libres | Mettre à jour le Wiki du groupe]] : Le Wiki est un espace de travail collaboratif. Il est ce que vous en ferez. '''Chacun peut contribuer''', pensez à partager vos ressources !<br />
*[[Présenter le groupe de travail accessibilité et logiciels libres]]<br />
* [[Faire remonter les rapports de bugs d'accessibilité]]<br />
<br />
==Projets en cours==<br />
*[[Audition et logiciels libres]]<br />
* [[Vidéo accessibilité et logiciel libre]]<br />
* [[Fiches pratiques et livre blanc]]<br />
* [[Projet de sensibilisation des MDPH]]<br />
<br />
== Boîte à outils ==<br />
Vous trouverez ci-dessous des ressources utiles pour communiquer sur l'accessibilité, le logiciel libre et le groupe de travail.<br />
* [[Carte de visite du groupe de travail accessibilité et logiciels libres]]<br />
* [[Flyer Accessibilité et logiciels libres]]<br />
* [[Logo du groupe de travail accessibilité et logiciels libres]]<br />
* [[Technologies d'assistance libres | Logiciels libres d'accessibilité]] : liste de logiciels libres utiles pour compenser un handicap, appelés également technologies d'assistance.<br />
* [[Tutoriels d'accessibilité]]<br />
* [[Panneau résumé des logiciels libres pour l'accessibilité]]<br />
<br />
==Agenda / Rencontres 2011==<br />
Liste des évènements que le groupe de travail organise ou auxquels des membres du groupe participent pour le présenter.<br /><br />
Pour voir la liste des [[Bilans du groupe de travail accessibilité | rencontres antérieures, se reporter aux bilans du groupe de travail]].<br />
<br />
* 15 janvier 2011 : [[BarCamp accessibilité et logiciels libres 2011 | site officiel des RMLL]] à la Cité des Sciences et de l'Industrie à Paris.<br />
* 11-13 juillet 2011 : [http://2011.rmll.info Rencontres Mondiales du Logiciel Libre] à Strasbourg. [http://wiki.april.org/w/Reunion_rmllstrasbourg2011 | page wiki de la réunion]<br />
<br />
==Ressources==<br />
===Ressources générales===<br />
* [[Technologies d'assistance libres | Logiciels libres d'accessibilité]] : liste de logiciels libres utiles pour compenser un handicap, appelés également technologies d'assistance.<br />
*[[Accessibilité numérique : tentatives de définition]]<br />
*[[FAQ_Accessibilité| Foire Aux Questions (FAQ) Accessibilité et logiciel libre]]<br />
* [[Logiciels libres de gestion de sites Web et accessibilité]]<br />
* [[Ressources documentaires sur l'accessibilité et le logiciel libre]]<br />
* [[Glossaire accessibilité et logiciels libres]]<br />
* [[Activités de recherche]]<br />
<br />
===Traduction d'articles===<br />
* Traduction de l'[[Appel de la FSF pour l'accessibilité]]<br />
*[[Lettre de l'Institut national d'Islande pour les aveugles à Freedom Scientific]]<br />
*[[Plaidoyer pour l'utilisation de technologies d'assistance libres et open source]]<br />
<br />
=== Améliorer l'accessibilité des logiciels libres ===<br />
*[[Rapport de bugs accessibilité logiciels libres]]<br />
*[[Groupe Ubuntu-accessibility]]<br />
*[http://fr.dotclear.org/blog/feed/atom/comments/929 Wikimedia et accessibilité]<br />
*[http://fr.dotclear.org/blog/post/2010/07/17/Accessibilit%C3%A9-et-refonte-de-l-administration Dotclear et accessibilité]<br />
<br />
[[Catégorie:Groupe de travail]] [[Catégorie:Accessibilité]]</div>89.234.168.40