le release manager de Koha 3.8 répond à Bambou

Paul Poulain*, nouveau release manager du SIGB Koha (version 3.8), et également co-fondateur de la société BibLibre, a bien voulu nous éclairer sur le mode de gouvernance qui structure et anime désormais la communauté internationale des développeurs du logiciel libre Koha

Bambou : « Vous êtes actuellement le release manager de la version 3.8 communautaire de Koha. Pouvez-vous nous préciser en quoi consiste cette fonction ? »

Paul Poulain : « La communauté Koha rassemble des contributeurs des quatre coins du monde. Un travail de coordination est donc nécessaire pour que les contributions s’assemblent de la manière la plus harmonieuse possible. Afin qu’un nouveau contributeur puisse identifier « qui fait quoi », un certain nombre de responsabilités doivent être nominatives. Parmi celles-ci :

  • le Release Manager = il est responsable de la coordination des travaux en vue du développement de la version du logiciel qui sera diffusée à la prochaine publication. Depuis 18 mois, notre cycle de publication est basé sur le principe « Time Based Release », c’est à dire 1 publication tous les 6 mois (fin avril et fin octobre). Le contenu de la publication n’est donc pas défini à l’avance : ce qui est prêt est publié. Ce qui ne l’est pas est repoussé au cycle suivant. C’est justement le rôle du Release Manager de coordonner et trancher en cas de difficulté.
  • le Release Maintainer = il est responsable de la maintenance de la dernière version stable publiée (à ce jour, la version 3.6)
  • le QA manager = il est chargé de définir et contrôler la qualité technique du code qui « rentre » dans l’application. Ce rôle est très important même si invisible, car c’est grâce à la QA que l’application reste « lisible » et « maintenable ». Le QAM est assisté de QA Assistants, qui l’aident dans sa tache de contrôle.
  • Dans les autres responsabilités, citons le « documentation manager » (responsable de la documentation -en anglais-) le « translation manager » (responsable du site sur lequel sont faites les traductions) et le « packaging manager » (responsable de la fabrication et publication des « paquets » Koha pour différentes distributions de Linux -à commencer par Debian-) »

Bambou : « Comment êtes-vous désigné et par qui ? »

Paul Poulain : « Généralement 2 mois avant une release, une page de wiki est ouverte par quelqu’un (n’importe qui), pour demander « qui est candidat à quel rôle pour la prochaine version? ». Pour la prochaine version, la page est visible ici. N’importe qui peut être candidat et, s’il y a plusieurs candidats, un vote est organisé. Il n’y a eu que très rarement besoin d’un vote jusqu’à présent. En effet, ces différentes responsabilités ne sont pas des sinécures, elles demandent beaucoup d’investissement, et ne rapportent rien, sauf des complications dans son quotidien !
Pour la prochaine version (baptisée 3.10 pour l’instant), vous pourrez constater que nous avons encore plusieurs postes vacants, dont celui de QA Manager, le précédent QAM ne souhaitant pas poursuivre.
Pour ce qui me concerne, j’ai postulé pour rester Release Manager parce que j’estime qu’un seul cycle de 6 mois, c’est trop peu. Je me porterai peut-être volontaire pour un 3eme cycle dans 6 mois, mais ce n’est pas sûr, et en tous cas sûrement pas pour un 4eme ! Pour l’instant, j’ai encore de nombreuses idées que je souhaite mettre en place. »

Bambou : « Quel temps consacrez-vous à cette activité ? »

Paul Poulain : « Lorsque j’ai posé ma candidature, nous (la direction de BibLibre) avions convenu que j’y passerai un mi-temps. Dans les faits, j’y consacre un peu plus qu’un mi-temps. Et je ne travaille pas que 35H par semaine. Par contre, je réussis à préserver mes week-ends de manière très stricte et j’y passe quelques soirées, mais j’évite que ce soit fréquent. Le travail possible est tellement important que 2 personnes pourraient y consacrer un plein temps sans difficulté ! »

Bambou : « Quels sont les critères d’acceptation ou de refus d’un patch soumis par les développeurs ? »

