Nombre de posts: 64 Inscrit(e) le: 04 juillet 2009
samedi 19 septembre 2009 à 23:31
bonjour,
sur le wiki, je pense que les pages de rapports de bugs sont un peu trop encombrées et je vous propose de séparer les bugs par type. Ca permettrait de séparer les bugs vraiment graves, les bugs mineurs, les fautes d'orthographe, les problèmes d'interface, etc. Qu'en pensez vous ?
Ensuite, on pourrait faire des pages séparées pour les bugs et pour les idées d'amélioration. Ca se chargerait plus vite chez ceux qui ont une connexion internet lente. (c'est malheureusement mon cas et la page met assez longtemps à se charger à chaque fois).
Nombre de posts: 64 Inscrit(e) le: 04 juillet 2009
dimanche 20 septembre 2009 à 11:12
Suite : finalement, la page de bugs ne met pas si longtemps à se charger, donc ce n'est pas la peine de séparer les bugs et les idées d'amélioration, etc. Autant tout laisser sur une même page (plus pratique pour sylvain aussi qui peut imprimer la page d'un coup).
En revanche, je vous propose d'effacer les petits bugs et les fautes d'orthographe après leur résolution (en attendant un certain délai quand même au cas où sylvain ait besoin de reprendre une ancienne version). Je ne sais pas si c'est une bonne idée (faut-il archiver tous les bugs ou est ce inutile ?). Qu'en pensez vous ?
Nombre de posts: 1592 Inscrit(e) le: 1er janvier 2008
dimanche 20 septembre 2009 à 11:28
Zut alors, j'ai fait le ménage dans la liste ce matin. Je vais les récupérer dans l'historique et je vais créer une partie en bas de page qui récapitulera les bugs résolus. Bruno
Nombre de posts: 64 Inscrit(e) le: 04 juillet 2009
dimanche 20 septembre 2009 à 11:32
bonjour,
dans ce cas, plutôt qu'une liste de bugs résolus en bas de page, je préférerais un lien en bas de la page vers une page de vieux bugs résolus. (évite de surcharger la page courante de bugs et aussi, plus pratique pour ceux dont la connexion internet est lente).
Nombre de posts: 64 Inscrit(e) le: 04 juillet 2009
lundi 10 mai 2010 à 11:13
bonjour,
sur le wiki, je vous propose de séparer le menu des bugs dans une page à part : je le fais et si vous trouvez que la version précédente était plus pratique, il suffira d'annuler ma modification à partir du bouton "anciennes révisions".
Nombre de posts: 84 Inscrit(e) le: 04 septembre 2008
lundi 10 mai 2010 à 18:13
et passer à un "vrai" système de gestion de bugs (bugzilla, trac, redmine... ou les sites de Google Code, sourceforge, ...), je suis le seul à penser que ça serait plus pratique ?
Nombre de posts: 84 Inscrit(e) le: 04 septembre 2008
mardi 11 mai 2010 à 10:15
Citation de sylvain :
Je me suis renseigné sur Bugzilla et Trac : ces outils utilisent Perl ou Python qui sont indisponibles chez Free, l'hébergeur du site de VT).
Oui pareil avec RedMine qui marche sur Ruby on Rails. Aucun se contente de php+sql. Mais chaque université et IUT dispose quand même d'internet et de machines, moi par exemple je pourrais installer Redmine pour les rapports de bug de VT sur le pc où je fais tourner tout ce qui touche à l'EDT, si ça peut dépanner.
Ou bien créer un projet sourceforge / google code ou autre. D'ailleurs pour ce qui est des scripts SQL liés à VT (au moins initialisation de la base pour nouveaux utilisateurs), on peut réellement créer un projet "open source", ce qui permet de garder la trace de toutes les évolutions de la bdd. et profiter de tout le système des projets google code. Ca prend 5 minutes (surtout avec un seul script à gérer !), je peux faire ça dans la semaine si tu n'as rien contre.
Citation :
Ce qu'on peut qd-même dire c'est que depuis l'utilisation du wiki pour gérer les bugs, le travail a été beaucoup plus efficace.
J'imagine, mais pour un simple utilisateur, faire face à une page wiki imposante pour simplement chercher / enregistrer un bug, même moi ça m'effraie un peu ! Surtout pour exploiter la liste des bugs résolus / en cours / graves / mineurs ... une vraie base de bugs est incomparablement plus commode qu'une page wiki.
Citation :
En ce qui concerne la nouvelle organisation du wiki : moi ca me convient très bien !
Je dirais que c'est aussi ce que disent les collègues responsables d'EDT qui le font avec excel / word depuis des années et en sont satisfaits. Ils n'ont pas tort, mais ... ;-p
1.6.925 ©2006-2010
Se connecter
