De Framalang Wiki.

Chapitre 7 : Paquets, sorties et développement quotidien

Page d'accueil du projet

Chapitre 9 : Licence, droits d'auteur et brevets

---

Sommaire 1 Chapitre 8 : Encadrer les volontaires 1.1 Tirer le meilleur des volontaires 1.1.1 Déléguer 1.1.1.1 Distinguer clairement requête et assignation 1.1.1.2 Le suivi après la délégation 1.1.1.3 Remarquer les centres d'intérêts des gens 1.1.2 Félicitations et critiques 1.1.3 Éviter le marquage de territoire 1.1.4 La bonne dose d'automatisation 1.1.4.1 Les tests automatisés 1.1.5 Considérez tous les utilisateurs comme des volontaires potentiels 1.2 Partager les tâches de gestion aussi bien que les tâches techniques 1.2.1 Responsable correctifs 1.2.2 Responsable traduction 1.2.3 Responsable documentation 1.2.4 Responsable difficultés 1.2.5 Responsable FAQ 1.3 Transitions 1.4 Committers 1.4.1 Choisir les committers 1.4.2 Révoquer un accès de commit 1.4.3 Accès de commit restreint 1.4.4 Les committers en hibernation 1.4.5 Éviter le mystère 1.5 Remerciements 1.6 Les fourches 1.6.1 Gérer une fourche 1.6.2 Amorcer une fourche 2 Notes

Chapitre 8 : Encadrer les volontaires

La réussite d'un projet ne tient pas uniquement à la création d'une atmosphère sympathique ou à son bon fonctionnement. Cela ne suffit pas à mettre tout le monde d'accord sur les besoins du projet ou encourager la collaboration. Il faut qu'une personne, voire plusieurs, prenne(nt) en charge l'encadrement des volontaires. Encadrer les volontaires n'est peut être pas un art technique au même titre que la programmation, mais c'est un art, dans le sens où cette discipline peut-être améliorée par l'étude et la mise en pratique.

Le but de ce chapitre n'est pas de vous apporter sur un plateau un ensemble de techniques précises prêtes à l'emploi pour diriger les volontaires. Il s'appuie, peut-être plus encore que les autres chapitres, sur le projet Subversion comme cas d'étude. Ceci est dû, en partie, au fait que je travaillais sur ce projet au moment de la rédaction du livre, j'avais donc un accès direct à la matière première, mais aussi, en partie parce que « charité bien ordonnée commence toujours par soi-même ». J'ai également été témoin, dans d'autres projets, des conséquences de la mise en application des recommandations qui suivent, ou des conséquences de leur inapplication le cas échéant. S'il s'avère politiquement correct de citer des exemples venant d'autres projets, je le ferai.

En parlant de politique, quitte à en discuter, autant le faire maintenant et regarder de plus près ce domaine tant décrié. De nombreux ingénieurs pensent que la politique est une chose réservée aux autres. « Je ne fais que défendre la meilleure marche à suivre pour le projet, mais elle soulève des objections pour des raisons politiques. » Je pense que ce dégoût de la politique (ou de ce qui est perçu comme tel) est particulièrement fort chez les ingénieurs, car ils adhèrent à l'idée que certaines solutions sont objectivement meilleures que d'autres. Ainsi, quand quelqu'un se laisse guider par des considérations externes (par exemple : la défense de sa propre position d'influence, l'abaissement de l'influence d'une autre personne, un retournement de veste manifeste ou encore pour éviter de blesser quelqu'un), d'autres personnes dans le projet pourraient en être gênées. Ce qui ne les empêchera évidemment pas de se comporter de la même manière quand leurs propres intérêts vitaux seront en jeu.

Si pour vous « politique » est un gros mot, et que vous espérez qu'il ne vienne pas salir votre projet, vous pouvez tout laisser tomber dès maintenant. La politique entre inévitablement en compte lorsque des gens doivent gérer ensemble une ressource partagée. Lors d'une prise de décision, il est tout à fait normal de prendre en considération les conséquences que cette décision aura sur notre influence future dans le projet. Après tout, si vous avez confiance en votre propre jugement et vos propres compétences, comme c'est le cas de la plupart des programmeurs, le risque d'une perte d'influence doit être considéré, dans un sens, comme une donnée technique . Un raisonnement similaire s'applique à d'autres comportements qui peuvent, de prime abord, sembler purement politiques. En fait le « purement politique » n'existe pas, c'est bien parce que les actions ont des répercussions dans le monde réel que les gens deviennent « politiquement conscients ». La politique n'est rien d'autre finalement que la reconnaissance des conséquences d'une décision et leur prise en compte. Si une décision particulière mène à un résultat que les participants trouvent techniquement satisfaisant, mais qui modifie les relations au pouvoir et donne un sentiment de mise à l'écart à certains personnages clés, cette considération devient au moins aussi importante que le résultat technique. L'ignorer n'est pas un signe de noblesse d'esprit, mais plutôt un manque de clairvoyance.

Alors en lisant les conseils qui suivent, quand vous travaillez sur votre propre projet, souvenez vous que personne n'est au dessus de la politique. Se donner l'air d'être au dessus de la politique n'est qu'une simple stratégie politique, qui peut parfois être très utile, mais, dans tous les cas, ce n'est jamais une réalité. La politique n'est que le fruit du désaccord entre certaines personnes, et les projets qui réussissent sont ceux développant des mécanismes politiques pour gérer les désaccords de manière constructive.

Tirer le meilleur des volontaires

Pourquoi les volontaires travaillent-ils sur des projets de logiciels libres ? [24]

Quand on le leur demande, beaucoup disent que c'est parce qu'ils veulent produire un bon logiciel, ou qu'ils veulent être personnellement impliqués dans la réparation des bogues importants pour eux. Mais en général, ce ne sont pas là les seules raisons. Après tout, pouvez vous imaginer un volontaire s'accrochant à un projet même si personne ne le félicite pour son travail ou ne lui prête attention dans une discussion ? Bien sûr que non. Il est évident que les gens participent à un projet de logiciel libre pour des raisons qui vont au delà du désir de produire un bon code. Comprendre les motivations réelles des volontaires vous aidera à les attirer et les faire rester. Le désir de produire un bon logiciel peut faire partie de ces raisons, avec le défi et l'enrichissement personnel qu'apporte le travail sur des problèmes complexes. Mais les humains ont également un désir inné de travailler avec d'autres, de donner et recevoir du respect au travers d'activités coopératives. Les groupes, impliqués dans des activités coopératives, doivent produire des normes de comportement, de sorte qu'une position s'acquiert et se maintient par des actions qui servent les objectifs du groupe.

Ces normes ne vont pas toujours s'imposer d'elles-mêmes. Par exemple sur certains projets, les gens ressentent apparemment qu'une position s'acquiert en écrivant fréquemment et verbeusement, les développeurs Open Source expérimentés savent sûrement de quoi je parle. Ils n'arrivent pas à cette conclusion par accident, ils y parviennent parce que lorsqu'ils produisent des arguments longs et compliqués, ils obtiennent du respect, peu importe si ça aide vraiment le projet. Vous trouverez dans les prochains paragraphes quelques techniques pour créer une atmosphère dans laquelle les actions sont à la fois « politiques » et constructives.

Déléguer

Déléguer ne se résume pas à répartir la charge de travail, c'est aussi un outil politique et social. Envisagez les conséquences quand vous demandez à quelqu'un de faire quelque chose. La plus évidente est que, s'il accepte, il fera le travail et pas vous. Mais en même temps, il se rend compte que vous lui faites confiance pour mener cette tâche à bien. De plus, si vous en avez fait la demande dans un forum public, il sait que le reste du groupe est averti de la confiance accordée. Mais il ne faut pas qu'il se sente obligé d'accepter, vous devez formuler la demande de manière à lui laisser la possibilité de décliner avec élégance l'offre s'il ne veut pas vraiment faire le travail. Si la tâche requiert une coordination avec d'autres membres du projet, vous lui offrez effectivement de s'impliquer plus, de créer des liens qui n'auraient autrement jamais été forgés, et peut-être de devenir une figure d'autorité dans une sous partie du projet. L'implication supplémentaire peut être intimidante comme elle peut être encourageante en raison d'un plus grand sentiment d'engagement .

Pour toutes ces raisons, il vaut mieux, parfois, demander à quelqu'un d'autre de faire quelque chose, même si vous savez que vous pourriez le faire plus rapidement ou mieux vous même. Bien sûr, certains impératifs d'efficacité vous y amèneront : si vous avez des tâches plus importantes à accomplir, peut-être que le faire vous même serait illogique. Mais, même quand cette considération ne s'applique pas, vous pouvez choisir de déléguer le travail à quelqu'un d'autre parce que vous cherchez à l'impliquer plus sur le long terme, même si cela signifie que vous devrez passer plus de temps à le surveiller au départ. L'inverse est également vrai, si vous vous proposez de faire de temps en temps le travail que quelqu'un d'autre ne veut pas ou n'a pas le temps de faire, vous gagnerez sa bonne volonté et son respect. Déléguer et échanger ne sert pas seulement à mener à bien des tâches ponctuelles, ça sert aussi à impliquer plus encore les gens dans le projet.

Distinguer clairement requête et assignation

Parfois, il est juste d'attendre d'une personne qu'elle accepte une tâche particulière. Par exemple, si quelqu'un est à l'origine d'un bogue ou qu'il produit des lignes de code ne correspondant manifestement pas aux standards du projet, il suffit de signaler le problème en montrant que vous attendez que la personne s'en occupe. Mais dans d'autres situations votre demande n'aura pas forcément cette légitimité naturelle. La personne est libre de répondre favorablement à votre demande ou pas. La bonne volonté d'un bénévole n'est pas chose acquise, et vous devez bien faire la différence entre ces deux situations et adapter votre requête en conséquence.

Une personne a qui vous demandez de faire quelque chose, en impliquant clairement que vous pensez que c'est sa responsabilité, alors qu'elle ne partage pas ce sentiment, ne sera certainement pas bien disposée à le faire. Ceci rend la répartition des tâches très complexe. Dans un projet, les participants savent, en général, qui est expert dans chaque domaine, donc, quand un bogue est signalé, tout le monde pensera à une ou deux personnes susceptibles de le réparer rapidement. Cependant, assigner cette mission à l'une de ces personnes, sans avoir son accord, pourrait la mettre dans une position inconfortable. Elle peut le ressentir à la fois comme une reconnaissance de son expertise, mais aussi comme si son savoir faire était récompensé par une punition. Après tout, c'est en réparant des bogues que les gens acquièrent de l'expérience, alors peut-être que quelqu'un d'autre pourrait s'occuper de celui-ci ! (Si le système de suivi de bogues assigne automatiquement les problèmes à certaines personnes en se basant sur les informations contenues dans le rapport de bogue, les attributions se font de manière plus douce puisque la désignation est un processus automatisé et qu'elle ne traduit pas les attentes d'autres humains.)

Vous serez parfois amené à encourager la personne pouvant résoudre le bogue le plus vite, à le faire même si idéalement il faudrait répartir la charge de travail. Puisque vous ne pouvez pas créer une exception dès que la nécessité se fait ressentir (« Serais tu prêt à jeter un œil à ce bogue ? » « Oui. » « Ok, je te donne alors ce travail. » « Ok. »), vous devriez plutôt formuler la demande comme une requête, sans pression. Quasiment tous les outils de suivi des bogues permettent d'associer un commentaire à l'assignation d'une tâche. Dans ce commentaire, vous pourriez dire quelque chose comme ceci :

Je te confie cette tâche, A.Nonyme, parce que tu es celui qui est le plus familier avec ce code. Tu es libre de refuser si tu n'as pas le temps de t'y pencher malgré tout (et fais moi savoir si tu préfèrerais ne plus recevoir ce genre de demande dans le futur).

Vous envoyez ainsi une requête claire tout en laissant la possibilité à la personne concernée de la refuser. Le public ici n'est pas seulement la personne en question, c'est tout le monde : le groupe entier a la confirmation publique de son expertise, mais le message indique clairement qu'elle est libre d'accepter ou de refuser la responsabilité.

Le suivi après la délégation

Lorsque vous demandez à quelqu'un de faire quelque chose, souvenez vous que l'avez fait, et suivez le travail avec lui quoiqu'il arrive. La plupart des requêtes sont formulées sur des forums publics et suivent à peu près le même modèle « Est-ce que tu peux t'occuper de X ? Fais le nous savoir, c'est pas grave si tu ne peux pas, il faut juste qu'on sache. » Si vous recevez une réponse négative, vous revenez à votre point de départ et vous devrez tenter une autre stratégie pour régler le problème X. Si la réponse est positive, gardez un œil sur le progrès fait dans ce secteur, et commentez l'évolution du travail (n'importe qui travaille mieux en sachant que le résultat sera jugé). S'il n'y a pas de réponse après quelques jours, répétez votre demande, ou écrivez que vous n'avez pas reçu de réponse et que vous êtes à la recherche de quelqu'un d'autre pour cette tâche. Ou, faites la vous même, mais assurez vous d'annoncer que vous n'avez pas reçu de réponse après votre première demande.