Paul Poulain : « Pour être inclus dans Koha, un « patch » (= des lignes de code source qui corrigent un bug ou ajoutent une fonctionnalité) doit passer plusieurs étapes:

  • être soumis via la plateforme, avec un formalisme décrit sur notre wiki communautaire
  • être testé par une tierce personne du point de vue fonctionnel. Lorsqu’un testeur (n’importe qui, il n’y a pas besoin de s’inscrire pour ce faire) a testé le patch et constaté qu’il règle bien le problème décrit ou ajoute la fonctionnalité annoncée va « signer » le patch, toujours sur la plateforme
  • être passé au tamis de la QA. la personne de l’équipe de QA qui va regarder le patch va vérifier s’il respecte nos règles de développement, notamment la conformité avec nos « coding guidelines« 
  • enfin, le Release Manager va vérifier une dernière fois le patch et l’inclure dans Koha. Le RM a le « mot de la fin » dans tous les cas. S’il estime qu’il serait utile qu’une autre personne teste le patch, que son intégration est « dangereuse » pour la stabilité du code en général,… il peut le refuser. Certains me demandent combien de patches je rejette, je dirais qu’1 patch par semaine, au maximum, pose problème.

Dans la plupart des cas le rejet n’est pas définitif. Lorsqu’un patch ne « revient pas » après avoir été rejeté une première fois, c’est généralement parce que celui qui l’a soumis ne répond pas à nos demandes. Dans ce cas, il arrive parfois qu’une autre personne prenne le patch en charge, mais c’est assez peu fréquent.
Ajoutons que les patches qui correspondent à une correction de bug ne posent généralement pas de problèmes importants et qu’il arrive que j’accepte des corrections de bugs importants même si la solution proposée n’est pas idéale techniquement. L’efficacité prime. »

Bambou : « Pensez-vous que le modèle de gouvernance actuel est satisfaisant ou en attendez-vous des évolutions, au regard notamment de l’expansion considérable de Koha sur le plan international ? »

Paul Poulain : « C’est une question très large, et également très sensible… Comme toutes les communautés Open Source -ou presque-, l’écosystème Koha fonctionne sur le principe de la « méritocratie« .
Certaines communautés ont une organisation s’apparentant à des cercles concentriques, avec un noyau ayant une autorité et des droits plus importants que les cercles périphériques. La communauté Koha est strictement basée sur le principe « 1 personne = 1 voix ». Cela signifie qu’il faut toujours être convaincant lorsque l’on porte une idée.
Cette situation me convient plutôt, mais elle aboutit parfois à des blocages lorsqu’il n’y a pas de consensus. Et le blocage signifie que l’on ne change rien à une situation dont tout le monde s’accorde à dire qu’elle n’est pas bonne.
Heureusement, ce genre de blocage est rare, et en général, celui qui apporte une idée sur la balance, avec la réalisation de cette idée, est bien accueilli !
Un autre souhait que je pourrais formuler serait que plus de bibliothécaires s’impliquent dans la gouvernance du projet. Il y a quelques profils « mixtes » (Katrin -allemande-, Liz et Owen -américains- ou Magnus -norvégien-), mais la plupart des participants réguliers et assidus ont un profil de développeur. »

Bambou : « Quelles sont vos motivations à exercer une telle responsabilité, au-delà des compétences techniques qui sont les vôtres ? »

Paul Poulain : « Vaste question… à laquelle je peux donner plusieurs réponses, toutes sincères et vraies. Tout d’abord, j’ai fait mienne la devise suivante : « seul on va plus vite, ensemble on va plus loin ». Au final, je préfère aller plus loin que plus vite. Par ailleurs, BibLibre est le plus gros contributeur de Koha. Il m’a donc paru logique que nous poussions notre participations aussi au niveau « RM ». Il m’a aussi semblé que j’avais quelques idées qu’il serait plus facile de mettre en œuvre en étant Release Manager, « en tenant la barre » en quelque sorte.
Enfin, je suis un « libriste », avant d’être un « chef d’entreprise ». BibLibre ayant la taille et les moyens d’investir dans cette œuvre commune, il nous a semblé que c’était cohérent avec notre « mission » d’entreprise. »

*Ingénieur en Informatique, Paul Poulain a travaillé pour l’assurance maladie et, à la fin des années 1990, dans une start-up du secteur de la vente en ligne. Il s’implique dans des projets de logiciels libres depuis 1998. Contributeur aux développements de Koha depuis 2001, il s’est engagé à temps plein dans ce projet dès 2002. Il en est l’un des plus importants développeurs, ayant en particulier mis en œuvre la gestion des formats MARC. Dans ces différentes activités, Paul Poulain a ainsi œuvré depuis 2001 à faire connaître les logiciels libres dans le monde des bibliothèques.
paul.poulain@biblibre.com | +33-(0)491813508 | http://twitter.com/paul_poulain

Publicités

2 Réponses

  1. […] 16h30-17h15 : Ateliers « bac à sable » – découverte en libre-service de Koha ; présentation par Paul Poulain. […]

  2. […] Via docmiop.wordpress.com Share this:J'aimeJ'aime  […]

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s