En mars j’écrivais un billet de blog au sujet du reversement des développements. Ces 7 derniers mois nous avons maintenu et accentué nos efforts pour contribuer les développements dans la master communautaire.
Je me dois de saluer l’engagement et l’énergie de mon équipe et aussi d’autres personnes de l’entreprise (notamment Paul, Release Manager, Stéphane Delaye, qui a beaucoup testé) parce qu’il en faut ! Rebaser un développement c’est avant tout réécrire la majeure partie du patch (changement du moteur de template mais aussi modification des API et changements internes), suivre les nombreux allers/retours avec les autres membres de la communauté, soumettre à nouveau des patchs jusqu’à complète digestion dans la version finale (sans compter les tests, la doc et la traduction). C’est un processus plutôt long, rébarbatif mais nécessaire et BibLibre a su nous permettre d’investir beaucoup de temps dans cette tâche.
Les outils de suivi se sont améliorés, mais sont restés sensiblement les mêmes toute l’année:
Place aux chiffres:
Les courbes sont basées sur un reste à faire en « tickets » (Notez que le nombre total de tickets à soumettre à augmenté en cours d’année). Ce reste à faire est seulement sur les développements réalisés en 2011 et 2012, nous l’avons mis à jour au fur et à mesure (les toutes dernières commandes ne sont pas référencées). Comme vous pouvez le lire sur le schéma, le « reste à soumettre » a fortement baissé depuis juin où le planning nous a permis de soumettre beaucoup de patchs. Le « en cours » représente les patchs soumis à la communauté non encore poussés (ils sont en grande partie dans un état « en attente de signature »). Vous pouvez vous référer à l’onglet « Devs » qui est à jour de début octobre (date du dernier point).
C’est sur l’écart entre la courbe rouge et la courbe bleue que vous pouvez influer. Je ne le répéterai jamais assez : nous ne sommes pas les seuls responsables de ce résultat : nous soumettons des patchs, quelqu’un d’autre que BibLibre doit les tester et valider, c’est la « signature », puis l’équipe de contrôle qualité va passer faire une vérification technique.
Tous les travaux ne sont pas visibles dans ce document qui ne rend visible « que » les développements liés à une fonctionnalité utilisateur. Jonathan a investi encore plus de temps sur la QA, et des évolutions techniques comme la gestion des mises à jour de la base de données (l’updatedatabase) et la gestion des traces de Koha. Notre engagement pris au début de l’année était de soumettre tous les développements de 2011 et une bonne part de ceux de 2012 à la communauté pour la fin 2012. Nous y sommes et la courbe bleue suit la bonne tendance.
