Le 03.06.2010 09:12, Cédric Bosdonnat a écrit : > Bonjour Bruno, > > Le mercredi 02 juin 2010 à 21:48 +0200, Bruno Friedmann a écrit : > >> C'est même souvent mieux, c'est mon cas avec openSUSE, >> Comme c'est super facile de remonter les bugs chez eux, et l'équipe en >> charge remonte upstream sur oogo. >> > Je sais, je fait partie de cette equipe aussi ;) > > >> Bon je parle et écris l'anglais : ce qui est souvent un frein pour >> l'utilisateur de base. >> Mais très souvent c'est nécessaire, et en plus il y a souvent des >> confirmations ou expérimentations supplémentaires à faire. >> (et la ça dépasse souvent la compétence de l'utilisateur lambda ... ) >> > Merci beaucoup pour ton aide. N'hesite pas a motiver d'autres personnes > de ton entourage pour mieux repartir le travail. > > JBF, Gilles: comment utiliser au mieux les outils du projet francophone > pour lancer cette equipe? > > A bientot, > > Bonjour Cédric et tous,
Vous voudrez bien m'excuser d'avoir tardé à répondre mais j'étais en déplacement cette semaine. Tout d'abord je veux remercier Cédric pour cette excellente initiative. Pour moi l'outil de base devrait être la liste qa-t...@fr avec éventuellement des relais sur d...@fr. Actuellement le travail de remontée des problèmes signalés sur us...@fr n'est pas formalisé, il repose sur l'initiative de ceux qui suivent la liste d'entraide. La difficulté est qu'il faut faire la distinction entre ce qui est un bug entre la chaise et le clavier et ce qui est possiblement un bug de OOo et donc demande quelques tests plus approfondis. Je pense qu'une première étape pour constituer une telle équipe serait de faire le point sur les participants intéressés avec les informations suivantes : - le ou les OS sur lesquels ils peuvent réaliser des tests complémentaires avant de remonter un bug sur IZ - le ou les modules qu'ils pratiquent le plus, voire même les compétences inter-modules spécifiques, telles que le publipostage, l'utilisation de documents maître, la liaison avec des données externes, le déploiement de OOo, l'écriture de macro, etc. - s'ils ont ou non le droit "canconfirm" sur IZ. Par ailleurs, afin de ne pas remonter des bugs déjà connus, il est utile de se tenir au courant des nouveaux bugs rapportés sur IZ. Il existe un fil RSS qui fournit la liste des nouveaux rapports de bugs 2 fois par jour. On trouve ce fil sur le planet OOo (http://planet.services.openoffice.org/) dont le lien est disponible sur la page d'accueil du site FR. Sur le plan procédural, je pense qu'il y a deux étapes, la première relève de sentinelles sur la liste us...@fr (mais aussi peut-être ailleurs) qui d'une part détectent les possibles bugs et envoient une alerte sur qa-t...@fr pour approfondissement et d'autre part informent la liste us...@fr quand un bug déjà connu est rapporté qu'il s'agit en effet d'un bug connu. La seconde étape se passerait plutôt sur qa-t...@fr avec un travail de précision du scénario de reproduction du défaut, une recherche de doublon sur IZ et enfin, si nécessaire, un rapport sur IZ, confirmé par quelqu'un ayant le droit "canconfirm". Voilà mon point de vue pour le moment. Qu'en pensez-vous ? Bonne journée JBF -- Seuls des formats ouverts peuvent assurer la pérennité de vos documents.
