POSSFR Chap 4
De Framalang Wiki.
| Chapitre 3 : Infrastructure technique | | Chapitre 5 : L'argent |
Sommaire |
Chapitre 4 : Infrastructure sociale et politique
Certaines interrogations concernant les logiciels libres sont récurrentes : « Comment ça marche ? Qu'est-ce qui fait avancer un projet ? Qui prend les décisions ? ». Les réponses invoquant la méritocratie ne me satisfont jamais, pas plus que l'esprit de coopération, le code qui parle pour lui-même, etc. Le fait est que la réponse à ces questions n'est pas simple. La méritocratie, la coopération et le code qui marche en font partie, mais n'expliquent pas vraiment comment un projet fonctionne au quotidien et encore moins comment les conflits sont résolus.
Ce chapitre tente de mettre en avant les fondements structurels que les projets réussis ont en commun. J'emploie « réussis » non seulement pour parler de qualité technique, mais aussi de santé opérationnelle et de capacité de survie. Un projet en bonne santé est un projet qui sait incorporer de nouvelles contributions au code et de nouveaux développeurs sans arrêt et qui sait être réactif face aux rapports de bogue. Quant à la capacité de survie, c'est l'aptitude du projet à exister indépendamment de tout participant individuel ou sponsor, ce que l'on peut traduire par la probabilité que le projet se poursuive même si tous les membres fondateurs passent à autre chose. La réussite technique n'est pas difficile à atteindre mais, sans une équipe de développeurs et des fondations sociales solides, un projet peut se montrer incapable de faire face à la croissance que génèrent des débuts réussis ou aux départs d'individus charismatiques.
Les façons d'atteindre cette réussite sont diverses. Certaines impliquent une structure de gouvernance formelle qui permet de résoudre les débats, d'intégrer (et parfois d'exclure) de nouveaux développeurs, de planifier de nouvelles fonctionnalités, etc. D'autres impliquent une structure moins formelle, mais plus d'auto-modération volontaire, le mode de gouvernance repose alors sur le respect de règles fiables. Ces deux modes de gestion mènent au même résultat : un sens de la persistance institutionnelle, étayé par des habitudes et des procédures bien comprises de tous ceux qui participent au projet. Ces caractéristiques sont même plus importantes encore dans des systèmes auto-organisés que dans ceux où le contrôle est centralisé, car dans les systèmes auto-organisés chacun est conscient du fait que quelques pommes pourries peuvent gâter tout le panier, du moins pendant un certain temps.
Fourchabilité
L'ingrédient indispensable qui maintient les développeurs unis autour d'un projet de logiciel libre et les amène à faire des compromis si nécessaire est la « fourchabilité » du code, c'est à dire la possibilité offerte à chacun de prendre une copie du code source et de l'utiliser pour démarrer un projet concurrent, connu sous le nom de « fork » ou « fourche » en français. Paradoxalement la possibilité de créer une fourche est généralement un levier beaucoup plus puissant dans les projets de logiciel libre que les vraies fourches, qui restent très rares. Parce qu'une fourche n'est bonne pour personne (pour des raisons exposées plus en détail dans la section « Fourches » du Chapitre 8, Encadrer les volontaires), plus la menace de bifurcation devient sérieuse, plus on est prêt à faire de compromis pour l'éviter.
Les fourches, ou plutôt le potentiel de démarrer une fourche, sont la raison pour laquelle il n'y a pas de vrai dictateur dans les projets de logiciels libres. Cette déclaration peut paraître surprenante, étant donné qu'il est très courant d'entendre parler d'un « dictateur » ou d'un « tyran » au sein d'un projet Open Source. Mais il s'agit d'une sorte de tyrannie particulière, très loin de la définition classique de ce terme. Imaginez un roi dont les sujets pourraient à tout moment copier le royaume entier et emménager dans la copie du royaume pour le gouverner comme bon leur semble. Il est quasi certain que le règne d'un tel roi serait fort différent de celui dont les sujets sont contraints de rester sous sa loi quoi qu'il fasse.
C'est pourquoi même les projets qui ne sont pas formellement organisés comme des démocraties s'en remettent dans la pratique à un processus démocratique quand il s'agit de prendre une décision importante. Pouvoir répliquer le code implique pouvoir créer un fourche et la possibilité de créer un fourche implique le consensus. Il se peut très bien que tout le monde accepte de s'en remettre à un leader (l'exemple le plus célèbre étant Linus Torvalds et le développement du noyau Linux), mais parce qu'ils ont choisi de le faire de manière totalement dénuée de cynisme et de malignité. Le dictateur n'a pas d'emprise magique sur le projet. Une des caractéristiques essentielles des licences Open Source est qu'elles mettent tout le monde sur un pied d'égalité devant les décisions concernant la modification ou l'utilisation du code. Si le dictateur se mettait soudain à prendre de mauvaises décisions, s'élèverait alors un mécontentement suivi éventuellement d'une révolte et d'une fourche. Si ce n'est, bien sûr, que les choses vont rarement si loin, car le dictateur cède le premier.
La possibilité de fourche borne le pouvoir que chacun peut exercer au sein du projet, mais cela ne veut pas dire qu'il existe une unique façon de gouverner les projets. Il ne s'agit pas de brandir la menace de fourche à chaque décision, cette menace ne doit être utilisée qu'en dernier recours. Cela deviendrait vite fatigant et détournerait l'énergie du travail à réaliser. Les deux parties suivantes passent en revue différentes manières d'organiser les projets de sorte que la plupart des décisions passent en douceur. Les deux exemples cités sont des extrêmes un peu idéalisés ; la plupart des projets se situent quelque part entre les deux.
Les dictateurs bienveillants
Le dictateur bienveillant est exactement ce que laisse entendre son nom : le pouvoir de prise de décision ultime est mis entre les mains d'une personne dont on attend, en vertu de sa personnalité et de son expérience, qu'elle en use sagement.
Bien que « dictateur bienveillant » (DB) soit le terme courant pour ce rôle, ce serait mieux de l'imaginer comme un « arbitre approuvé par la communauté » ou un « juge ». Généralement, les dictateurs bienveillants ne prennent pas concrètement toutes les décisions, ni même la majorité des décisions. Il est peu probable qu'une seule personne puisse avoir les compétences requises pour prendre des décisions justes dans tous les domaines d'un projet et, de toute façon, les bons développeurs ne s'éterniseront pas s'ils n'ont pas quelque influence sur la direction du projet. C'est pourquoi les dictateurs bienveillants ne dictent généralement pas grand chose. En revanche, ils laissent les choses s'éclaircir d'elles-mêmes au cours de la discussion et de l'expérimentation, quand c'est possible. Ils y participent eux-mêmes, mais en tant que simples développeurs, s'en remettant souvent à un responsable du domaine ayant plus de savoir-faire. C'est seulement quand il apparaît clairement qu'un consensus ne peut être trouvé et que la majorité du groupe veut que quelqu'un oriente la décision afin que le développement puisse continuer, qu'il tape du poing sur la table en disant : « Voilà ce qu'il faut faire. ». Presque tous les dictateurs bienveillants ont en commun une aversion pour la prise de décisions par dictat ; c'est une des raisons pour lesquelles ils parviennent à garder leur rôle.
Qui peut être un bon dictateur bienveillant ?
Être un bon DB requiert une diversité de traits de caractère. Il faut, tout d'abord, une perception bien affûtée de sa propre influence sur le projet, ce qui implique que le DB doit faire preuve de modération. Dans les premières phases de discussion, si le DB assène ses opinions et ses conclusions avec force, les autres trouveront inutile de penser différemment. Les gens doivent se sentir à l'aise pour exposer leurs idées, y compris les stupides. Inévitablement, le DB, lui-aussi, postera à l'occasion une idée absurde, c'est pourquoi ce rôle demande aussi de savoir comprendre et reconnaître ses erreurs lors d'une mauvaise décision. C'est là un trait de caractère que tout bon développeur devrait posséder, notamment s'il reste longtemps dans le projet. La différence est que le DB peut se permettre des erreurs de temps en temps, sans craindre de conséquences sur sa crédibilité à long-terme. Les développeurs de moindre ancienneté ne se sentiront pas aussi protégés, et le DB devra formuler ses critiques et décisions contraires avec courtoisie vue la portée de ses mots, aussi bien sur le plan technique que psychologique.
Le DB n'a nullement besoin de posséder les meilleures compétences techniques au sein du projet. Il doit en avoir suffisamment pour travailler sur le code, pour comprendre et discuter tout changement : c'est tout. La position de DB n'est ni obtenue ni détenue en vertu d'un talent de codeur hors du commun. Ce qui compte, c'est l'expérience et la vision globale, pas forcément la capacité à concevoir de bonnes choses à la demande, mais plutôt l'aptitude à reconnaître une bonne conception, quelle qu'en soit la source.
Le dictateur bienveillant est généralement un des fondateurs du projet, mais il s'agit plus d'une corrélation que d'une cause. L'ensemble des qualités permettant à une personne de démarrer un projet avec succès (compétences techniques, capacité à persuader d'autres gens de s'y associer, etc.), est exactement identique aux aptitudes nécessaires au DB. Bien évidemment, les fondateurs débutent avec une sorte d'ancienneté automatique, souvent suffisante pour faire apparaître le dictateur bienveillant comme une voie de moindre résistance s'offrant à tous.
Souvenez-vous que la potentialité de fourche est à double tranchant. Un DB peut scinder un projet aussi facilement que quiconque, et certains le firent à l'occasion, quand ils sentirent que la direction voulue pour le projet était différente de celle souhaitée par la plupart des développeurs. Du fait d'une possibilité de fourche, peu importe que le dictateur bienveillant ait, ou pas, les privilèges d'administrateur sur le serveur principal du projet. Les gens parlent parfois du contrôle du serveur comme d'une source ultime de pouvoir dans un projet, mais en fait c'est sans importance. La capacité, d'ajouter ou d'enlever, sur un serveur particulier, les mots de passe de validation (commit) des uns et des autres, n'affecte que la copie du projet hébergée sur ce serveur. En cas d'abus prolongé de ce pouvoir, de la part du DB ou d'un d'autre, il suffit de migrer le développement sur un autre serveur.
Quant à savoir, si votre projet devrait avoir un dictateur bienveillant, ou, s'il fonctionnerait mieux avec un système moins centralisé, cela dépend en grande partie du candidat disponible pour assumer ce rôle. En règle générale, s'il est évident, pour tout le monde, qu'untel devrait être le DB, le problème est résolu. Par contre, si aucun candidat ne se démarque nettement, le projet devrait plutôt recourir à un mode de prise de décision décentralisé.
Démocratie basée sur le consensus
En vieillissant, les projets tendent à s'éloigner du modèle du dictateur bienveillant au profit de systèmes plus ouvertement démocratiques. Ce n'est pas forcément par mécontentement à l'égard d'un DB en particulier. C'est simplement, parce que la gouvernance basée sur le groupe est, en empruntant une métaphore à la biologie, plus « évolutionnairement stable » . Chaque recul, ou essai d'une répartition plus équilibrée de la responsabilité de décision, de la part du dictateur bienveillant, est une occasion pour le groupe d'établir un nouveau système non-dictatorial, de fonder une constitution en quelque sorte. Le groupe peut ne pas saisir cette opportunité la première fois, ni la deuxième, mais il finira par la prendre, et, une fois le fait établi, la possibilité d'un retour en arrière est invraisemblable. La raison tient du bon sens : si un groupe de N personnes devait investir un membre de pouvoirs spéciaux, ceci voudrait dire que N-1 personnes ont accepté de diminuer leur influence personnelle, ce qui est peu probable. Dans les faits, la dictature résultante n'est que conditionnelle : le DB sacré par le groupe peut, aussi bien, être détrôné par celui-ci. Ainsi, une fois qu'un projet a évolué d'une direction autocratique vers un système officiel basé sur le groupe, il revient rarement en arrière.
Le fonctionnement de ces systèmes connaît de nombreuses variantes, mais il existe 2 éléments communs : 1) le groupe travaille par consensus la plupart du temps ; 2) il existe un mécanisme officiel de vote sur lequel se reposer quand le consensus n'est pas atteint.
« Consensus » veut simplement dire : accord prêt à être respecté par chacun. Il ne s'agit pas d'un état ambigu : le consensus est atteint, pour une question donnée, lorsque l'on déclare le consensus atteint et que cette affirmation n'est pas contredite. La personne proposant le consensus devrait, bien sûr, déclarer ses spécifications, et quelles actions en découlent, si cela n'est pas évident.
La plupart des conversations, dans un projet, portent sur des questions techniques, telles que : la meilleure façon de corriger un bogue, l'ajout ou non d'une fonctionnalité, le degré de précision dans la documentation des interfaces, etc. La gouvernance basée sur le consensus fonctionne bien, car elle s'harmonise parfaitement à la discussion technique proprement dite. En fin de discussion, tout le monde s'accorde souvent sur la voie à prendre. Habituellement, une conclusion est postée faisant office conjointement de résumé des décisions et de proposition implicite de consensus. Ce qui offre une dernière chance à chacun de dire : « Attendez, je n'ai pas donné mon accord là-dessus. Il faut encore décortiquer la question. »
Pour les décisions mineures ne faisant pas controverse, la proposition de consensus est implicite. Par exemple, quand un développeur valide spontanément une correction de bogue, la validation elle-même (« commit ») contient une proposition de consensus : « Je suppose tout le monde d'accord, ce bogue doit être corrigé, et c'est la bonne façon de le faire. ». Bien sûr, le développeur ne le dit pas réellement ainsi, il ne fait que valider la correction, et les autres membres du projet ne se donnent pas la peine de manifester leur accord, car « qui ne dit mot consent ». Si une modification validée n'est, finalement, pas approuvée par tous, le projet engage alors simplement une discussion, comme si elle n'avait pas encore été validée. Le bienfondé de cette méthode est l'objet de la prochaine partie.
La gestion de versions, gage de sérénité
Du fait de la mise du code source du projet sous gestion de versions, on peut revenir sur la plupart des décisions. Le cas le plus courant est lorsque que l'on valide un changement en pensant erronément rendre tout le monde heureux, alors que l'acte ne rencontre que des objections. Il est d'usage, après de telles objections, de commencer obligatoirement par présenter ses excuses pour avoir manqué les discussions antérieures, quoique cette étape puisse être omise si l'objecteur ne trouve pas trace d'une telle discussion dans les archives de la liste. D'une manière ou d'une autre, il n'y a aucune raison que le ton de la discussion soit différent avant et après la validation du changement. Tout changement est réversible, du moins jusqu'à l'implantation des modifications de dépendances liées aux changements (c'est-à-dire, du code ajouté par la suite qui casserait si le changement original était soudainement supprimé). Le logiciel de gestion de versions permet au projet de défaire les effets de jugements mauvais ou hâtifs. Il est donc possible de suivre librement son instinct, et d'évaluer le meilleur moment de l'ajout d'une modification en fonction des commentaires reçus.
Cela veut également dire que le processus pour parvenir au consensus n'a aucunement besoin d'être très formel. La plupart des projets le font au jugé. Les changements mineurs passent sans discussion, ou alors, minimale et ponctuée de quelques signes d'approbation. Concernant les changements plus importants, notamment ceux pouvant déstabiliser une bonne quantité de code, il faudrait attendre un jour ou deux avant de confirmer le consensus : la logique étant que personne ne devrait être tenu à l'écart d'une conversation importante, seulement pour ne pas avoir vérifié son courrier assez fréquemment.
Ainsi, une fois certain de savoir ce qu'il faut effectuer, on devrait simplement se lancer et le faire. Ceci s'applique non seulement aux corrections logicielles, mais également aux mises à jour du site Web, aux changements de la documentation, et, à tout ce qui a peu de chances de prêter à controverse. Généralement, les situations où il faut annuler une action sont rares, ainsi, elles pourront être traitées au cas par cas. Bien sûr, on ne devrait pas encourager les gens à l'obstination. Il subsiste toujours une différence psychologique entre une décision en discussion et une décision déjà effective, même si elle est techniquement réversible. Les gens, associant toujours l'élan à l'action, seront moins disposés à défaire un changement qu'à l'empêcher en premier lieu. Cependant, si un développeur abuse de ce fait en validant trop rapidement des changements potentiellement controversés, les gens sont en droit, et ont le devoir, de se plaindre et de lui imposer des règles plus strictes jusqu'à ce que la situation s'améliore.
Quand le consensus n'est pas possible, votez
Certains débats ne trouveront pas de consensus, c'est inévitable. Quand tous les autres moyens pour sortir d'une impasse échouent, la solution est le vote. Mais avant de procéder au vote, les choix possibles doivent être clairement définis. Ici, de nouveau, le processus normal de la discussion technique se marie étonnamment avec les procédures de prise de décision du projet. Le genre des questions amenant au vote touche souvent à des thématiques complexes, aux multiples facettes. Dans de telles discussions alambiquées, une ou deux personnes, généralement, jouent le rôle de médiateurs : elles postent régulièrement des comptes-rendus sur les différents arguments, et gardent trace des principaux points d'achoppement (et d'accord). Ces compte-rendus aident tout le monde à mesurer les progrès effectués et rappellent les questions en suspens. Ces mêmes compte-rendus peuvent servir de prototype au bulletin de vote, au cas où ce dernier deviendrait nécessaire. Si les médiateurs ont bien fait leur travail, ils seront en mesure d'appeler à voter le moment venu, et le groupe sera disposé favorablement à l'utilisation de la feuille de scrutin basée sur leurs compte-rendus. Les médiateurs eux-mêmes peuvent participer au débat et n'ont pas obligation de rester au-dessus de la mêlée ; tant qu'ils arrivent à comprendre et présenter équitablement les autres points de vue, sans que leur sentiment partisan ne les empêche de rendre compte de manière neutre de l'état de la discussion.
Le contenu du bulletin n'est, généralement, pas controversé. Quand l'affaire en vient au vote, quelques positions clés bien identifiées sont déjà isolées et résumées par des descriptions succinctes. Occasionnellement, un développeur fera une objection sur le vote lui-même. Parfois son inquiétude est légitime, par exemple, si une option importante a été omise ou insuffisamment renseignée. Mais d'autres fois, un développeur essaiera tout simplement d'éviter l'inévitable, en sachant peut-être que l'issue du vote n'ira pas dans son sens. Référez-vous à la section « Les personnes difficiles » dans le Chapitre 6, Communication pour savoir comment gérer ce genre d'obstructionnisme.
Pensez à préciser le système de vote, vu qu'il en existe plusieurs, et que l'on pourraient se méprendre sur la procédure en cours. Dans la plupart des cas, la bonne option est le vote par approbation où, chaque participant peut voter, comme il l'entend, selon ses choix sur le bulletin. Le vote par approbation est simple à expliquer et à compter, de plus, à la différence d'autres méthodes, c'est une élection à un seul tour. Voir http://fr.wikipedia.org/wiki/Système_de_vote pour plus de détails sur le vote par approbation et les autres systèmes d'élection, mais évitez d'entrer dans un long débat sur le choix (car, évidemment, vous vous trouverez lancé dans un débat sur le système de vote pour décider du système de vote lui-même !) Une des raisons qui font du vote par approbation un bon choix, est la difficulté d'y opposer des objections : c'est un système de vote presque aussi juste que possible.
Enfin, procédez au vote publiquement. Ni le secret, ni l'anonymat ne sont requis pour un vote portant sur des questions qui, de toute façon, ont été débattues en public. Faites en sorte que chaque participant poste son vote sur la liste de discussion du projet afin que n'importe quel observateur puisse compter et vérifier les résultats, et que tout soit consigné dans les archives.
Quand voter
Le plus difficile, en ce qui concerne le vote, est de déterminer quand il doit avoir lieu. En règle générale, le recours au vote devrait être exceptionnel : la dernière solution quand toutes les autres options ont échoué. Ne voyez pas le vote comme LE moyen génial de clore les débats, loin de là. Il met fin à la discussion, et met donc fin à la réflexion créative sur le problème concerné. Tant que la discussion continue, subsiste la possibilité qu'une personne présente une nouvelle solution satisfaisant tout le monde . Étonnamment, ceci arrive assez souvent, d'un débat animé peut naître une nouvelle façon d'aborder le problème, laquelle débouche sur une proposition qui, finalement, satisfait tout le monde. Même si aucune proposition nouvelle ne surgit, il reste encore préférable de négocier un compromis que de voter. Après un compromis, tout le monde est un peu mécontent, tandis qu'après un vote, certains sont malheureux et d'autres heureux. D'un point de vue politique, la première situation est préférable : au moins chacun peut avoir le sentiment d'avoir tiré un prix de son malheur. On est peut-être malheureux, mais les autres le sont aussi.
L'avantage principal du vote est qu'il permet de régler définitivement une question afin de pouvoir aller de l'avant. Mais il règle la question au nombre de voix, et non pas par un dialogue rationnel amenant tout le monde à la même conclusion. Il me semble que ceux ayant de l'expérience dans les projets Open Source sont moins enclins à régler les questions par le vote. Ils essaieront plutôt d'explorer des solutions n'ayant pas été examinées précédemment, ou feront des compromis plus durs que ceux initialement prévus.
Il existe plusieurs techniques pour éviter un vote prématuré. La plus évidente consiste simplement à dire : « Je pense que nous ne sommes pas encore prêts pour un vote », tout en exposant les raisons. Une autre consiste à demander un vote informel (non contraignant) à main levée. Si l'issue penche nettement en faveur d'une partie, certains seront alors plus enclins à négocier, évitant le recours à un vote formel. Mais le mieux reste encore d'offrir une nouvelle solution, ou un nouveau point de vue sur une proposition ancienne, ainsi les gens se réinvestiront dans les problèmes au lieu de simplement ressasser leurs arguments.
Dans certains cas rares, tout le monde s'accorde sur le fait que les solutions avec compromis sont pires que celles sans arrangement. Alors, le vote devient plus acceptable, pour deux raisons : c'est le meilleur moyen d'amener une solution de qualité et, les gens ne seront pas foncièrement malheureux, quelle qu'en soit l'issue. Malgré tout, le vote ne doit pas être précipité. La discussion conduisant au vote instruit l'électorat : interrompre trop tôt cette discussion, nuirait donc à la qualité du résultat.
(Notez que ce conseil de ne pas s'obstiner à voter, ne s'applique pas au vote touchant l'inclusion des modifications et décrit dans la section « Stabiliser une version » du Chapitre 7, Paquets, sorties et développement quotidien. Là, le vote est bien plus un mécanisme de communication, un moyen d'enregistrer l'implication de chacun dans le processus de révision des modifications, afin de pouvoir évaluer l'attention dont a fait l'objet une modification).
Qui vote ?
Un système de vote c'est bien, mais qui a le droit de vote ? C'est là une question potentiellement sensible, car elle oblige le projet à démarquer certaines personnes pour leur implication ou leur jugement.
La meilleure solution consiste à utiliser une distinction existante, comme l'accès à la validation (« accès de commit »), et à y attacher les privilèges du vote. Dans les projets proposant à la fois des accès de commit restreints et non-restreints, les committers restreints doivent-ils aussi avoir le droit de vote ? La réponse à cette question dépend largement du processus accordant l'accès de commit restreint. Si le projet les délivre généreusement, par exemple comme un moyen de mettre à jour de nombreux outils versés au dépôt par des tierces parties, alors il faudrait préciser que l'accès de commit restreint est juste un droit de validation, pas un droit de vote. Et inversement : puisque ceux qui ont un accès de commit non-restreint auront les privilèges du vote, il faut les choisir non seulement en tant que programmeurs, mais aussi en tant que membres de l'électorat. Si quelqu'un affiche sur les listes des diffusion des tendances turbulentes ou obstructionnistes, le groupe devrait peut-être réfléchir à deux fois avant de lui donner les droits de committer, même si ses compétences techniques ne font aucun doute.
Le système de vote lui-même devrait être utilisé pour choisir les nouveaux committers, qu'ils aient un accès de commit restreint ou complet. Mais il s'agit ici d'une des circonstances où le vote secret est approprié. Il est impossible de voter pour un committer potentiel sur la liste de discussion publique sans risquer de heurter les sentiments du candidat (et sa réputation). En revanche, l'usage veut qu'un committer poste, sur une liste privée composée uniquement des autres committers, la proposition d'accorder, à un tiers, l'accès à la validation. Les autres committers donnent ouvertement leur avis, sachant que la discussion est privée. Généralement, il n'y a aura pas de désaccord, donc pas besoin de vote. Après avoir attendu quelques jours afin d'être sûr que chacun ait eu l'occasion de réagir, l'émetteur original de la proposition écrit au candidat pour lui offrir l'accès à la validation. Si désaccord il y a, une discussion s'ensuit, comme pour tous les autres désaccords, débouchant, le cas échéant, sur un vote. Pour que ce processus soit franc et ouvert, le simple fait que la discussion ait lieu devrait rester secret. Si la personne en question savait ce qui se trame, et ne se voyait pas offrir l'accès de commit, elle en conclurait qu'elle n'a pas remporté le vote, et en serait vraisemblablement blessée. Bien sûr, si quelqu'un demande explicitement l'accès à la validation, il ne reste plus alors qu'à considérer la proposition, et l'accepter ou la rejeter explicitement. Dans ce dernier cas, il faudrait procéder aussi poliment que possible, avec une explication claire : « Nous avons apprécié tes correctifs, mais nous avons besoin d'en voir plus encore » ou « Nous avons apprécié tous tes correctifs, mais ils avaient besoin de beaucoup d'ajustements avant de pouvoir être appliqués, donc nous ne sommes pas prêt à te donner un accès à la validation pour le moment. Nous espérons que cela va changer avec le temps. » Souvenez-vous, ce que vous dites peut blesser, tout dépend du degré de confiance en soi de la personne. Essayez de voir les choses de son point de vue lorsque vous rédigez le courriel.
Ajouter un nouveau committer étant plus important que la plupart des autres décisions, certains projets ont des exigences particulières concernant le vote. Ils peuvent, par exemple, exiger que la proposition reçoive n votes positifs et aucun vote négatif, ou bien qu'une majorité la plébiscite. Les paramètres exacts importent peu : l'idée principale étant que le groupe doit être prudent au moment d'ajouter de nouveaux committers. De telles exigences, similaires voire plus strictes, peuvent être appliquées au vote visant à retirer ses privilèges à un committer : en espérant que cela ne soit jamais nécessaire. Reportez-vous à la section intitulée « Committers », dans le Chapitre 8, Encadrer les volontaires, pour plus d'informations sur les options autres que le vote pour l'attribution ou le retrait des droits de commit.
Vote ou sondage ?
Pour certains votes, il peut être utile d'élargir l'électorat. Par exemple, quand les développeurs ne parviennent pas à saisir si le choix d'une interface donnée correspond bien à l'usage réel du logiciel. Une solution peut être de demander à tous les abonnés de la liste de discussion du projet de voter. Il s'agit, en réalité, plus d'un sondage que d'un vote, et les développeurs peuvent ou non choisir de se soumettre au résultat. Comme pour tout sondage, faites en sorte que les participants comprennent parfaitement qu'il s'agit de questions ouvertes : si quelqu'un propose une meilleure option que celles proposées dans le sondage, sa réponse pourrait être le résultat le plus important du sondage.
Veto
Quelques projets autorisent aussi un type particulier de vote : le veto. Le veto permet au développeur d'immobiliser un changement hâtif ou inconsidéré, au moins suffisamment longtemps pour que l'on puisse encore en discuter. Le veto se situe à mi-chemin entre une très forte objection et une forme d'obstruction. Son sens exact varie d'un projet à l'autre. Certains projets rendent très difficile l'annulation d'un veto, d'autres la permettent au moyen d'un vote majoritaire, peut-être après un délai obligatoire afin de prolonger la discussion. Tout veto se doit d'être accompagné d'une explication approfondie : sans elle, il devrait être considéré comme nul et non avenu.
Avec le veto vient le problème de son abus. Parfois les développeurs sont trop pressés de faire monter les enchères en lançant un veto quand le temps est encore aux discussions. Vous pouvez éviter l'abus de veto en étant vous-même très réticent à y recourir, et en signalant gentiment quand quelqu'un d'autre utilise son droit de veto trop souvent. Si nécessaire, vous pouvez également rappeler au groupe que les vetos ne sont contraignants que dans la mesure où le groupe accepte qu'ils le soient. Après tout, si une nette majorité de développeurs veulent X, c'est X qui adviendra d'une façon ou d'une autre. Dans ce cas, soit le développeur opposant son veto cède, soit le groupe décide d'affaiblir la portée du veto.
Vous pourrez voir certains écrire « -1 » pour exprimer leur veto. Cet usage vient de l'Apache Software Foundation, dont le processus de vote et de veto est hautement structuré, voir la description à cette adresse : http://www.apache.org/foundation/voting.html. Les critères d'Apache se sont étendus à d'autres projets, vous pourrez ainsi voir ses conventions utilisées à divers degrés dans de nombreux endroits du monde de l'Open Source. Techniquement, « -1 » n'indique pas toujours un veto officiel, même d'après les critères d'Apache, par contre , ce « -1 » est assimilé, de manière informelle, à un veto ou à une très forte objection.
Comme le vote, le veto peut être rétroactif. On ne peut faire objection au veto en prétextant que le changement en question a déjà été validé par « commit », ou que l'action a déjà été lancée (à moins qu'il ne s'agisse d'un fait irréversible, comme la publication d'un communiqué de presse). D'un autre côté, un veto arrivant des semaines ou des mois plus tard a peu de chances, à juste titre, d'être pris très au sérieux.
Tout mettre par écrit
Arrivé à un certain point, le nombre de conventions et d'accords tacites entourant votre projet risque de devenir si important qu'il deviendra nécessaire de les consigner quelque part. Pour donner à ce document sa légitimité, faites savoir qu'il est basé sur les discussions menées sur la liste et sur des accords ayant déjà cours. Lors de sa rédaction, veillez à faire référence aux fils pertinents dans les archives de la liste de diffusion, et s'il y a des points sur lesquels vous avez des doutes, reposez la question. Le document ne doit contenir aucune surprise : ce n'est pas la source des accords, ce n'est qu'un simple description. Certes, s'il est réussi, les gens commenceront à le citer comme référence, mais cela ne voudra seulement signifier qu'il reflète exactement la volonté générale du groupe.
La section intitulée « Les directives développeurs » dans le Chapitre 2, Bien démarrer fait allusion à ce document. Naturellement, si le projet est récent, il faut mettre par écrit les lignes directrices sans pouvoir s'appuyer sur les avantages d'une longue histoire. Mais au fur et à mesure que la communauté de développement mûrit, vous pourrez adapter le discours afin de refléter l'évolution du projet.
N'essayez pas d'être exhaustif. Aucun document ne peut contenir tout ce qu'il est nécessaire de savoir pour participer à un projet. Parmi les conventions générées par un projet, un bon nombre restent souvent inexprimées, voire ne sont jamais mentionnées explicitement, et pourtant, tout le monde les respecte. D'autres encore sont tout bêtement trop évidentes pour être mentionnées, et ne feraient que détourner l'attention d'éléments importants moins évidents. Il est inutile, par exemple, d'écrire des directives telles que « Soyez poli et respectueux sur les listes de discussion, ne lancez pas de trolls » ou « Écrivez du bon code dépourvu de bogues. ». Bien sûr, ces comportements sont souhaitables, mais ils sont si évidents qu'il est inutile de les mentionner. Si les gens sont grossiers sur les listes, ou s'ils écrivent du code bogué, ils ne vont pas cesser de le faire simplement parce que c'est écrit dans les directives du projet. Ces situations doivent être traitées lorsqu'elles se présentent, et non par des incitations génériques. D'un autre côté, si le projet a des directives spécifiques afin d'écrire du code de qualité, telles que des règles pour documenter chaque API dans un certain format, alors elles devraient être détaillées par écrit.
En vous basant sur les questions les plus courantes des nouveaux venus ainsi que sur les récriminations les plus fréquentes des développeurs expérimentés, vous aurez une bonne idée des points à faire figurer dans ce document. Ceci ne veut pas forcément dire qu'il se présentera sous la forme d'une FAQ, il nécessitera vraisemblablement une structure narrative plus cohérente que ne le permet une FAQ. Mais il devrait suivre le même principe : traiter des questions posées réellement, et non celles, qui selon vous, pourraient se poser.
Si le projet est une dictature bienveillante ou, si certains cadres sont investis de pouvoirs spéciaux (président, directeur ou autre), ce document est aussi une bonne occasion de codifier les procédures de succession. Parfois, ceci se résume simplement à la désignation de personnes particulières pour remplacer le DB au cas où celui-ci quitterait brusquement le projet pour une raison quelconque. Généralement, si DB il y a, il est le seul pouvant nommer un successeur. S'il y a des cadres élus, alors, la procédure de nomination et d'élection ayant servi à les désigner à l'origine devrait être décrite dans ce document. Si aucune procédure n'existe, cherchez le consensus via la liste de discussion avant de la mettre par écrit. Les gens sont parfois très chatouilleux en matière de hiérarchie, c'est pourquoi le sujet doit être abordé avec tact.
Mais le plus important est, peut-être, de dire clairement que les règles peuvent être révisées. Si les conventions décrites dans le document commencent à entraver le projet, rappelez bien à tout le monde que ledit document est censé être un portrait vivant des intentions du groupe et non une source de frustration et de blocage. Si quelqu'un prend l'habitude de demander, sans cesse, la révision des règles chaque fois qu'elles se mettent en travers de son chemin, vous n'êtes pas obligé d'en débattre en permanence : garder le silence est, parfois, une bonne tactique. Les autres personnes, en accord avec ses critiques, s'en mêleront, et, le changement deviendra évident. Mais si personne n'est d'accord, le point soulevé ne suscitera aucune réaction, et le règlement restera tel quel.
Deux bons exemples de directives de projet sont : le « Hacker's Guide » de Subversion (http://svn.collab.net/repos/svn/trunk/www/hacking.html) et les documents de gouvernance de l'Apache Software Foundation (http://www.apache.org/foundation/how-it-works.html et http://www.apache.org/foundation/voting.html). L'ASF est en réalité une collection de projets logiciels ayant un statut juridique d'organisme à but non lucratif, ces documents tendent donc à décrire des procédures de gouvernance plutôt que des conventions de développement. Cela vaut néanmoins la peine de les lire car ils sont le fruit de l'expérience accumulée au cours de nombreux projets Open Source.
| Chapitre 3 : Infrastructure technique | | Chapitre 5 : L'argent |
