sorrodje
oulah ... Personnellement ce qui m'intéresse dans la démarche, c'est juste de mutualiser nos efforts .. A mon avis si on commence à dire que tel groupe fait en français et qu'il faut ensuite transmettre dans un autre coin mais pas trop sur le forum et plutot sur launchpad .. j'avoue que ça me parait complexe.
De mon point de vue :
le contexte :
- Aujourd'hui tout le monde reporte dans son coin.. il faut attendre que quelqu'un ( de n'importe où ) ait le même bug , fasse un rapport , découvre que le premier bug préexiste et se rattache en confirmant plutot que d'ouvrir un nouveau bug .. en bref .. c'est pas fiable.
- On est pas des pro du bug reporting ou tout du moins on a pas le même niveau de compétences . A quel paquet rattacher le bug ? bien utiliser ubuntu-bug ? comment décrire le bug ? comment l'écrire en anglais
Ces deux tendances de base rendent notre contribution individuelle peu efficace.
Objectif : sur une base zéro , amorcer une contribution coopérative sur la base des bonnes pratiques qui ont commencé à naitre sur Oneiric :
Méthode de base à consolider:
- On constate un bug chez soi
- On en cause sur le forum dans un topic dédié Bug pour que les autres intervenants reproduisent le bug.
- Identification du paquet concerné si nécessaire
- Recherche d'un rapport de bug préexistant sur le problème et souscription sinon :
- Reporting du bug via ubuntu-bug puis collage du lien dans le topic . y.c en français pour les non anglicistes.
- Relecture et amendement ( traduction si nécessaire , complément , commentaire , patch , workaround,... ) via les contributeurs du topic .
- Souscription au bug pour les utilisateurs atteints ( contributeurs ou lecteurs du topic ayant un compte launchpad )
En bref , on doit considérer qu'on débute depuis zéro et que ça c'est la base pour améliorer la qualité du reporting ... le reste me semble accessoire tant qu'on est pas bien calé sur cette méthode à mon avis . et un topic dédié suffit pour ça pour l'instant. Philosophie KISS 😉
Ensuite on voit ce qui a manqué dans la méthode et on avise sur quel outil peut être nécessaire pour améliorer le truc et pour aller plus loin dans les contributions mais dans l'état , je trouve préférable de rester sur l'essentiel , à savoir déjà arriver à bosser ensemble sur une tâche simple.
L'intérêt actuel de la team launchpad c'est à mon avis dans un premier temps de contribuer à la dynamique , de se montrer sur launchpad mais pas plus dans l'état actuel des choses. j'avoue queje n'ai pas encore saisi ce que ça apporte vraiment 🙂
My 2 cents d'utilisateur Michuesque 😉
darkevolution
L'intérêt du compte et des rapports sur launchpad c'est que c'est bien plus simple de gérer les rapports, de les modifier, etc...
Par contre si des gens veulent entrer un bug sur le forum (genre le petit nouveau qu'à pas de compte launchpad, ou autre), il faudra simplement qu'un membre de la team entre le bug sur launchpad.
Sans ça, ça risque d'être dur à gérer. (Si les gens s'y mettent et qu'on a 10 ou 15 rapport par jour :lol: )
Étant donné qu'on commence après l'alpha1 et que ça se compliquera plutôt vers la 2 ou la bêta, on aura un temps de mise en route confortable pour voir les problèmes.
Pour le nom, celui proposé va très bien.
Pour lier le bug "interne" du bug réel, ou pourrait juste mettre le lien du bug réel dans le bug interne (certes faut recopier et refaire le bug proprement, ça prend plus de temps qu'une simple affectation à un autre projet, mais ça sera plus clair, non ?)
Plus sérieusement pour le côté "choisir un gourou", vu la bonne ambiance, je suis pas certain que ce soit nécessaire, prendre plutôt les décisions d'un commun accord serait plus logique je trouve...
kao_chen
Sur le launchpad en créant un projet générique, on pourrait se servir de "Answers" pour rédiger en français et traduire les bugs.
exemple:
https://answers.launchpad.net/ubuntu
Ensuite les anglophones font le pont vers les vrai "bugs"
exemple:
https://bugs.launchpad.net/ubuntu
le module Answers est tout à fait adapté pour ça, on peut même uploader des fichiers logs.
Une question par bug
Malizor
@kao_chen : En pratique ça revient au même, non ?
Sauf que l’appellation « bug » est importante, on ne veut pas faire du support ailleurs que sur le forum. Les gens savent que « Answers » veut dire « Questions » 😉
Plus sérieusement pour le côté "choisir un gourou", vu la bonne ambiance, je suis pas certain que ce soit nécessaire, prendre plutôt les décisions d'un commun accord serait plus logique je trouve...
+1
Techniquement on aura tout de même besoin d'au moins un admin dans le groupe Launchpad mais ça ne sera pas un rôle particulier au niveau de la prise de décision. Si on a beaucoup de succès et/ou qu'il y a des conflits, on sera peut-être obligé de mettre plus de formes. Mais on en est pas encore là.
willy78
Launchpad me parais bien pour gérer une liste de bugs, mais il ne faudrait pas le traduire in-situ mais dans la discussion qui va avec, une fois le bug bien conscrit (paquet- reproduit etc...) une personne(affecté de préférence) le rédige sur le projet viser!
Laisser le bugs en français sur ubuntu-fr bugs squad me parait mieux et pourrai attiré des testeurs non anglophone.
Malizor
C'est aussi comme ça que je vois les choses.
(sur ce, à demain 😛)
kao_chen
@Malizor, je pensais à un abonnement aux bugs anglais dans la page "bug" et "answer" pour en discuter. Mais c'est peut être mieux de créer un nouveau bug enfrançais.
kao_chen
Là j'ai un bug qui ressemble à une wishlist, doit on les traiter aussi?
C'est pour ne plus avoir de corbeille caché sur les clés USB.
https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/12893
C'est un vieux bug mais toujours d'actualité...
Malizor
Ce bug est marqué comme étant corrigé chez Gnome (quand tu démontes la clef USB, on te demande si tu veux purger la corbeille).
Je pense qu'on pourrait s'occuper de ce genre de bug, car ils sont somme toute assez précis.
Par contre je suis plus réservé en ce qui concerne des demandes du genre « Il faudrait changer le dash pour faire ça, ajouter une barre ici, remplacer tel logiciel par tel autre… ».
Du moins il faudrait que ça soit bien discuté avant (sur le forum ou ailleurs) et qu'il y ai une sorte de consensus.
Par exemple, les suggestions design doivent être vraiment blindées (avec mock-up et tout) pour avoir une chance d'être prises en compte upstream. Ce que je veux dire c'est que ça serait une perte de temps de transmettre telles quelles toute les plaintes de type « opinion ».
kao_chen
Malizor a écritCe bug est marqué comme étant corrigé chez Gnome (quand tu démontes la clef USB, on te demande si tu veux purger la corbeille).
Pour moi ça suffit pas, si t'as clé est pleine et que tu veux ajouter un fichier, tu dois commencer pas vider ta clé.
Actuellement il faut:
-mettre ta clé
-supprimer des fichiers
-retirer la clé pour être sûr de libérer de la place, (ne pas le faire à la sauvage sinon ça ne marche pas)
-remettre ta clé
-copier le nouveau fichier
C'est un peu lourd et surtout pas très intuitif.
Malizor a écrit
Ce que je veux dire c'est que ça serait une perte de temps de transmettre telles quelles toute les plaintes de type « opinion ».
Tout à fait d'accord il faut se concentrer sur la résolution de problème "technique"
Le fil "Nouveautés dans Precise..." se charge déjà, plus moins, de ça
Malizor
kao_chen a écritMalizor a écritCe bug est marqué comme étant corrigé chez Gnome (quand tu démontes la clef USB, on te demande si tu veux purger la corbeille).
Pour moi ça suffit pas, si t'as clé est pleine et que tu veux ajouter un fichier, tu dois commencer pas vider ta clé.
Actuellement il faut:
-mettre ta clé
-supprimer des fichiers
-retirer la clé pour être sûr de libérer de la place, (ne pas le faire à la sauvage sinon ça ne marche pas)
-remettre ta clé
-copier le nouveau fichier
C'est un peu lourd et surtout pas très intuitif.
Il me semble qu'il propose aussi de vider la corbeille quand il n'y a plus de place (je n'ai pas vérifié).
Si ce n'est pas le cas, c'est ce qu'il devrait faire.
Sinon, c'est typiquement le genre de truc que l'équipe pourrait transmettre sur le bugzilla de Gnome. Il y a la marche à suivre pour reproduire le problème et je pense pas que le statut de bug fasse débat ici.
seb24
Ca serait bien de pas parler de bug ici, mais plutôt de comment s'organiser pour monter l'équipe. Sinon ca va devenir le bazaar.
Malizor
On peut se baser sur cet exemple pour discuter.
darkevolution
On est pas obligé de retirer la clé faut faire clique droit vider la corbeille (sur la corbeille du PC, et ÇA c'est un bug ^^)
Faudra faire attention à ça, mettre en wishlist ce qui doit l'être.
kao_chen
darkevolution a écritOn est pas obligé de retirer la clé faut faire clique droit vider la corbeille (sur la corbeille du PC, et ÇA c'est un bug ^^)
C'est un peu tordu mais ça fonctionne... j'essayerai d'y penser la prochaine fois
PhuniX
Salut à Tous,
Je suis OK pour faire de la traduction. Par contre j'aimerai bien que le système soit automatisé, genre on reçoit une notification par RSS ou E-mail qu'il y a une traduction à faire , y'a surement une mailing list à se faire la dessus.
Après j'essayerai de faire du test et de la reproduction de Bug pendant mon temps libre (au boulot ça devient chaud sauf en phase BETA 😃)
Phoenamandre
Idem je veux bien participer pour de la traduction
Malizor
La traduction c'est bien, mais on ne fera pas que ça hein.
Il faudra vérifier la reproductibilité des bugs, vérifier qu'ils n'ont pas déjà été rapportés, ajouter des détails si nécessaire et enfin transmettre au bon endroit.
Pour ce qui est des notifications, je pense qu'on créera une liste de diffusion sur Launchpad et qu'on l'abonnera aux bugs du projet bugsquad-fr. Les inscrits recevront donc un mail à chaque nouveau bug/commentaire.
Phoenamandre
Cette version d'ubuntu est importante, je veux donc bien pister les bugs avec vous ! Ce serait même un plaisir. Il faut vraiment que la 12.04 soit la version la plus rapide et stable jusqu'à maintenant 😉
shindz
Alors , je crois qu'on est deja plus ou moins fixé sur comment procéder.
A mon avis la traduction obéira aussi à la meme regle. j'ai une autre vision pour ce qui est de la traduction , mais elle tient a vraiment briser les habitudes :lol: car souvent quand je lis certaines traductions sur launchpad, je remarque que c'est le meme profil qui revient toujours : les traducteurs s'efforcent de reutilser la traduction mot pour mot, alors qu'on devrait plutot essayer de trouver une phrase en francais qui exprime la meme chose qu'en anglais mais plus accessible / comprehensible pour l'utilisateur final. c'est un ressenti constant chaque fois que je tombe sur un doc traduit de l'anglais pour le francais dans launchpad ou dans le systeme. ce ressenti est le meme apres la phase test ( en phase test je garde le system en anglais) et quand je reviens sur le systeme en francais je ressens dans certains endroit ( desolé j'ai pas d'exemple là sur le coup vu que je n'avais noté ca à coté ) cet effet de juste voir une traduction et non avoir l'impression que le systeme est editer en francais.
En anglais j'ai par exemple : System Settings --> Paramètres Système ce terme est parlant pour les geeks , mais parcontre Réglages du Systeme ou Configuration du Systeme me semble plus parlant pour tout le monde.
il y a encore Dispositif D'affichage « Dispositif» n'est pas accessible pour tout le monde, et dans Gnome-controle -center il est juste nommé «Affichage». bref l'utilsateur doit se sentir proche de son systeme. je respecte ceux qui traduisent mais ce serait bien s'ils se mettent a la place de cet utilsateur moyen qu'il faut encadrer.
pour faire un parallèle et mieux expliquer le probleme sur le choix des mots , j'avais debloqué un ami a l'université, qui n'etait pas dans les maths .... : il m'avait demandé de l'aider à comprendre le "gradient" ( gradient de potentiel, gradient d'un vecteur en general) alors qu'il savait (sans s'en rendre compte) ce que c'etait mais seulement le mot "gradient" le deroutait. quand je lui ai dit que pour tout vecteur en general , lorsque celui-ce varie en fonction d'une variable , alors le gradient n'est rien d'autre que la variation de ce vecteur par rapport à cette variable , en d'autre terme , la dérivé de ce vecteur par rapport à cette variable ; et là il me demande tout joyeux: "c'est tout ? " ) et depuis il n#etait plus bloqué. on ne se rend pas souvent compte de l'impact qu'un mot a sur un utilisateur.