Le but n'est pas d'humilier la personne en constatant publiquement son absence de réponse, vos remarques devraient être tournées de telle sorte qu'elles n'aient pas cet effet. Le but est simplement de montrer que vous savez où vous en êtes, et que vous prenez en compte les réponses reçues. Les gens seront plus prompts à dire oui la prochaine fois, car ils verront (même de manière inconsciente) que vous êtes en mesure de remarquer le travail fournit puisque vous avez noté le fait, beaucoup moins visible, que quelqu'un n'a pas donné de réponse.

Remarquer les centres d'intérêts des gens

Remarquer les centres d'intérêt des gens est aussi quelque chose qui leur fait plaisir. En général, mieux vous connaissez et gardez en mémoire les facettes d'une personnalité, plus elle se sentira à l'aise, et plus elle voudra travailler au sein de votre groupe.

Il y avait par exemple une distinction marquée dans le projet Subversion entre ceux qui voulaient atteindre la version 1.0 définitive (ce qui s'est finalement réalisé), et ceux qui voulaient principalement ajouter de nouvelles fonctionnalités et travailler sur des problèmes intéressants mais qui ne se souciaient pas de la date de sortie de la version 1.0. Il n'y a pas de bonne ou de mauvaise approche, il y a simplement deux types de développeurs, les deux abattant beaucoup de travail pour le projet. Mais on a rapidement compris que l'excitation de la dernière ligne droite avant la sortie de la version 1.0 était partagée par tous. Les communications électroniques peuvent être très trompeuses, vous pouvez ressentir que vos intentions sont partagées, alors qu'en fait ce n'est vrai que pour les personnes avec qui vous étiez en contact, tandis que les autres ont des priorités complètement différentes.

C'est en connaissant les attentes des gens vis-à-vis du projet que vous serez à même de formuler vos demandes efficacement. En montrant que vous comprenez les aspirations des participants, même sans faire de requête liée, vous les rassurerez car ils se diront alors qu'ils sont plus qu'un simple grain de sable au milieu d'un désert uniforme.

Félicitations et critiques

Félicitations et critiques ne sont pas antonymes, elles sont très semblables de bien des manières. Toutes les deux sont des formes d'attention, et sont plus efficaces quand elles sont précises plutôt que vagues. Les deux devraient être utilisées à des fins particulières. Les deux perdent de leur valeur en cas de surabondance, louer trop ou trop souvent et vos louanges s'en retrouveront dévaluées. Il en va de même pour les critiques, bien qu'en pratique elles soient généralement plus marquantes et du coup moins sensibles à la déflation.

Un trait, très particulier aux environnements techniques, est que les critiques détaillées et objectives sont souvent prises comme une sorte de compliment (comme on l'a vu dans la section nommée « Reconnaître l'insolence » dans le Chapitre 6, Communication), car elles impliquent que le travail analysé est suffisamment important pour qu'on prenne le temps de s'y attarder. Cependant, ces deux qualités, détaillées et objectives, doivent être remplies pour que ceci soit vérifié. Par exemple, si quelqu'un fait une modification brouillonne du code, il est inutile (et même dangereux) de simplement faire le commentaire : « C'était brouillon ». Le manque de soin est en fin de compte une caractéristique de la personne, pas de son travail, et il est important que vos réponses portent sur le travail. La critique ne vaut que si elle est constructive. Détaillez, avec tact et sans méchanceté, les maladresses dans la contribution. Si c'est déjà la troisième ou quatrième modification négligente consécutive de cette personne, il convient de dire, encore une fois sans énervement, à la fin de votre commentaire que cette habitude a été remarquée.

Si vous ne constatez pas d'amélioration malgré les critiques, poursuivre dans cette voie ne vous mènera à rien. La seule solution est que le groupe retire à cette personne les responsabilités pour lesquelles elle n'a manifestement pas les compétences, en évitant au maximum de la blesser, référer vous aux exemples de la section « Transitions » plus loin dans ce chapitre. Ceci arrive rarement cependant. La plupart des gens réagissent bien aux critiques précises, détaillées et qui véhiculent (même de manière implicite) une attente d'amélioration.

Les louanges ne blesseront évidemment personne, mais ça ne veut pas dire que vous devez en abuser pour autant. C'est avant tout un outil : avant de l'utiliser, réfléchissez vos motivations. Utilisez les compliments à bon escient, et évitez de commencer à remercier tout le monde pour tout et n'importe quoi, et en particulier, ce qui est systématiquement attendu des gens. Si vous mettez le doigt dans l'engrenage, où vous arrêtez ? Devriez vous féliciter chacun pour avoir accompli son travail habituel ? C'est risqué, car si vous en oubliez certains, ils se demanderont pourquoi. Il vaut bien mieux exprimer son appréciation et sa gratitude avec parcimonie, pour des efforts inhabituels ou non sollicités, avec l'intention d'encourager ce genre de pratiques. Lorsqu'un participant s'implique plus, ajustez vos attentes et vos félicitations en fonction. Des félicitations répétées pour des choses banales perdent leur sens. Cette personne devrait plutôt ressentir que son activité accrue est maintenant considérée comme normale et naturelle, et que, seul un travail encore plus poussé sera remarqué.

Ça ne veut pas dire que les efforts de cette personne ne devraient pas être reconnus bien sûr. Mais souvenez vous que si le projet est bien construit, tout ce que fait cette personne sera visible de toute façon, et le groupe saura (et la personne saura que le groupe sait) tout ce qu'elle réalise. La reconnaissance ne s'exprime d'ailleurs pas que par des félicitations. En mentionnant, en passant, dans un sujet lié que la personne a accompli beaucoup de travail dans ce domaine, vous lui attribuez un statut particulier, vous pouvez aussi la consulter publiquement pour des questions relatives au code. Mieux : vous pouvez, par la suite, utiliser plus ostensiblement ce qu'elle a fait afin qu'elle voit bien que les autres lui font suffisamment confiance pour s'appuyer sur les résultats de son travail. Tout ceci n'est pas nécessairement calculé. Celui ou celle qui contribue beaucoup et régulièrement au projet le remarquera et acquerra automatiquement une position influente. Vous n'aurez en général rien de particulier à faire en ce sens, à moins que vous ne sentiez, pour une raison ou pour une autre, qu'un participant est sous estimé.

Éviter le marquage de territoire

Faites attention aux participants qui tentent de revendiquer le contrôle exclusif sur certains domaines du projet, et qui semblent se réserver tout le travail sur cette partie, jusqu'à reprendre agressivement la main sur une tâche que d'autres ont commencée. Un tel comportement peut sembler bénéfique à première vue. Après tout, si cette personne a décidé de prendre plus de responsabilités et d'accroitre son activité dans un domaine donné, c'est tant mieux. Mais c'est destructeur à long terme. En voyant un gros panneau « Défense d'entrer », les autres volontaires passeront leur chemin. Le code bénéficiera de moins d'attention, il sera donc plus fragile parce que tout repose sur les épaules de cet unique développeur. Pire encore, l'esprit de collaboration et d'égalité dans le groupe est rompu. En théorie chaque développeur devrait être libre de faire ce qu'il veut quand il veut. Bien sûr, en pratique ce n'est pas si simple : les experts dominent leur(s) domaine(s) de compétence, et les novices s'en remettent fréquemment à eux. Mais tout ceci est avant tout volontaire : l'autorité informelle s'obtient au mérite, et cela ne doit pas être un processus actif. Même si la personne est effectivement compétente dans le domaine où elle recherche plus d'influence, il est crucial que cette autorité reste informelle, qu'elle respecte le consensus du groupe, et qu'elle ne serve pas à verrouiller le domaine en question.

Si un travail est rejeté pour des raisons techniques, c'est une autre histoire. On parle ici de technique, pas de chasse gardée. Il se peut très bien qu'une personne fasse la majeure partie des inspections dans un domaine, et tout devrait bien se passer tant qu'elle n'empêche personne d'autre d'en faire autant.

Afin d'éviter tout ce qui ressemble de près ou de loin à du marquage de territoire, de nombreux projets ont pris l'initiative de ne plus citer le nom des auteurs ou des responsables dans les fichiers sources. J'approuve complètement cette pratique : nous faisons de même dans le projet Subversion, et c'est plus ou moins la politique officielle de l'Apache Software Foundation. Un membre de l'ASF, Sander Striker, l'explique ainsi :

À l'Apache Software Foundation nous n'encourageons pas la signature du code source par les auteurs. Les raisons sont diverses, ce n'est pas uniquement par crainte des répercussions légales. Le développement collaboratif est avant tout un effort collectif, développer et faire évoluer un projet en tant que groupe. Il faut savoir montrer sa reconnaissance, c'est sûr, mais il faut le faire d'une manière ne permettant pas de fausses attributions, même implicites. Et comment savoir quand ajouter sa signature ? Est-ce que vous signez de votre nom quand vous modifiez un commentaire ? Quand vous ajoutez une amélioration d'une ligne ? Est-ce que vous retirez le nom de l'auteur quand vous devez revoir le code qui, finalement, est transformé à 95% ? Et que dire de ceux qui vont modifier ça et là des documents, juste assez pour atteindre un quota virtuel de travail afin d'ajouter leur signature et, ainsi, avoir leur nom partout ?

Il y a de meilleurs moyens d'exprimer sa reconnaissance, et ce sont ceux là que nous privilégions. D'un point de vue strictement technique, les signatures des auteurs ne sont pas nécessaires, si vous désirez savoir qui a écrit une partie précise du code, vous pouvez consulter le logiciel de gestion de versions pour le découvrir. Les signatures se périment également. Voulez vous vraiment être contacté en privé à propos d'un morceau de code écrit cinq ans auparavant et que vous étiez content d'avoir oublié ?

Les fichiers du code source d'un logiciel représentent sa carte d'identité. Ils devraient mettre l'accent sur l'aspect collaboratif du développement, et ne devraient pas être divisés en plusieurs petits fiefs.

Pour certains, les signatures de développeurs ne devraient pas être éliminées, car c'est la manière la plus directe d'identifier ceux qui accomplissent le plus de travail. Cet argument pose deux problèmes. Primo, comment fixer un quota de travail à réaliser pour avoir le droit d'apposer sa signature ? Secundo, il ne fait pas la distinction entre mérite et autorité : l'ancienneté n'est pas suffisante pour se prévaloir de la "propriété" d'un domaine. Il est cependant difficile, voire impossible, d'éviter ce genre de méprise lorsque le nom d'individus apparaît en haut des fichiers source. Dans tous les cas, les informations relatives au mérite sont déjà inscrites dans les journaux de gestion de versions ou dans d'autres outils discrets comme les archives des listes de diffusion, ainsi on ne perd rien en retirant les signatures des fichiers sources eux-mêmes [25].

Si votre projet décide de bannir les noms des fichiers sources, assurez vous de ne pas aller trop loin. Par exemple, de nombreux projets ont une zone « contributions » regroupant des outils et des scripts d'aide, leurs auteurs sont souvent des personnes extérieures au projet. Ils ne sont donc pas entretenus par le projet, et il vaut mieux que le nom de leur auteur y figure. Cependant, si un outil de ce type est inspecté et amélioré par des membres du projet, et que vous décidez finalement de lui donner plus de visibilité, vous pouvez, en supposant que l'auteur approuve, retirer son nom afin que le code ressemble à toute autre ressource entretenue par la communauté. Si l'auteur est tatillon sur ce point, des compromis peuvent être trouvés, exemple :

  # indexclean.py: Remove old data from a Scanley index.
  #
  # Original Author: K. Maru <kobayashi@yetanothere-mailservice.com>
  # Now Maintained By: The Scanley Project <http://www.scanley.org/>
  #                    and K. Maru.
  # 
  # ...

ou en français :

  # indexclean.py: Nettoie les anciennes données d'un index de Scanley
  #
  # Auteur original: K. Maru <kobayashi@encoreunautreserveurmail.com>
  # Maintenant géré par: The Scanley Project <http://www.scanley.org/>
  #                    and K. Maru.
  # 
  # ...

Mais il vaut mieux éviter ce genre de compromis si possible. Les auteurs sont en général très ouverts à la discussion, car ils aiment que leurs contributions soient reprises par un projet.

Il faut surtout retenir qu'il n'y a pas de continuité entre le cœur et la périphérie d'un projet. Les principaux fichiers du code source du logiciel font évidemment partie du cœur, et la communauté doit clairement affirmer qu'elle en assure le maintien. À l'opposé, toutes les ressources ne sont pas nécessairement développées et maintenues par le projet. C'est le cas, par exemple, d'outils d'aide ou de morceaux de la documentation qui peuvent être le fruit du travail d'une personne extérieure. Rien ne vous empêche de les intégrer au projet voire même à la distribution, mais ils font partie de la périphérie du projet. Le principe d'anonymat ne s'applique qu'aux ressources entretenues par le projet, vous êtes plus libre pour les autres.

La bonne dose d'automatisation

Les machines peuvent accomplir toutes sortes de tâches, profitez en par une automatisation maximale. Par expérience, une machine effectuera une tâche dix fois plus efficacement qu'un humain. Ce gain peut atteindre un facteur vingt, ou plus encore, pour les opérations très fréquentes ou complexes.

Vous penser comme « dirigeant du projet », plutôt que développeur au sein d'un groupe, pourrait vous être utile ici. Parfois, les développeurs sont incapables de prendre le recul nécessaire pour réaliser que tout le monde gaspille son temps à accomplir manuellement des fonctions automatisables. Même ceux qui s'en rendent compte peuvent ne pas prendre le temps de résoudre le problème. Chaque tâche prise individuellement ne semble par être si fastidieuse, personne ne prend donc jamais la peine d'y remédier. Mais chaque petite tâche est répétée maintes fois par un développeur, multipliez-le encore par le nombre de développeurs, et l'automatisation s'impose alors comme une évidence.

Ici je prend le terme « automatisation » dans une conception large, pour désigner non seulement les actions répétées où une ou deux variables changent chaque fois, mais aussi tout type d'infrastructure technique au service des humains. L'automatisation minimale a été décrite dans le Chapitre 3, Infrastructure technique, mais chaque projet rencontre ses propres obstacles. Par exemple, un groupe travaillant sur la documentation pourrait vouloir un site Web affichant en permanence la dernière version des documents. Comme la documentation est souvent écrite dans un langage de mise en forme, il se peut qu'il y ait une étape de compilation, souvent assez complexe, permettant la création de documents affichables ou téléchargeables. Mettre en place un site Web, où cette compilation est automatisée à chaque publication des modifications, peut être difficile et demander beaucoup de temps, mais cela en vaut la peine, même si ça vous prend un jour ou deux de réalisation. Une documentation constamment à jour sera un grand progrès pour votre projet, même si le fait qu'elles ne le soit pas ne vous semblerait être qu'un désagrément léger et ponctuel.

Non seulement votre équipe réalisera un gain de temps considérable, mais elle sera aussi à l'abri des erreurs humaines inévitables lors de l'accomplissement manuel de procédures complexes. Les ordinateurs ont bien été inventés pour réaliser des opérations déterminées en plusieurs étapes, offrant ainsi aux humains plus de temps pour les choses plus intéressantes.

Les tests automatisés

Si les tests automatisés sont indispensables au développement de tout type de logiciel, ils le sont particulièrement pour les projets Open Source. Les tests automatisés (notamment les tests de non-régression) donnent aux développeurs une plus grande liberté dans des domaines qui ne leurs sont pas familiers, et donc encouragent l'esprit d'exploration. Parce que la détection manuelle des ruptures est si complexe (schématiquement, il faut deviner où pourrait se situer la brèche, puis faire divers tests pour déterminer si on a vu juste ou non), que des moyens automatisés de détection de ces ruptures font gagner beaucoup de temps au projet. Les développeurs savent qu'ils travaillent avec un filet de sécurité, et peuvent modifier sans crainte des pans entiers du code, ce qui facilite le maintien à long terme du projet.

Les tests de non-régression ne sont pas la panacée. D'une part, ils fonctionnent bien pour les programmes en lignes de commandes (les logiciels qui emploient une interface utilisateur graphique sont bien plus complexes à tester automatiquement), et d'autre part, la structure de la suite de tests peut être, elle même, plutôt compliquée. Elle n'est pas forcément simple à appréhender, et il faut aussi la maintenir. Pour qu'elle soit vraiment utilisable, il faut sans cesse l'optimiser, même si ça peut prendre un temps considérable. S'il est facile d'ajouter de nouveaux tests, les développeurs le feront, et vous détecterez plus facilement les bogues. N'oubliez pas que ces efforts de simplification porteront leurs fruits sur toute la durée de vie du projet.

Une règle commune à beaucoup de projets est la suivante : « Ne détruisez pas l'architecture ! », ou en d'autres termes : ne faites pas de changement qui pourrait empêcher de compiler ou de lancer le programme. Quand cette mésaventure arrive à un développeur, il ne fait en général pas le malin, et se fait un peu railler par ses pairs. Lorsque le projet utilise aussi une gamme de tests de non-régression, il y a souvent un corollaire à cette première règle : ne changez rien qui pourrait faire échouer les tests. Les erreurs graves sont plus facilement détectables, si toute une batterie de tests de non-régression vérifie l'intégrité du programme automatiquement le soir, et envoie les résultats à toute la liste des développeurs ou à une liste de diffusion dédiée : voilà un autre exemple d'automatisation qui vous sera grandement bénéfique.

La plupart des développeurs volontaires sont d'accord de prendre un peu plus de temps pour écrire les tests de non-régression quand le système est suffisamment clair et facile à utiliser. Les gens comprennent qu'il faut que les changements soient accompagnés de tests, d'autant plus que c'est aussi une bonne occasion de développer la collaboration : souvent deux développeurs se partageront le travail de réparation d'un bogue, l'un écrivant le correctif et l'autre écrivant le test. Comme ce dernier aura finalement plus de travail, et qu'en plus l'écriture du test apporte moins de satisfaction que la réparation du bogue lui même, il faut impérativement que la suite de test ne rende pas les choses plus désagréables qu'elles ne le sont déjà.

Certains projets poussent encore plus loin, et exigent que chaque correctif ou nouvelle fonction soit accompagné d'un nouveau test. Pour en évaluer la pertinence il faut prendre en compte plusieurs éléments : la nature du logiciel, la composition de l'équipe de développement ainsi que la facilité à écrire ces tests. Le projet CVS (http://www.cvshome.org) a pendant longtemps appliqué cette règle. En théorie, c'est une bonne règle puisque CVS est un logiciel de gestion de versions, il est par conséquent exclu de prendre des risques avec les données des utilisateurs. Le problème dans la pratique est que le test de non-régression de CVS est un énorme script shell fait d'un bloc (ironiquement nommé sanity.sh [NdT : santé mentale]), difficile à lire, modifier ou compléter. La difficulté d'ajouter de nouveaux tests et le besoin d'en associer à chaque correctif font que CVS n'encourage pas du tout l'écriture de correctifs. Quand je participais au projet CVS, j'ai vu des gens abandonner leur correctif lorsqu'ils apprenaient qu'ils devaient y associer un nouveau test à ajouter à sanity.sh, même si leur correctif était déjà prêt.

Il est courant de passer plus de temps à écrire un nouveau test de non-régression qu'à corriger le bogue. Mais CVS avait porté ce phénomène à son paroxysme : les gens pouvaient passer des heures à parfaire leurs tests sans qu'ils ne marchent pour autant car un script Bourne shell de 35 000 lignes est tout simplement ingérable. Même les développeurs expérimentés traînaient les pieds lorsqu'ils devaient ajouter un nouveau test.

C'est simplement notre incapacité à comprendre les bienfaits de l'automatisation qui nous a poussé dans cette impasse. Il faut reconnaître aussi qu'adopter un véritable cadre de tests, à créer nous même ou prêt à l'emploi, aurait demandé un effort conséquent. [26] Mais l'avoir négligé a coûté bien plus au projet au fil des ans. Combien de correctifs et de nouvelles fonctionnalités n'ont pas été incorporés aujourd'hui dans CVS à cause de l'obstacle que représente une suite de tests mal conçue ? On ne peut pas déterminer le chiffre exact, mais il est sûrement bien plus élevé que le nombre de correctifs ou de nouvelles fonctionnalités auxquels renonceraient les développeurs pour créer un nouveau système de test (ou en intégrer un prêt à l'emploi). Cette opération ne prendrait qu'un temps limité, alors que le handicape lié à l'utilisation de la suite de tests actuelle perdurera si rien n'est fait.

Une politique stricte vis à vis de l'écriture des tests n'est pas forcément mauvaise pour autant, pas plus que l'écriture de votre système de test sous forme d'un script Bourne shell. Tout dépend de sa conception et des tests à effectuer. En résumé, lorsque le système de test devient une obstruction sérieuse au développement, vous devez agir : cela vaut pour tous les procédés routiniers se transformant en obstacles.

Considérez tous les utilisateurs comme des volontaires potentiels

Chaque contact avec un utilisateur est une opportunité de recruter un nouveau volontaire. Lorsqu'un utilisateur prend le temps d'écrire sur des listes de diffusion du projet, ou de remplir un rapport de bogue, il se distingue, et montre un plus fort potentiel d'investissement que la majorité des utilisateurs (dont le projet n'entendra jamais parler). Vous devez répondre à ce premier signe : s'il a décrit un bogue, remerciez le pour son rapport, et demandez lui s'il voudrait le corriger lui même. S'il a écrit pour dire qu'une question importante manque à la FAQ ou signaler une carence dans la documentation du programme, reconnaissez le problème (en supposant qu'il existe effectivement), et demandez lui s'il serait intéressé par l'écriture des passages manquants. Évidemment, la plupart du temps les utilisateurs déclineront. Mais ça ne coûte rien de demander, et chaque fois que vous le faites, vous rappelez à tous les lecteurs du forum que chacun est invité à prendre part au projet.

Ne cherchez pas uniquement à recruter de nouveaux développeurs ou de nouveaux auteurs pour la documentation. Entraîner simplement les gens à écrire de bons rapports de bogues porte ses fruits sur le long terme si vous ne passez pas trop de temps sur chaque cas, et s'ils continuent à envoyer des rapports de bogue dans le futur, ce qui est plus probable dans la mesure où le premier rapport a reçu des critiques constructives. Une réaction constructive n'est pas forcément un correctif pour le bogue signalé, même si ce serait évidemment l'idéal, ils veulent surtout une écoute, la correction de bogue ne venant qu'ensuite. Vous ne pourrez pas nécessairement répondre à ce deuxième désir dans un bref délai, mais vous (ou plutôt, le projet entier) peut satisfaire le premier.

Logiquement, les développeurs ne devraient pas s'en prendre à ceux qui font preuve de bonne volonté et remplissent des rapports de bogue manquant de précision. C'est ma bête noire personnelle, je remarque que des développeurs le font tout le temps sur les listes de diffusion ouvertes et les dommages causés sont palpables. Quelques malheureux débutants posteront des rapports inutiles :

Salut, je n'arrive pas à faire marcher Scanley. À chaque fois que je le lance, il plante. Est-ce que quelqu'un d'autre rencontre ce problème ?

Un développeur, qui a déjà vu ce genre de rapport des milliers de fois, mais qui ne se met pas à la place du débutant répondra :

Qu'est ce que qu'on est sensé faire avec si peu d'informations ? Mince ! Donne nous au moins quelques détails, ta version de Scanley, ton système d'exploitation et l'erreur.

Ce développeur n'est pas parvenu à voir les choses du point de vue de l'utilisateur, et n'a pas pris en considération les effets qu'une telle réaction peut avoir sur les personnes assistant à l'échange. Naturellement, un utilisateur qui n'a aucune expérience de programmation, n'ayant jamais rapporté de bogue, ne saura pas comment écrire un rapport de bogue. Comment bien gérer ces situations ? Éduquez les ! Donnez leur envie de revenir :

Désolé que tu rencontres des problèmes. Nous aurons besoin de plus d'informations pour comprendre ce qui t'arrive. S'il te plaît, indique nous ta version de Scanley, ton système d'exploitation et le message d'erreur exact. Le mieux que tu puisses faire est de nous envoyer une copie de ce que tu as exactement tapé et le résultat obtenu. Réfère toi à http://www.scanley.org/how_to_report_a_bug.html pour plus de précisions.

En répondant ainsi il est bien plus probable que vous obteniez les informations nécessaires de la part de l'utilisateur, parce que le message est écrit de son point de vue. Premièrement, vous montrez de la sympathie : tu as eu un problème, nous comprenons ta douleur (ce n'est pas nécessaire dans tous les cas, ça dépend de la gravité du problème et de l'agacement montré par l'utilisateur). Deuxièmement, plutôt que de rabaisser la personne parce qu'elle ne sait pas comment rapporter un bogue, cette réponse lui indique comment faire, et fournit les détails nécessaires pour que cela soit vraiment utile, de nombreux utilisateurs par exemple ne réalisent pas que « montre nous l'erreur » veut dire « montre nous le message d'erreur exact, sans commettre d'omissions ou faire de raccourcis ». Dès le premier contact avec un nouvel utilisateur, vous devez être clair à ce sujet. Finalement cette réponse conclut par un lien vers des instructions plus précises et détaillées à propos des rapports de bogue. Si vous avez fait ce qu'il faut, l'utilisateur prendra souvent le temps de lire ce document, et se conformera aux directives qui s'y trouvent. Vous devez donc, évidemment, le mettre à disposition. Il devrait donner des instructions claires à propos du type d'informations dont votre équipe de développement a besoin pour étudier un rapport de bogue. Le mieux serait qu'il évolue avec le temps en fonction des erreurs que les utilisateurs continuent à faire.

Les instructions concernant les rapports de bogue du projet Subversion représentent un exemple assez standard dans ce domaine (voir Annexe D, Exemples d'instructions pour les rapports de bogues). Notez la conclusion, c'est une invitation à produire un correctif pour réparer le bogue. Ce n'est pas parce qu'une telle invitation vous apportera un meilleur rapport correctif/bogue, la plupart des utilisateurs capables de réparer les bogues savent déjà qu'un correctif serait le bienvenu, on n'a pas besoin de le leur dire. L'invitation a pour but de rappeler à tous les lecteurs, en particuliers aux nouveaux venus dans le projet ou dans le monde des logiciels libres en général, que le projet dépend des contributions de volontaires. Dans un sens, les développeurs ne sont pas plus responsables de la réparation des bogues que la personne l'ayant signalé. C'est un aspect important avec lequel de nombreux volontaires ne sont pas familiers. Une fois qu'ils le réalisent, il y a de meilleures chances qu'ils aident à la création du correctif, à moins qu'ils ne participent au développement du code en fournissant une méthode de reproduction plus complète ou en proposant de tester les correctifs que les autres personnes soumettent. Il faut que tous les utilisateurs réalisent qu'il n'y a pas de barrière imperméable entre eux et l'équipe du projet, que tout est question de degré d'implication et non pas de personnalité.

S'il faut en général être sévère contre les réponses agressives, vous pouvez faire une exception quand les utilisateurs se montrent grossiers. De temps à autres des gens enverront des rapports de bogue ou des plaintes qui, contenu informatif mis à part, sont carrément irrespectueux. Souvent ils alternent entre insultes et flatteries, comme dans ce message écrit pas un utilisateur sur une liste de diffusion de Subversion :

Comment se fait-il qu'après 6 jours, il n'y ait toujours pas d'exécutable pour les plateformes Windows ?!? C'est toujours la même histoire et c'est plutôt frustrant. Pourquoi sa création n'est-elle pas automatisée afin qu'il soit disponible immédiatement ?? Quand vous sortez une version « RC », je pense que le but est que les utilisateurs testent la version, mais vous ne fournissez aucun moyen de le faire. Pourquoi prendre la peine d'avoir une période de mise à l'épreuve si on ne peut pas tester ??

Les premières réponses à ce message plutôt provocateur furent étonnamment modérées : les gens ont mis en avant le fait que le projet avait pour règle de ne pas fournir d'exécutables officiels, et ont suggéré, pas tous avec la même mesure, qu'il devrait plutôt se porter volontaire pour les faire lui même s'ils sont si important à ses yeux. Que vous le croyez ou non sa réponse commençait par ces lignes :

Tout d'abord laissez moi vous dire que je pense que Subversion est génial et je suis reconnaissant des efforts fournis par les personnes impliquées. [...]

...et puis son message continue par des admonestations contre le fait que le projet ne fournissait toujours pas d'exécutable, sans pour autant se porter volontaire pour y remédier. Environ 50 personnes lui sont alors tombées dessus, et je ne peux pas dire que cela m'ait vraiment dérangé. La politique de tolérance zéro évoquée dans la section « Tuez la vulgarité dans l'œuf » dans le Chapitre 2, Bien démarrer s'applique aux gens avec qui le projet a (ou voudrait avoir) une relation durable. Mais quand quelqu'un montre clairement, dès le départ, qu'il causera plus de problème qu'autre chose, il n'y a pas de raison qu'il se sente bien accueilli.

Heureusement, ces situations restent rares. Elles le sont encore plus quand les projets s'attachent, dès le premier contact, à inciter de manière constructive et courtoise les utilisateurs à participer.

Partager les tâches de gestion aussi bien que les tâches techniques

Partagez les tâches de management aussi bien que les tâches techniques pour la bonne marche du projet. À mesure que le projet progresse, vous serez amené à faire beaucoup plus de gestion : gestion des volontaires et gestion du flot d'information. Il n'y a pas de raison pour que vous ne partagiez pas cette charge. Rassurez vous, inutile d'instaurer une hiérarchie verticale pour autant. En pratique, elle ressemblera plus à l'organisation d'un réseau pair à pair qu'à une hiérarchie militaire.

Parfois les rôles de gestion sont attribués formellement, d'autres fois c'est spontané. Dans le projet Subversion, nous avons un responsable correctifs, un responsable traduction, des responsables documentation, des responsables parutions (bien que ce poste reste officieux) et un responsable difficultés. Si certains ont été créés, d'autres se sont créés d'eux mêmes. Quand le projet se développe, il est normal que de nouveaux rôles se dessinent. Nous allons maintenant détailler plus précisément ces postes ainsi que d'autres.

À mesure que vous lisez la description des rôles, vous remarquerez qu'aucun ne requiert le contrôle complet sur un domaine en question. Le responsable parutions n'empêche personne de faire des changements dans le système de contrôle de versions, le responsable FAQ ne s'impose pas comme la seule personne à pouvoir modifier la FAQ, etc. Il s'agit de trouver l'équilibre pour endosser ces responsabilités, sans exercer un contrôle exclusif. Une part importante du travail de tout responsable est de repérer ceux qui travaillent dans son domaine, et de les former à faire les choses à sa manière afin que les efforts de chacun s'additionnent plutôt que d'entrer en conflit. Les responsables devraient documenter leur manière de travailler : si l'un d'eux venait à quitter le projet, on pourra ainsi immédiatement lui succéder.

Il se peut qu'il y ait des conflits : une place convoitée par deux personnes ou plus. Il n'y a pas de manière simple et juste pour résoudre ce problème. Vous pouvez proposer à chaque volontaire d'établir un projet (une « candidature »), et que tous les participants votent pour élire le meilleur. Mais c'est fastidieux et cela peut devenir gênant. Il est plus judicieux, à mon avis, de demander aux candidats de régler cela entre eux. Ils y arriveront en général, et seront plus satisfaits du résultat que si la décision leur avait été imposée de l'extérieur.

Responsable correctifs

Dans un projet de logiciel libre qui reçoit de nombreux correctifs, les suivre tous et rester au fait de ce qui a été décidé pour chacun d'eux peut être un vrai cauchemar, particulièrement s'ils ne sont pas centralisés. La plupart des correctifs sont envoyés sur la liste de diffusion des développeurs, mais pas tous. Certains apparaitront en premier sur le suivi de bogues ou sur un autre site Web. Et la vie d'un correctif est tout sauf un long fleuve tranquille.

Si, en inspectant le correctif, quelqu'un y décèle un problème, il le renverra parfois à son auteur pour qu'il y remédie. Cela donne généralement naissance à un processus itératif, parfaitement visible sur la liste de diffusion, dans lequel l'auteur renvoi des versions revues du correctif jusqu'à ce que le relecteur ne trouve plus rien à critiquer. Ce n'est pas toujours évident de déterminer quand ce processus a atteint son terme. Si le relecteur met la modification sur le site alors le cycle est clairement achevé. Mais s'il ne le fait pas, peut être n'en a-t-il simplement pas eu le temps, ou n'a-t-il pas l'accès nécessaire pour entrer en contact avec un autre développeur pour que ce dernier le fasse.

La soumission d'un correctif peut aussi être à l'origine d'une discussion libre, pas forcément à propos du correctif lui même, mais sur le concept sous-jacent, à savoir s'il est bon ou mauvais. Il peut, par exemple, corriger un bogue, mais le projet préfère régler ce bogue d'une autre manière, au sein de la résolution d'un problème plus général. Le fond de la discussion n'est pas prévisible par avance, et c'est le correctif qui stimule la découverte.

À l'occasion, un correctif proposé ne soulève aucune réaction. C'est, en général, parce que les développeurs manquent de temps à ce moment précis pour inspecter le correctif, et chacun espère qu'une autre personne le fera. Comme cette période n'a pas de limites déterminées, chacun attend que les choses soient prises en main, et d'autres tâches importantes arrivant sans cesse, un correctif peut facilement passer au travers des mailles du filet sans que personne ne l'ait vraiment voulu. Non seulement le projet peut passer à côté d'un correctif utile, mais en plus, l'auteur, qui a fourni des efforts pour faire ce correctif, est découragé, et le projet peut sembler un peu déconnecté, en particulier aux yeux de ceux qui envisagent d'écrire des correctifs, c'est bien là le plus grave.

Le responsable correctifs doit donc s'assurer qu'aucun correctif ne « passe au travers des mailles du filet ». Il lui faut pour cela suivre chaque correctif jusqu'à ce qu'il n'évolue plus. Le responsable correctifs surveille tous les sujets des listes de diffusion liés à la publication de correctifs. Si le sujet abouti à la sortie du correctif, alors il n'a rien à faire. S'il entre dans un processus itératif d'inspection/amélioration le responsable le suit. Si une fois le processus achevé le correctif n'est pas publié, il doit remplir un rapport de problème pointant vers la version finale et vers la liste de diffusion concernée, afin qu'il bénéficie toujours d'une certaine attention. Si le correctif répond à un problème existant, il ajoute une note au rapport avec les informations pertinentes plutôt que de commencer un nouveau rapport.

Quand un correctif ne suscite aucune réaction, le responsable correctifs patiente quelques jours, puis demande si quelqu'un compte l'inspecter. En général, sa question ne restera pas lettre morte : un développeur peut expliquer qu'il ne pense pas que le correctif doive être appliqué, en donnant ses raisons, ou qu'il pourrait le contrôler, dans quel cas, on en revient à l'un des mécanismes précédemment décrits. S'il n'y a toujours pas de réponse le responsable correctifs peut, ou peut ne pas, remplir un rapport pour ce correctif, à sa discrétion, mais au moins, la personne l'ayant soumis recevra un retour.

Avoir un responsable correctifs a permis d'économiser beaucoup de temps et d'énergie à l'équipe de développement de Subversion. Sans une personne désignée pour prendre cette responsabilité, tous les développeurs se demanderaient sans cesse « Si je n'ai pas le temps de répondre à ce correctif maintenant, est-ce que je peux compter sur les autres pour le faire ? Devrais-je essayer de garder un œil dessus ? Mais si pour les mêmes raisons d'autres personnes font de même, on va alors dupliquer cet effort inutilement ». Le responsable correctifs évite ces « et si... ». Chaque développeur peut prendre la bonne décision, pour lui, au moment où il découvre le correctif. S'il décide de se charger de l'inspection, il peut le faire, le responsable correctifs agira en conséquence. S'il veut ignorer complètement le correctif, ce n'est pas grave, le responsable correctifs est là pour s'assurer qu'il ne tombera pas complètement dans l'oubli.

Ce rôle devrait rester formel car il revient alors à une personne qui devrait toujours être active. Dans Subversion nous avions envoyé nos annonces aux listes de diffusion des développeurs et des utilisateurs, plusieurs réponses sont arrivées, et nous avons sélectionné le plus rapide. Quand il a dû abdiquer (voir la section nommée « Transitions » plus loin dans ce chapitre), nous avons recommencé. Nous aurions pu attribuer ce rôle à plusieurs personnes, mais nous avons choisi de ne pas le faire à cause de la transparence requise dans leurs conversations. Mais peut-être serait-il plus logique de se reposer sur plusieurs responsables pour traiter de très gros volumes de correctifs.

Responsable traduction

Pour un logiciel, « traduction » peut avoir deux significations très différentes. Il y a la traduction de la documentation en plusieurs langues d'une part et la traduction du logiciel d'autre part. Le logiciel traduit affiche les erreurs et les messages d'aide dans la langue choisie par l'utilisateur. Les deux tâches sont complexes mais, une fois la bonne infrastructure en place, elles sont bien dissociables du reste du développement. Ces tâches s'avérant semblables sous certains aspects, vous pouvez n'avoir qu'un seul responsable traduction pour les deux, mais il peut aussi être plus intéressant d'en avoir deux différents.

Dans le projet Subversion, nous avons un responsable traduction qui s'occupe des deux. Il ne traduit pas vraiment lui même, même s'il peut bien sûr y aider de temps en temps, mais en plus de sa langue maternelle, il devrait parler dix langues (douze si on compte les dialectes) pour pouvoir travailler sur chacune ! Son rôle est donc de gérer les équipes de traducteurs volontaires : il les aide à se coordonner entre eux, et fait le lien entre les équipes et le reste du projet.

Le responsable traduction est utile car les traducteurs et les développeurs sont deux groupes bien distincts. Parfois, ils sont complètement étrangers au travail sur un dépôt de gestion de versions, ou même au travail au sein d'une équipe éparse de volontaires. Mais à d'autres égards, ce sont souvent les meilleurs volontaires : des gens, avec un savoir particulier dans un domaine particulier, qui ont entrevu un besoin et ont décidé de participer. En général, ils ont soif d'apprendre et enthousiastes au travail. Ils ont juste besoin de quelqu'un pour les guider. Le responsable traduction s'assure que la traduction se passe sans créer d'interférences inutiles avec le développement régulier. C'est aussi lui qui représente les traducteurs lorsque les développeurs doivent être informés d'une modification technique nécessaire pour aider l'effort de traduction.

Les compétences les plus importantes à avoir ne sont donc pas techniques mais diplomatiques. Dans Subversion, par exemple, nous demandons que pour chaque traduction, il y ait au moins deux personnes, autrement le texte ne pourrait pas être relu. Quand un nouveau volontaire arrive en proposant de faire la traduction de Subversion, en malgache par exemple, le responsable traduction doit essayer de le mettre en relation avec quelqu'un ayant posté six mois auparavant avec le même désir de faire une traduction malgache, ou lui demander poliment de trouver un autre traducteur malgache pour qu'ils s'associent. Quand ce quota est atteint, le responsable traduction leur donne l'accès nécessaire, les informe des règles du projet (comment écrire un message dans le registre par exemple), puis garde un œil sur eux pour voir s'ils suivent bien ces règles.

Les échanges entre le responsable traduction et les développeurs, ou entre le responsable traduction et les équipes de traduction se font en général dans la langue maternelle du projet, c'est à dire, la langue depuis laquelle toutes les traductions sont réalisées. Pour la plupart des projets de logiciel libre, c'est l'anglais, mais cela importe peu du moment que c'est en accord avec le projet (l'anglais est sûrement la langue la plus indiquée pour les projets désirant attirer une importante communauté de développeurs internationaux).

Au sein d'une équipe de traduction, les membres parleront en général entre eux dans leur langue commune, et l'une des tâches dévolue au responsable traduction est de mettre en place des listes de diffusions dédiées. Ainsi, les traducteurs peuvent discuter plus librement, sans déranger les gens sur les listes principales du projet, la plupart d'entre eux n'en comprendraient pas le contenu de toute manière.

Responsable documentation

Maintenir la documentation du logiciel à jour est une tâche sans fin. Chaque nouvelle fonctionnalité ou amélioration ajoutée au code est potentiellement source de modification de la documentation. Aussi, lorsque la documentation du projet atteint un certain niveau d'achèvement, vous remarquerez que beaucoup de correctifs envoyés concernent la documentation et non pas le code. Simple effet de masse, plus de gens sont compétents pour corriger la prose que le code : tous les utilisateurs sont des lecteurs, mais seulement un faible pourcentage d'entre eux sont des programmeurs.

Les correctifs pour la documentation sont en général plus simple à inspecter et à appliquer que les correctifs pour le code. Puisque leur nombre est élevé, mais le travail d'inspection faible, le ratio travail administratif sur travail productif est plus élevé pour les correctifs de documentation que pour le code. De plus, la plupart des correctifs demanderont sûrement quelques ajustements, de manière à assurer la cohérence de la documentation. Les correctifs bruts seront rarement applicables, ils se chevauchent ou sont interdépendants, et doivent donc être ajustés avant d'être validés.

Le traitement des correctifs de la documentation est exigeant. Le code source doit sans cesse être surveillé pour que la documentation reste à jour. Il est donc logique de dédier une personne ou une petite équipe à cette tâche. Ils savent exactement où et dans quelle mesure la documentation a pris du retard sur le logiciel, et peuvent avoir mis au point des procédures avancées de traitement de grandes quantités de correctifs.

Bien sûr, cela n'empêche personne du projet d'améliorer la documentation à la volée, en particulier de faire de petites corrections quand le temps le permet. Et le responsable correctifs (voir la section appelée « Responsable correctifs » plus tôt dans ce chapitre) peut suivre à la fois les correctifs pour le code et ceux pour la documentation, les archivant là ou les équipes de développement ou de documentation en ont besoin (si la quantité de correctifs dépasse une limite humainement tenable, séparer la tâche du responsable correctifs entre deux responsables, code et documentation, sera peut-être un bon premier pas). L'équipe de documentation doit maintenir la cohésion entre les gens se sentant responsables de la traduction afin qu'ils soient organisés, cohérents et toujours à jour. En pratique, cela passe par une connaissance intime de la documentation, une surveillance étroite du code source et des modifications apportées par les autres à la documentation, mais aussi par le suivi des correctifs de documentation entrants, et par l'utilisation de toutes ces informations pour faire tout ce qui est nécessaire en vue de maintenir la documentation en bonne santé.

Responsable difficultés

Le nombre de problèmes dans le suivi de bogues augmente proportionnellement au nombre d'utilisateurs. Par conséquent, même si vous corrigez les bogues et proposez un programme de plus en plus solide, vous devez toujours vous attendre à observer une augmentation du nombre de problèmes non traités, sans forcément qu'ils aient de liens entre eux. Non seulement vous verrez apparaître de plus en plus de doublons, mais les rapports mal rédigés seront également plus nombreux.

Les responsables difficultés aident à soulager ces problèmes en surveillant ce qui entre dans la base de donnée et en l'inspectant entièrement régulièrement à la recherche de problèmes particuliers. Leur activité la plus courante est certainement d'arranger les rapports de problèmes entrants, soit parce que le rapporteur n'a pas rempli certains champs du formulaire correctement, soit parce qu'un rapport semblable est déjà archivé. Évidemment, le responsable difficultés sera vraiment à même de détecter les doublons s'il est familier avec la base de données de bogue du projet. À ce titre, si vous pouvez amener quelques personnes à se spécialiser dans la base de données de bogue, le nettoyage de celle-ci sera fait beaucoup plus efficacement que si chacun y apporte sa petite contribution. Cette tâche demande vraiment une connaissance approfondie de la base de données, et personne ne l'acquiert quand tout le groupe tente de la mener à bien dans le désordre général.

Les responsables difficultés peuvent aussi aider à attribuer les problèmes à des développeurs précis. Face à la masse de bogues pouvant être signalés, chacun ne suit pas la liste de diffusion avec la même attention. Cependant, si quelqu'un surveille tous les rapports entrants, et qu'il connait bien l'équipe de développement, il peut attirer l'attention des développeurs concernés sur des bogues particuliers. Des paramètres extérieurs sont à prendre en compte, comme le déroulement du développement ou les envies et le tempérament du destinataire. Il serait donc souhaitable que les responsables difficultés soient eux-mêmes développeurs.

Selon l'utilisation que fait votre projet du suivi de problèmes, les responsables difficultés peuvent modeler la base de données pour qu'elle reflète les priorités du projet. Par exemple, dans Subversion nous essayons de donner une prévision en terme de versions pour la correction des bogues. Lorsqu'il est demandé « Quand sera réglé le problème X ? », nous pouvons ainsi répondre « Dans deux versions », même si nous ne donnons pas de date exacte. Les sorties sont représentées dans le suivi de problèmes comme des jalons à atteindre, un champ disponible dans IssueZilla.[27] La règle en vigueur est que chaque nouvelle version de Subversion apporte une nouvelle fonctionnalité principale ainsi qu'une liste de correctifs de bogues particuliers. Pour chaque version, nous nous fixons des objectifs et une liste de problèmes à corriger. La nouvelle fonctionnalité en fait partie puisqu'elle devient aussi un problème . Les utilisateurs peuvent alors consulter la base de données pour connaître les améliorations à venir dans les versions prévues. En général cependant, ces objectifs sont modifiés. À mesure que de nouveaux bogues sont rapportés, les priorités sont réorganisées et les problèmes doivent être déplacés d'un jalon à un autre, afin que chaque version reste faisable. Pour ceci, encore une fois, les personnes ayant une vue d'ensemble, du contenu de la base de données et des liens entre les problèmes, sont mieux placées pour prendre ces décisions.

Les responsables difficultés doivent aussi trier les problèmes obsolètes. Un bogue peut tout simplement être réglé au gré des modifications, même sans être spécifiquement ciblé. Et ce qui est un bogue pour une personne peut être une fonctionnalité pour une autre ; le projet peut simplement changer son point de vue. Débusquer les problèmes obsolètes n'est pas simple, une seule solution : passer en revue toute la base de données consciencieusement. Les révisions complètes deviennent plus fastidieuses avec le temps et l'accroissement du nombre de problèmes. Il existe un seuil au-delà duquel, pour conserver une base de données saine, votre seul recours sera de « diviser pour mieux régner » : classer les problèmes immédiatement quand ils sont rapportés, et les rediriger vers le bon développeur ou la bonne équipe. Le destinataire prend alors la responsabilité du problème ad vitam æternam, le menant vers une résolution ou vers l'oubli selon la situation. Quand la base de données devient trop importante, le responsable difficultés se mue alors en coordinateur, il passe moins de temps à s'occuper du problème lui même qu'à le rediriger vers la bonne personne.

Responsable FAQ

L'entretien de la FAQ est un problème étonnamment difficile. Contrairement à la majeure partie des autres documents du projet, dont le contenu est planifié à l'avance par leurs auteurs, une FAQ est un document très réactif (voir « Entretenir une FAQ »). Son amélioration est par nature imprévisible. Et parce qu'elle est complétée au fur et à mesure, le document complet peut facilement devenir incohérent et désorganisé, voire même contenir des entrées en double ou très semblables. Même quand vous n'êtes pas confrontés à ces problèmes, certaines questions sont souvent liées entre elles. Malheureusement ces liens ne sont pas toujours détectés si les entrées ont été faites à une année d'intervalle par exemple.

Le rôle du responsable FAQ est double. Premièrement, il assure la qualité globale de la FAQ par sa connaissance des sujets abordés, ainsi, quand des gens ajoutent de nouvelles questions déjà posées, ou liées à d'autres déjà posées, il peut réaliser les corrections nécessaires. Deuxièmement, il surveille les listes de diffusion du projet et les forums pour repérer les problèmes ou les questions récurrentes, puis il crée une nouvelle entrée à la FAQ si besoin est. Cette tâche n'a rien de simple : la personne doit être capable de suivre un sujet, reconnaître le cœur du problème soulevé, proposer une nouvelle entrée pour la FAQ, tenir compte des commentaires extérieurs (puisqu'il est impossible que le responsable FAQ soit expert dans tous les domaines couverts par la FAQ) et estimer quand le processus est achevé et que l'entrée peut être ajoutée.

Le responsable FAQ devient en général l'expert de la mise en page de la FAQ par défaut. De nombreux petits détails sont à prendre en compte dans la mise en forme de la FAQ (voir la section appelée « Traiter toutes les ressources comme des archives » dans le Chapitre 6, Communication) ; quand une personne modifie la FAQ, elle oubliera souvent certains de ces détails. Ce n'est pas grave tant que le responsable FAQ passe derrière pour corriger ces erreurs.

Il existe différents logiciels libres aidant à l'entretien de la FAQ. Vous pouvez les utiliser tant qu'ils ne compromettent pas la qualité de la FAQ, faites attention à l'abus d'automatisation. Certains projets tentent de rendre l'entretien de la FAQ entièrement automatique, permettant à chacun de contribuer à la FAQ et d'en modifier les entrées, à la manière d'un wiki (voir la section appelée « Wikis » dans le Chapitre 3, Infrastructure technique). C'est flagrant pour ceux qui utilisent Faq-O-Matic (http://faqomatic.sourceforge.net/), bien que les exemples que j'ai observés pouvaient être dus à une sur-automatisation, ce pour quoi Faq-O-Matic n'est pas prévu à l'origine. Quoi qu'il en soit, en optant pour les avantages qu'offrent une FAQ entièrement automatisée, vous devrez vous contenter d'un document de plus mauvaise qualité. Personne n'a une vue d'ensemble de la FAQ, personne ne peut remarquer les articles qui nécessitent une mise à jour ou qui sont devenus complètement obsolètes et personne ne surveille les liens entre les questions. Au final les utilisateurs trouveront rarement l'aide qu'ils étaient venus chercher dans la FAQ. Dans le pire des cas, elle les induira même en erreur. Utilisez tous les outils nécessaires à l'entretien de la FAQ du projet, mais ne tombez pas dans la facilité, la qualité de votre FAQ s'en ressentirait.

Vous pouvez lire l'article de Sean Michael Kerner : La FAQ des FAQ à l'adresse http://osdir.com/Article1722.phtml, vous y trouverez des descriptions et des évaluations d'outils Open Source pour l'entretien d'une FAQ.

Transitions

De temps à autres, un volontaire occupant une place importante (par exemple responsable correctifs, responsable traductions, etc.) ne pourra plus remplir ses fonctions. Les raisons peuvent être diverses : charge de travail trop importante, mariage, nouveau bébé, nouvel employeur, etc.

Quand un volontaire se retrouve submergé ainsi, il ne le remarque pas forcément de suite. Ça se passe en douceur, il n'y a pas de moment précis où il prend conscience de son incapacité à assumer ses responsabilités. Il se fait discret pendant un certain temps, puis soudainement, vous verrez un accroissement d'activité quand, réalisant qu'il a négligé le projet pendant trop longtemps, il prend une nuit pour rattraper son retard. Puis vous n'entendrez plus parler de lui à nouveau pendant un certain temps, et vous verrez peut-être nouveau un regain d'activité. Les démissions ne seront que rarement spontanées. Si c'est un volontaire, il travail sur son temps libre. Démissionner revient alors à avouer que son temps libre a été définitivement réduit, ce qu'on a souvent du mal à reconnaître ou accepter.

C'est donc votre rôle, ou celui des autres membres du projet, de remarquer quand quelque chose se passe, ou plutôt ne se passe pas, et de demander au volontaire si tout va bien. Ne prenez pas un ton accusateur, c'est une demande amicale. Vous cherchez une information, pas à mettre l'autre personne mal à l'aise. De manière générale, la demande devrait être faite ouvertement devant le reste du projet, mais si des circonstances particulières vous poussent à le faire en privé, cela ne pose pas de problème. Il y a une bonne raison de faire la demande en public : si le volontaire répond qu'il ne sera plus capable d'accomplir le travail, un contexte sera déjà établi pour votre prochaine annonce publique : la recherche d'un nouveau volontaire pour le remplacer.

Il peut arriver qu'un volontaire ne remplisse pas le rôle qu'on attend de lui. Il ne le remarquera pas forcément ou peut refuser de l'admettre. Bien sûr, chacun peut connaître des difficultés au départ, surtout si la tâche est complexe. Cependant, si la personne n'est pas à la hauteur des responsabilités qui lui ont été confiées, malgré l'aide des autres participants, l'unique solution pour lui est de s'effacer et de donner sa chance à un autre. Si cette personne ne s'en rend pas compte d'elle-même, quelqu'un devra le lui dire. Je ne vois qu'une bonne manière de procéder, c'est un processus en plusieurs étapes où chacune est importante.

En premier, assurez vous que vous n'êtes pas fou. Sondez en privé l'avis des autres membres du projet pour savoir s'ils partagent le même sentiment que vous par rapport au problème. Même si vous êtes déjà sûr de vous, cela permettra de faire savoir aux autres que vous envisagez de demander à cette personne d'abandonner son rôle. En général personne ne fera d'objection, ils seront soulagés que vous vous chargiez de cette tâche embarrassante et qu'ils n'aient pas à le faire.

Ensuite, contactez le volontaire en question, en privé, et informez le, gentiment mais de manière directe, du problème. Soyez précis et donnez autant d'exemples que possible. Assurez vous de bien mettre en avant l'aide proposée par les autres mais que les problèmes ont persisté sans amélioration. Prenez tout votre temps pour rédiger cet e-mail mais, pour ce genre de message, si vous n'étayez pas vos observations, mieux vaut ne rien faire. Annoncez lui que vous voudriez chercher un autre volontaire pour ce rôle, mais indiquez également qu'il existe bien d'autres manières d'apporter sa contribution au projet. Pour le moment ne dites pas encore que vous en avez parlé à d'autres, personne n'apprécie qu'on lui dise qu'il est le sujet d'une conspiration.

Les choses peuvent prendre différentes tournures ensuite. Le plus probable est que la personne sera d'accord avec vous, ou qu'au moins elle ne vous contredira pas, et cèdera volontairement sa place. Dans ce cas, proposez lui de faire l'annonce lui même et de vous laisser vous occuper du message pour lui trouver un remplaçant.

Il peut aussi être d'accord sur le fait qu'il y a eu des problèmes mais demandera un sursis (ou une nouvelle chance dans le cas d'une tâche ponctuelle comme responsable parutions). Suivez votre jugement, mais peu importe ce que vous faites, ne donnez pas votre accord simplement parce que vous pensez que la demande est raisonnable. Cela ne ferait que prolonger l'agonie, pas la réduire. En général, les choses n'en sont pas arrivées là par hasard, la personne a déjà bénéficié de beaucoup d'opportunités, elle a déjà eu sa seconde chance. Nous avons eu le cas avec un responsable parutions qui ne faisait pas vraiment ce qu'on attendait de lui, voilà comment j'ai tourné mon e-mail :

  > Si tu veux me faire remplacer par quelqu'un d'autre, je passerai
  > la main sans problème. J'aurai juste une demande, qui je l'espère
  > n'est pas déraisonnable. J'aimerai qu'on m'accorde une sortie de plus
  > pour pouvoir prouver ma valeur.

  Je comprends totalement ton désir (je suis passé par là moi aussi !),
  mais dans le cas présent on ne devrait pas procéder ainsi.
  Ce n'est pas la première ou deuxième parution, c'est la sixième ou 
  septième... Et je sais qu'à chaque fois tu avais un sentiment 
  d'inachevé (parce qu'on en a déjà parlé avant). Tu as donc déjà eu ta 
  seconde chance. Il faut bien un dernier essai... 
  Je pense que [cette dernière parution] devrait l'être.

Dans le pire des cas le volontaire peut montrer ouvertement son désaccord. Vous devrez alors accepter ce passage délicat : il faudra bien vous faire entendre coûte que coûte. Le moment sera venu de dire que vous en avez déjà parlé à d'autres (mais ne dévoilez pas leur identité sans leur permission puisque ces discussions sont sensées rester confidentielles), et que, pour le bien du projet, vous ne pensez pas qu'il faille continuer ainsi. Insistez, mais ne devenez pas menaçant. Gardez en tête que pour la plupart des postes la transition devient effective au moment où une nouvelle personne commence le travail, pas au moment où son prédécesseur arrête de le faire. Si la controverse touche le rôle de responsable difficultés par exemple, vous ou n'importe quelle autre personne influente dans le projet peut solliciter un nouveau responsable difficultés à n'importe quel moment. La personne qui le faisait avant n'a pas vraiment besoin d'arrêter de faire son travail, tant qu'elle ne sabote pas (délibérément ou pas) les efforts du nouveau responsable.

Mais alors, plutôt que de demander à la personne de démissionner, pourquoi ne pas l'encadrer sous prétexte de lui apporter un peu d'aide ? Pourquoi ne pas utiliser deux responsables difficultés, correctifs ou autre ? L'alternative semble tentante, mais...

Bien qu'en théorie l'idée semble bonne, en général elle ne l'est pas. Ce qui fait que le rôle de manager fonctionne, ce qui le rend utile en fait, est la centralisation. Tout ce qui peut être fait de manière décentralisée l'est en général déjà. Pour que deux personnes accomplissent une tâche de gestion, il faut qu'elles communiquent, ce qui implique un délai supplémentaire, sans oublier les erreurs de communication potentielles (« Je pensais que tu avais pris le kit de premiers soins ! » « Moi ? Non, je pensais que tu l'avais pris ! »). Bien sûr, il y a des exceptions. Parfois deux personnes travaillent extrêmement bien ensemble, ou alors le rôle peut être naturellement partagé facilement entre plusieurs personnes. Mais ça ne fera pas une grande différence dans le cas d'une personne se démenant dans un rôle pour lequel elle n'est pas faite. Si, dès le début, il se sentait à l'aise avec ce problème, il aurait demandé l'aide nécessaire bien avant. Dans tous les cas, ce serait un manque de respect que de laisser quelqu'un continuer un travail auquel personne ne prêtera attention.

Lorsque vous demandez une démission, observez la discrétion de rigueur : il n'y a rien de pire que de se savoir observé et sous pression. J'ai fait cette erreur une fois, une erreur évidente quand j'y repense, j'ai adressé un courrier aux trois parties pour demander au responsable parutions de Subversion de démissionner au profit de deux autres volontaires. J'en avais déjà parlé en privé avec ces deux derniers, et je savais qu'ils étaient désireux d'endosser cette responsabilité. Alors j'ai pensé, naïvement et avec peu de tact, que je gagnerai du temps et m'éviterai des tracas en leur envoyant à tous un courrier pour commencer la transition. Je supposais que le responsable parutions était déjà au courant des problèmes et comprendrait ma démarche sans problème.

J'ai eu tort. Le responsable parutions de l'époque s'est senti insulté, à raison. C'est une chose de se voir demander de passer la main, s'en est une autre quand c'est fait devant les personnes qui prendront la main. Dès que j'ai compris ce qui l'avait insulté, je me suis excusé. Finalement, il a démissionné et continue, aujourd'hui encore, à être impliqué dans le projet. Mais son amour propre fut blessé, sans oublier que les nouveaux responsables prenaient leurs fonctions dans un contexte délicat.

Committers

Les committers sont vraiment un groupe à part dans les projets Open Source, et à ce titre, ils méritent une attention particulière. Les committers sont la seule exception dans un système qui, normalement, est aussi peu discriminatoire que possible. « Discrimination » n'est pas pris dans un sens péjoratif ici. Le rôle des committers est absolument essentiel, je ne pense pas qu'un projet puisse réussir sans eux. Le contrôle qualité demande un... contrôle. Beaucoup de personnes se sentent capables d'apporter des modifications au programme, mais peu le sont vraiment. Le projet ne peut pas se reposer sur le seul jugement des gens, il doit imposer des normes, et accorder un accès de commit à ceux qui les respectent [28]. D'un autre côté, créer une caste induit un rapport de force. Ce rapport de force doit être encadré afin de ne pas nuire au projet.

Dans la section « Qui vote ? » dans le Chapitre 4, Infrastructure sociale et politique, nous avons déjà parlé du mécanisme de recrutement de nouveaux committers. Ici, nous nous intéresserons aux critères d'évaluation des nouveaux committers potentiels et à la présentation de ce processus à la communauté entière.

Choisir les committers

Dans le projet Subversion, notre premier critère de sélection est le Serment d'Hippocrate. Premier commandement : ne fait rien de mal. Notre critère principal n'est pas l'aptitude technique ou même la connaissance du code, mais simplement le bon jugement dont fait preuve le committer. Un exemple de bon jugement ? Savoir simplement quoi ne pas incorporer par exemple. Une personne peut envoyer de petits correctifs, réparant des problèmes basiques du code ; mais si les correctifs s'appliquent proprement, qu'ils ne contiennent pas de bogues et sont en accord avec le journal de messages du projet et les conventions d'écriture du code et qu'ils sont assez nombreux pour attester d'une certaine constance, alors un des committers pourra suggérer d'attribuer à ce développeur un accès de commit. Si au moins trois personnes disent oui et que personne ne s'y oppose la proposition est faite. Nous ne savons pas s'il est capable de résoudre des problèmes complexes dans tous les domaines du code, mais ce n'est pas important : il a au moins montré qu'il est capable de juger de ses propres compétences. Les aptitudes techniques peuvent s'apprendre (et être enseignées), mais le jugement est en grande partie inné. C'est donc cette qualité que vous cherchez chez une personne à qui vous voulez donner l'accès de commit.

Quand on propose de donner l'accès de commit, et que cette suggestion est controversée, ce ne sont en général pas les aptitudes techniques de la personne qui sont mises en cause, mais plutôt son comportement sur les listes de diffusion et sur IRC. Parfois, un développeur fait preuve de grandes qualités techniques et d'une bonne éthique de travail, mais en même temps, il se montre systématiquement hargneux ou peu coopératif sur les forums publics. C'est un problème sérieux. S'il n'offre pas de signes d'amélioration, malgré nos allusions, alors nous ne lui offriront pas les responsabilités de committer, même s'il est très doué. Dans un groupe de volontaires, les aptitudes sociales et la capacité à « bien jouer dans le bac à sable » sont aussi importantes que les aptitudes techniques brutes. Si votre choix de committer ne s'avère pas judicieux, ce n'est pas tant au niveau technique que les conséquences sont graves. La gestion de versions permet de revenir sur des mauvaises décisions. Par contre, le projet pourrait être forcé d'annuler l'accès de commit de cette personne, une chose qui n'est jamais plaisante et qui peut parfois être conflictuelle.

Beaucoup de projets insistent sur le fait que le committer potentiel fasse preuve d'un certain niveau d'expertise technique et d'implication en proposant un nombre non négligeable de correctifs non triviaux, ce qui veut dire que ces projets ne veulent pas seulement s'assurer que cette personne ne causera pas de dégâts, ils veulent savoir si elle est susceptible d'apporter des améliorations au code. C'est compréhensible, mais attention, ne transformez l'accès de commit en une carte de membre d'un groupe fermé. La question à se poser est : « Qu'est ce qui sera le plus bénéfique au code ? » et non « Allons nous abaisser le statut social associé au rôle de commit en acceptant cette personne ? ». Le but d'un accès de commit n'est pas de renforcer le statut d'une personne mais de permettre l'ajout de bons changements au code sans trop le perturber. Si sur 100 committers vous en avez 10 qui font de grands changements régulièrement et les 90 autres qui se contentent de corriger des erreurs de frappes et des bogues minimes quelques fois dans l'année, c'est toujours mieux que si n'aviez que 10 committers.

Révoquer un accès de commit

Quoiqu'il arrive, éviter de devoir révoquer un accès de commit. Chaque cas de figure est différent, mais vous y perdrez de l'énergie et un temps précieux, vous avez certainement mieux à faire.

Cependant, si vous devez vous y résoudre, cette discussion ne doit pas être publique. N'y participent que ceux pouvant décider par vote d'informer le principal intéressé de la situation. La personne ne devrait pas être engagée dans la discussion. On est loin de la transparence prônée précédemment, mais, dans ce cas, c'est nécessaire. D'abord, c'est une condition nécessaire pour que chacun s'exprime librement.. Ensuite, si le vote échoue, vous ne voulez pas forcément que la personne sache que son éviction a été considérée, vous voulez éviter les interrogations néfastes (« Qui était de mon côté ? » ; « Qui était contre moi ? »). En guise d'avertissement le groupe pourrait décider de révéler à la personne la remise en cause de son accès de commit, mais c'est une décision de groupe. Personne ne devrait de sa propre initiative révéler l'existence d'une discussion et d'un scrutin sensé être secret.

Révoquer l'accès de quelqu'un, revient à rendre cette information publique (voir la section appelée « Éviter le mystère » plus loin dans ce chapitre), essayez donc de faire preuve d'autant de tact que possible dans la manière dont vous le présentez au monde extérieur.

Accès de commit restreint

Certains projets ont différents niveaux d'accès de commit. Par exemple, certains participants peuvent jouir d'un accès de commit leur laissant toute liberté sur la documentation, mais n'ont pas le même accès au code. On retrouve en général ces accès limités dans les domaines de la documentation, de la traduction, des liens entre le code et d'autres langages de programmation, des instructions détaillées pour la création de paquets (par exemple : les Redhat RPM spec files, etc.) et les autres domaines pour lesquels une erreur n'aura pas d'incidence sur le code.

Puisque l'accès de commit ne relève pas que de la technique, mais aussi de la politique du projet (voir la section appelée « Qui vote ? » dans le Chapitre 4, Infrastructure sociale et politique), la question suivante se pose naturellement : à quels votes peuvent prendre part les committers restreints ? En fait tout dépend du découpage de votre projet en domaines de commit restreints. Dans Subversion, les choses sont simples : un committer restreint peut voter pour les questions qui touchent exclusivement à son domaine et pour rien d'autre. Ce qui est important est que nous avons mis en place un système de « vote conseil » (en gros, le committer écrit « +0 » ou « +1 (ne compte pas) » plutôt que simplement « +1 » sur son bulletin). Leur vote ne compte pas formellement, mais ça n'est pas une raison pour les bâillonner complètement.

Les committers non-restreints ont accès à tous les domaines. De la même manière ils peuvent se prononcer sur tous les domaines aussi. Ce sont eux, et eux seuls, qui peuvent voter pour l'admission de nouveaux committers (quelque soit l'étendue de leur futur accès). En pratique pourtant, pour les committers restreints, cette tâche est souvent déléguée : n'importe quel committer non-restreint peut « parrainer » un nouveau committer restreint, et les committers restreints dans un domaine peuvent souvent choisir les nouveaux committers de ce même domaine (c'est particulièrement pratique pour permettre un travail de traduction sans accrocs).

Ce sont là des principes généraux, vous pouvez évidemment les adapter aux spécificités de votre projet, mais ils sont assez communs. Chaque committer vote dans la limite des privilèges qui lui sont attribués. Chaque committer devrait pouvoir exprimer son vote sur les questions qui sont de son ressort, mais pas sur les questions qui sont au delà de son champ d'accès. Les votes sur les questions procédurales devraient par défaut incomber aux committers ayant tous les droits, à moins qu'il n'existe des raisons (décidées par les committers non-restreints) pour élargir le suffrage.

Concernant l'accès de commit restreint ; il vaut souvent mieux que ce ne soit pas le logiciel de gestion de versions qui fasse respecter les domaines d'accès de commit restreint. Je vous renvoie à la section appelée « Autorisation » dans le Chapitre 3, Infrastructure technique pour en connaître les raisons.

Les committers en hibernation

Certains projets retirent automatiquement leur accès de commit aux gens qui ne valident plus de modifications pendant un certain temps (un an par exemple). Je n'en vois pas l'intérêt, je pense même que c'est contre-productif pour deux raisons.

D'abord parce que les gens pourraient se sentir obligés de valider des modifications acceptables mais inutiles simplement pour éviter que leur accès de commit n'expire. Ensuite, parce que ça ne sert pas vraiment à grand chose. Le statut de committer « consacre » le discernement dont fait preuve une personne. Ce n'est pas parce qu'elle s'éloigne du projet que son jugement se déprécie. Même s'il ne donne pas signe de vie pendant des années, qu'il ne regarde pas le code et qu'il ne suit pas les discussions autour du développement, au moment de sa réapparition, il aura conscience du retard accumulé et agira en fonction. Vous aviez confiance en son jugement précédemment, alors pourquoi changer ? Si les diplômes obtenus au lycée n'ont pas de date limite de validité, alors les accès de commit ne devraient pas en avoir non plus.

Parfois un committer peut demander à être remplacé ou à être clairement marqué comme étant inactif sur la liste des committers (voir la section appelée « Éviter le mystère » ci-dessous pour plus de détails à propos de cette liste). Dans ce cas, le projet devrait évidemment satisfaire à la demande de cette personne.

Éviter le mystère

Même si les discussions pour accorder un nouvel accès de commit doivent être confidentielles, les règles et procédures en elles-mêmes n'ont pas besoin d'être secrètes. En fait, il vaut mieux les publier, ainsi les gens se rendent compte que les committers ne font pas partie d'une sorte de « carré VIP » mystérieux dont l'accès est interdit aux simples mortels, mais que chacun peut y aspirer en proposant de bons correctifs et en sachant se comporter en communauté. Dans le projet Subversion, ces informations apparaissent directement dans les directives développeurs puisque les personnes, susceptibles d'être intéressées par les démarches menant à l'octroi d'un accès de commit, sont celles qui envisagent de contribuer au projet.

En plus de publier les procédures, publiez aussi la liste des committers. On la trouve habituellement dans un fichier appelé « MAINTAINERS » ou « COMMITTERS » au premier niveau de l'arborescence du code source du projet. Elle devrait lister tous les committers non-restreints en premier, suivis par les différents domaines de commit restreints avec leurs membres respectifs. Tous les noms et adresses e-mail devraient y figurer, les adresses pouvant être masquées pour éviter le spam (voir la section nommée « Masquer les adresses dans les archives » dans le Chapitre 3, Infrastructure technique) si la personne le désire.

Puisque la distinction, entre les committers non-restreints et restreints, est bien marquée et définie, il est normal que la liste fasse cette distinction aussi. Mais les distinctions faites par la liste ne devraient pas aller au delà. Des positions informelles s'établiront inévitablement au sein du projet, elles n'ont pas leur place ici. C'est une liste publique, pas un fichier de remerciements. Listez les committers soit par ordre alphabétique, soit par ordre d'arrivée.

Remerciements

Les remerciements sont la monnaie dans le monde des logiciels libres. Les participants peuvent invoquer toutes sortes de motivations, je ne connais personne qui serait heureux de faire tout ce travail anonymement ou sous une autre identité. C'est tout à fait compréhensible : c'est votre réputation dans un projet qui détermine plus ou moins votre influence. De plus, vous pouvez très bien valoriser votre participation à un projet Open Source puisque que désormais certains employeurs recherchent cette référence sur un CV. Et les raisons les plus évidentes ne sont pas nécessairement les plus fortes : les gens veulent simplement qu'on les apprécie et recherchent instinctivement des signes montrant que leur travail est reconnu par d'autres. La promesse de remerciements est une motivation forte. Lorsque des contributions minimes sont reconnues, cela incite les gens a en faire plus.

Le projet conserve toujours une trace de chaque contribution, c'est d'ailleurs l'une des caractéristiques du développement collaboratif (voir Chapitre 3, Infrastructure technique). Dès que possible, utilisez les moyens existants pour exprimer votre gratitude de manière précise, et soyez explicite quant à la nature de la contribution. N'écrivez pas simplement « Merci à A. Nonyme <anonyme@exemple.com> » si vous pouvez écrire à la place « Merci à A. Nonyme <anonyme@exemple.com> pour le rapport de bogue et les pistes de résolution » dans un message de journal.

Dans le projet Subversion, nous avons une règle informelle, mais cohérente, pour remercier les personnes qui rapportent un bogue, soit dans le formulaire du problème, s'il y en a un, soit dans le message de journal du commit qui règle le bogue. Un rapide tour d'horizon des journaux des commits de Subversion jusqu'au commit 14525 montre que dans 10% des commits figurent des remerciements nominatifs où apparaissent l'adresse e-mail. Ces remerciements sont en général destinés aux personnes ayant rapporté ou analysé les bogues corrigés par ce commit. Remarquez que cette personne n'est pas le développeur qui a vraiment fait la validation, dont le nom est déjà automatiquement enregistré par le logiciel de gestion de versions. Parmi les 80 et quelques committers (restreints ou non) que compte actuellement Subversion, 55 d'entre eux avaient déjà été remercié (en général plus d'une fois) dans le journal de validation avant de devenir committers eux-mêmes. Cela ne prouve évidemment pas qu'être remercié est un facteur de leur implication continue, mais au moins cela établit une atmosphère dans laquelle les gens savent que leur contribution sera remarquée.

Ne mélangez pas remerciements de routine et remerciements exceptionnels. Quand vous débattrez d'un morceau de code particulier, ou d'une autre contribution apportée, vous pouvez reconnaître leur travail. Par exemple, dire « Les dernières modifications de Daniel au code delta nous permettent maintenant d'ajouter la fonctionnalité X » aide les gens à savoir de quels changements vous parlez et, en même temps, montre votre appréciation pour le travail de Daniel. D'un autre côté, simplement dire « Merci à Daniel pour ses modifications au code delta » n'apporte rien. Aucune information nouvelle n'est transmise puisque le logiciel de gestion de versions et d'autres mécanismes ont déjà enregistré le fait qu'il a apporté des modifications. Éparpillez vos remerciements et ils perdent leur valeur (vous perdez aussi votre temps). Leur portée dépend de leur caractère exceptionnel par rapport aux commentaires positifs habituels affluant en permanence. Cela ne veut évidemment pas dire que vous ne devriez pas remercier les gens. Assurez vous simplement de le faire, tout en ne donnant pas dans la surenchère. Ces quelques conseils devraient vous aider :

• Vous êtes libre d'exprimer toute votre gratitude dans une discussion éphémère. Par exemple, remercier en passant, durant une conversation IRC, quelqu'un pour avoir corrigé un bogue ne pose pas de problème, idem pour une remarque dans un e-mail dédié principalement à d'autres sujets. Mais n'envoyez pas un e-mail juste pour remercier à moins qu'un fait vraiment exceptionnel n'ait été accompli. De la même manière, ne surchargez pas les pages Web du projet avec des remerciements. Une fois mis le doigt dans l'engrenage, vous ne saurez jamais où et comment vous en sortir. Ne mettez pas de remerciements dans les commentaires du code, il ne faut pas s'éloigner du but premier des commentaires qui est d'aider le lecteur à comprendre le code.

• Il est important de remercier les personnes les moins impliquées pour ce qu'elles ont fait. Même si cela peut sembler illogique, ça cadre avec l'idée que vous devez exprimer votre gratitude aux personnes qui dépassent vos attentes. Par conséquent, si vous remerciez trop les contributeurs réguliers pour un travail normalement attendu, vous montrez implicitement que vous attendez moins de leur part qu'ils ne le pensaient. C'est plutôt l'effet contraire que vous recherchez !

Il existe certaines exceptions à cette règle. Il est normal de remercier quelqu'un ayant fait ce qui était attendu de sa part si cela implique de consentir à des efforts sporadiques intenses sur des périodes données. L'exemple typique est le responsable sorties qui s'arme lourdement quand la sortie approche mais qui le reste du temps se met en hibernation (en hibernation en tant que responsable sorties, il peut très bien être actif en tant que développeur, mais c'est une autre chose).

• Comme pour les critiques et les remerciements, la gratitude devrait être précise. Ne remerciez pas les gens simplement parce qu'ils sont fantastiques, même s'ils le sont. Remerciez les pour avoir fait quelque chose sortant de l'ordinaire, pour les bons points, précisez en quoi leur réalisation était extraordinaire.

Le projet devra trouver un équilibre entre l'obligation de vérifier que toutes les contributions individuelles soient reconnues et le besoin de préserver le projet est tant qu'effort collectif, et non pas un ensemble de faits individuels mis bout à bout. Gardez ceci à l'esprit, et essayez de faire pencher la balance en faveur du groupe, ainsi vous pourrez garder le contrôle.

Les fourches

Dans la section « Fourchabilité » du Chapitre 4, Infrastructure sociale et politique, nous avons vu en quoi la possibilité de fourcher influe sur la gestion du projet. Mais que se passe-t-il quand une fourche se concrétise réellement ? Comment devriez-vous gérer la situation et à quoi devriez-vous vous attendre ? Inversement, quand devriez vous concrétiser une fourche ?

Là encore, tout dépend de la situation. Si certaines fourches sont dues à des différences de point de vue amicales mais irréconciliables sur la gestion du projet, bien plus nombreuses sont celles motivées par des désaccords techniques et des relations difficiles. Mais la distinction entre ces deux extrêmes n'est pas si simple, puisque les débats techniques ne sont pas dénués de sentiments personnels. À l'origine de toute fourche, par contre, on retrouve un groupe de développeurs, voire un développeur isolé, pour qui la collaboration avec certains devient plus problématique que constructive.

Dès qu'un projet fourche il est difficile de distinguer la « vraie » fourche du projet « original ». Les gens parleront de la fourche F issue du projet P, avec P poursuivant à l'identique le long d'un chemin naturel, alors que F s'aventure sur un nouveau territoire, mais ce constat simpliste est déjà teinté de subjectivité. C'est principalement un problème de perception : la majorité est source de vérité, si les gens pensent « blanc », c'est que c'est blanc. Ici, il n'y a pas de vérité objective à l'origine, pas de vérité qui saute aux yeux. Ce sont plutôt les perceptions qui forment cette vérité objective puisque, au final, le projet ou la fourche est une entité qui n'existe que dans l'esprit des gens de toute façon.

Si ceux à l'origine de la fourche pensent qu'ils font germer une nouvelle branche sur le projet principal, la question de la perception est résolue immédiatement et facilement. Tout le monde, développeurs et utilisateurs, verra la fourche comme un nouveau projet, avec un nouveau nom (peut-être basé sur l'ancien, mais facilement reconnaissable), un site Web distinct et une philosophie ou un but distinct. Cependant, les choses se compliquent quand les deux camps considèrent qu'ils sont les légataires de l'esprit original du projet, et qu'ils ont donc le droit de le poursuivre sous son nom d'origine. Si un organisme possède les droits sur le nom ou le contrôle légal du domaine ou des pages Web, la question est en général résolue légalement : en cas de litige, c'est cet organisme qui décidera de la légitimité de chaque groupe puisqu'il a toutes les cartes en main dans la guerre des relations publiques. Évidemment, les choses vont rarement aussi loin : les rapports de force sont connus, personne ne se lancera dans une bataille dont l'issue est connue d'avance et le bon sens s'applique.

Une fourche est, par nature, un vote de confiance. Donc, heureusement, dans la plupart des cas, il y a peu de doute quant à la position de chaque groupe, projet ou fourche. Si plus de la moitié des développeurs sont pour le chemin tracé par la fourche, il n'y a, généralement, pas besoin de fourche, le projet peut simplement emprunter ce chemin à moins qu'il ne soit dirigé par un dictateur particulièrement borné. À l'opposé, si moins de la moitié des développeurs y sont favorables, la fourche est clairement la rébellion d'une minorité, et la courtoisie et le bon sens veulent qu'ils se considèrent alors comme la branche divergente plutôt que comme la ligne principale.

Gérer une fourche

Quelqu'un menace de fourcher votre projet ? Gardez votre calme et souvenez vous de vos objectifs à long terme. L'existence d'une fourche n'est pas une menace en soi : la perte de développeurs et d'utilisateurs, voilà le vrai risque. Votre objectif alors n'est pas de bâillonner la fourche, mais d'en minimiser les effets néfastes. Vous pourrez être énervé, vous pourrez penser que la fourche n'est pas justifiée et qu'elle n'a aucune légitimité, mais exprimer cela en public ne peut que vous aliéner les développeurs indécis. Vous ne devriez pas forcer les développeurs à faire un choix entre les deux projets, et vous devriez être aussi coopératif que possible avec la fourche. En premier lieu, ne retirez pas à quelqu'un son accès de commit dans votre projet simplement parce qu'il a décidé de travailler sur la fourche. Ce n'est pas parce qu'il a commencé à travailler sur la fourche qu'il a soudainement perdu ses capacités à travailler sur le projet original, ceux qui étaient committers devraient le rester. Au delà de ça, vous devriez exprimer votre souhait de voir la compatibilité maintenue entre la fourche et le projet, et dire que vous espérez que les développeurs feront des portages entre les deux chaque fois qu'ils le pourront. Si vous avez un accès direct au serveur hébergeant le projet, offrez publiquement à la fourche une aide matérielle pour ses débuts. Par exemple, proposez leur un historique complet et détaillé du dépôt de gestion de version, s'ils n'ont pas d'autre moyen de l'obtenir, afin qu'ils n'aient pas à débuter sans historique (cela n'est pas forcément nécessaire, ça dépend du logiciel de gestion de version). Demandez leur s'ils ont besoin d'autre chose et fournissez le si possible. Inclinez vous, avec réserve, pour montrer que vous ne serez pas un obstacle, que vous voulez donner sa chance à la fourche et que son succès ne dépendra que de ses qualités.

Si vous devez faire tout cela, et le faire publiquement, ce n'est pas pour aider la fourche en fait, mais pour montrer aux développeurs que rester de votre côté est le pari le plus sûr en vous montrant aussi peu vindicatif que possible. En temps de guerre, il est parfois logique (stratégiquement parlant si ce n'est pas humainement) de forcer les gens à choisir leur camp, mais pour les logiciels libres, ce n'est presque jamais le cas. En fait, quand une fourche apparaît, certains développeurs ne se cachent pas pour travailler sur les deux projets et font de leur mieux pour entretenir leur compatibilité. Grâce à eux, les lignes de communications restent ouvertes après la séparation. Ils permettent à votre projet de bénéficier des nouvelles fonctionnalités intéressantes de la fourche (oui, la fourche peut proposer des choses attrayantes) et ils augmentent aussi la probabilité d'une fusion ultérieure.

Parfois une fourche gagne un tel succès que, même si elle était considérée comme une fourche au départ par ses instigateurs, elle devient la version préfèrée de tout le monde, et finalement supplante la version originale à la demande des utilisateurs. La fourche GCC/EGCS en est un exemple connu. Le GNU Compiler Collection (GCC, anciennement GNU C Compiler) est le compilateur de code exécutable Open Source le plus populaire et aussi l'un des compilateurs les plus portables au monde. En raison de désaccords entre les développeurs officiels de GCC et Cygnus Software, [29] l'un des groupes de développement de GCC le plus actif, Cygnus créa une fourche de GCC appelée EGCS. Ils avaient décidé de ne pas entrer en compétition : les développeurs d'EGCS n'ont à aucun moment essayé de faire passer leur version de GCC comme étant la nouvelle version officielle. Ils se sont plutôt concentrés sur l'amélioration de EGCS en ajoutant des correctifs plus rapidement que ne le faisaient les développeurs officiels de GCC. EGCS a gagné en popularité et finalement certains parmi les principaux distributeurs de systèmes d'exploitation ont décidé d'adopter EGCS comme compilateur par défaut à la place de GCC. Il était alors clair pour les développeurs de GCC que s'accrocher au nom « GCC », alors que tout le monde adoptait la fourche EGCS, n'empêcherait pas la migration et que la situation serait inutilement compliquée. Alors, GCC a adopté le code de base de EGCS : il n'y avait alors de nouveau plus qu'un seul GCC, mais largement amélioré grâce à la fourche.

Cet exemple montre que vous ne pouvez pas toujours voir une fourche comme une sorte d'adultère. Même si une fourche peut être douloureuse et indésirable, vous ne pouvez pas forcément prédire si elle réussira ou pas. Vous, et le reste du projet, devriez donc la surveiller et vous préparez, non seulement à en absorber des fonctionnalités et du code quand c'est possible, mais dans les cas les plus extrêmes, à la rejoindre si elle gagne le cœur du gros du projet. Bien sûr, vous pourrez souvent prédire les chances de succès d'une fourche d'après les personnes qui s'y joignent. Si la fourche est initiée par les pires empoisonneurs et ralliée par un groupe de développeurs mécontents qui n'apportait, de toute façon, rien de constructif , c'est plutôt une faveur faite que de prendre un autre chemin et vous n'avez pas à vous soucier de l'importance prise par la fourche vis à vis du projet originel. Par contre, si vous voyez des développeurs influents et respectés soutenir la fourche, vous devriez vous demander pourquoi. Peut-être que le projet devenait trop restrictif, la meilleure solution est alors que le projet principal fasse siennes toutes ou parties des actions envisagées par la fourche, c'est-à-dire, éviter qu'elle ne se concrétise.

Amorcer une fourche

Tous les conseils donnés ici supposent que la fourche n'intervienne qu'en dernier recours. Épuisez toutes les autres solutions avant de commencer une fourche. Amorcer une fourche est presque toujours synonyme de perte de développeurs, avec seulement la promesse vague d'en gagner de nouveaux plus tard. C'est aussi le début d'une nouvelle compétition : tous ceux qui s'apprêtent à télécharger le logiciel vont se demander : « Lequel devrais-je prendre, celui-là ou cet autre là ? » Que vous soyez le premier ou le deuxième, la situation est épineuse car une nouvelle question a été introduite. À en croire la théorie de l'évolution, les fourches sont bénéfiques pour l'écosystème du logiciel entier : le mieux adapté survivra, ce qui signifie que, au final, tout le monde profite d'un meilleur logiciel. Cela peut être vrai du point de vue de l'écosystème, mais ce n'est pas vrai du point de vue d'un projet prit individuellement. La plupart des fourches ne réussissent pas et la majorité des projets ne sont pas enchantés d'être divisés.

Pour cette même raison, vous ne devriez pas utiliser l'argument de la fourche comme un argument extrémiste, « Faites ce que je veux ou je commencerai une fourche ! », parce que tout le monde sait que les fourches, n'arrivant pas à attirer de développeurs du projet originel, n'ont qu'une faible chance de survie. Tous les observateurs, pas seulement les développeurs, mais aussi les utilisateurs et ceux qui font les dépôts pour les systèmes d'exploitation, choisiront leur camp selon leurs propres critères. Vous devriez donc vous montrer réticent à l'idée de commencer une fourche, ainsi, si vous devez finalement vous y résoudre, vous pourrez affirmer avec crédibilité que c'était la dernière alternative.

Ne négligez aucun facteur lorsque vous évaluez les chances de succès de votre fourche. Par exemple, si beaucoup de développeurs sur un projet ont un employeur identique, même mécontents et secrètement favorables à une fourche, il y a peu de chance qu'ils l'annoncent ouvertement si leur employeur y est opposé. De nombreux programmeurs de logiciels libres aiment à penser que le fait d'appliquer une licence libre au code signifie qu'aucune entreprise ne peut en dominer le développement. C'est vrai que la licence est au final une garantie de liberté, si certains veulent vraiment initier une branche, et ont les moyens de le faire, ils le peuvent. Mais en pratique, les équipes de développement de certains projets sont principalement financées par une entité, et vous ne pouvez pas ignorer purement et simplement ce soutien. Si cette entité est opposée à la fourche, il y a peu de chance que ses développeurs y prennent partie, même s'ils le désirent secrètement.

Si, pour autant, vous êtes toujours certains de la nécessité d'une fourche, assurez-vous, en premier, de vos soutiens en privé, annoncez ensuite la naissance de la fourche de manière amicale. Même si vous êtes en colère ou déçu par les responsables en place, ne le dites pas dans le message. Exposez sans emportement les raisons qui vous ont poussé à prendre cette décision, et annoncez que cette manœuvre ne vise pas à nuire au projet. En supposant que vous la considérez bien comme une fourche (en opposition à une manœuvre d'urgence de préservation du projet originel), soulignez bien que vous utiliserez le code, mais pas le nom du projet et que vous choisissez un nom qui ne prêtera pas à confusion. Vous pouvez utiliser un nom qui contient ou fait référence au nom original tant qu'aucune confusion n'est possible. Évidemment, vous pouvez mettre en avant sur le page Web de la fourche le lien de parenté avec le projet initial, et même que vous espérez le supplanter. Essayez simplement de ne pas compliquer la vie des utilisateurs en les mêlant à une bataille identitaire.

Pour finir, vous pouvez commencer du bon pied en octroyant automatiquement l'accès de commit pour la fourche à tous ceux qui l'avaient déjà sur le projet originel, même à ceux qui montraient ouvertement leur désaccord sur la nécessité d'une fourche. Même s'ils n'utilisent jamais leur accès, votre message est clair : il y a des désaccords, mais pas d'ennemis, et les contributions de tous ceux qui en ont les compétences sont les bienvenues.

Notes

[24] Cette question a été traitée en détail dans un papier signé par Karim Lakhani et Robert G. Wolf, intitulé « Why Hackers Do What They Do: Understanding Motivation and Effort in Free/Open Source Software Projects » [NdT : « Pourquoi les hackers font ce qu'ils font : comprendre les motivations et les efforts dans les projets de logiciels libres/Open Source »]. Les résultats sont intéressants. Disponible à l'adresse : http://freesoftware.mit.edu/papers

[25]Je vous invite à jeter un œil à la discussion « having authors names in .py files » [NdT : conservez les noms des auteurs dans les fichiers .py] à l'adresse http://groups.google.com/group/sage-devel/browse_thread/thread/e207ce2206f0beee, vous y trouverez de bons contre-arguments, en particulier dans l'intervention de William Stein. Ce qui fait la différence ici, je crois, est que parmi les auteurs, nombreux sont issus d'un monde (le monde des mathématiques académiques) où la norme veut que l'on cite les auteurs directement à la source et qu'ils y attachent beaucoup d'importance. En de telles circonstances, il vaut peut-être mieux ajouter les noms des auteurs dans les fichiers sources, avec une description précise des contributions de chacun puisque pour la majorité des participants ce genre de reconnaissance est attendue.

[26] Remarquez que ce n'est pas la peine de convertir tous les tests existants pour le nouveau cadre de tests, les deux peuvent très bien cohabiter et vous pouvez convertir les anciens tests uniquement quand le besoin s'en fait sentir.

[27] IssueZilla est le suivi de bogues que nous utilisons, c'est un descendant de BugZilla.

[28] Attention, l'accès de commit a une signification légèrement différente dans un système de gestion de versions décentralisé où chacun peut mettre en place un dépôt lié au projet, et s'accorder personnellement l'accès de commit à ce dépôt. Néanmoins, le concept d'accès de commit ne perd pas tout son sens : « accès de commit » devient synonyme d'« autorisation à apporter des modifications au code qui seront incluses dans la prochaine version du logiciel ». Si pour les systèmes de gestion de versions centralisés, c'est un accès à la validation, dans les systèmes décentralisés, cela signifie voir ses modifications intégrées d'office à la distribution principale. Dans les deux cas, l'idée est la même ; la mise en œuvre de l'idée n'est pas si importante.

[29] Maintenant partie intégrante de RedHat (http://www.redhat.com).

---

Chapitre 7 : Paquets, sorties et développement quotidien

Page d'accueil du projet

Chapitre 9 : Licence, droits d'auteur et brevets