Il est possible de participer à l’amélioration de Koha en testant et en apportant une validation aux corrections/nouvelles fonctionnalités proposées pour le logiciel.
Comment ça marche ?
Tous les bugs concernant Koha sont décrits dans la base Bugzilla (en anglais) : http://bugs.koha-community.org/bugzilla3/. Les nouvelles fonctionnalités y sont également proposées.
Plusieurs statuts sont utilisés pour définir l’état d’avancement de ces corrections/améliorations :
– NEW : le problème est décrit mais il n’y a pas de code correctif proposé
– NEEDS SIGNOFF : une correction a été proposée et elle doit être testée et validée. C’est là que l’on peut intervenir !
– FAILED QA : la proposition d’amélioration a été rejetée soit parce qu’elle n’est pas correcte fonctionnellement ou au niveau du code informatique
Pour en savoir plus sur le circuit de validation des bugs et les autres statuts
Et qu’est-ce qu’on peut faire ?
On peut tester ces propositions de corrections/améliorations en utilisant une sandbox (bac à sable), elles sont disponibles en ligne : http://sandboxes.ptfs-europe.co.uk/
Quand on a repéré un bug en statut NEEDS SIGNOFF, on peut lire son descriptif complet sur Bugzilla : on y trouve un plan de test qui donne les étapes pour vérifier que tout fonctionne bien. Ensuite, on peut configurer une sandbox. Attention, quelques vérifications sont nécessaires pour être sûr que l’on peut bien utiliser une sandbox pour le tester : les explications détaillées
Si les tests sont probants et montrent que les corrections attendues sont effectives et n’introduisent pas d’autres bugs, on peut « signer le patch », c’est à dire donner la validation fonctionnelle. Pour cela, on utilisera la sandbox pour changer le statut en « SIGNED OFF » et en ajoutera un commentaire dans Bugzilla en expliquant ce que l’on a testé.
Si les tests ne sont pas probants, on changera le statut directement dans Bugzilla en « FAILED QA » et on ajoutera un commentaire expliquant ce qui ne marche pas.