De Framalang Wiki.

Chapitre 2 : Bien démarrer

Page d'accueil du projet

Chapitre 4 : Infrastructure sociale et politique

---

Sommaire 1 Chapitre 3 : Infrastructure technique 1.1 Les besoins d'un projet 1.2 Les listes de diffusion 1.2.1 Se prémunir du spam 1.2.1.1 Filtrer les messages 1.2.1.2 Masquer les adresses dans les archives 1.2.1.3 Identification et gestion des en-têtes 1.2.2 Le grand débat du « Répondre à » 1.2.3 L'archivage 1.2.4 Les logiciels 1.3 Les logiciels de gestion de versions 1.3.1 Vocabulaire de la gestion de versions 1.3.2 Choisir un logiciel de gestion de versions 1.3.3 Utilisation du logiciel de gestion de versions 1.3.3.1 Tout versionner 1.3.3.2 Navigabilité 1.3.3.3 E-mails de commit 1.3.3.4 Utilisez les branches pour éviter les embouteillages 1.3.3.5 Unicité de l'information 1.3.3.6 Autorisation 1.4 Suivi de bogues 1.4.1 Interaction avec les listes de diffusion 1.4.2 Filtrer le système de suivi de bogues en amont 1.5 IRC et les chats en temps réel 1.5.1 Robots 1.5.2 Archiver les conversations 1.6 Les flux RSS 1.7 Les wikis 1.8 Les sites Web 1.8.1 Les forges 2 Notes

Chapitre 3 : Infrastructure technique

Les projets de logiciels libres reposent sur des technologies basées sur la capture et l'intégration sélectives des informations. Plus vous êtes habile à employer ces technologies, et à persuader les autres de les employer, plus votre projet aura de succès. Et cela devient d'autant plus vrai que votre projet croit. La bonne gestion de l'information est ce qui empêche des projets Open Source de s'effondrer sous l'effet de la loi de Brook [12] qui stipule qu'ajouter de la main d'œuvre à un projet informatique en retard ne fait que le retarder plus encore. Fred Brook a observé que la complexité d'un projet informatique augmente proportionnellement au carré du nombre de participants. Quand seulement quelques personnes sont impliquées la communication est aisée, mais quand des centaines de personnes sont impliquées tout le monde ne peut plus savoir ce que chacun fait. Si pour bien gérer un projet de logiciel libre, il faut faire en sorte que chacun ait l'impression de travailler avec tous les autres dans la même pièce, une question s'impose : que se passe-t-il dans une pièce surpeuplée quand tout le monde veut parler en même temps ?

Ce problème n'est pas nouveau. Dans les salles surpeuplées non-métaphoriques la solution est le procédé parlementaire : ce sont des directives formelles sur les moyens de mener des discussions en temps réel dans de larges assemblées, sur le moyen de s'assurer que d'importantes divergences d'opinion ne vont pas se retrouvées noyées sous des flots de « moi-je », sur la manière de former des sous-comités, d'identifier quand des décisions sont prises, etc. L'un des rôles importants de ce procédé parlementaire est de spécifier comment le groupe interagit avec son système d'information. Certaines remarques ont vocation à être « enregistrées », d'autres non. Cet « enregistrement » lui-même est sujet à manipulations et n'est pas une transcription littérale de ce qui vient de se produire mais une représentation de ce que le groupe a convenu de considérer comme résultat. Cet « enregistrement » n'est pas monolithique, mais revêt différentes formes selon la finalité recherchée. Il comprend les comptes-rendus des différentes réunions, la totalité des comptes-rendus de toutes les réunions, les résumés, les ordres du jour et leurs annotations, les rapports de comité, les rapports des correspondants non présents, les listes d'actions à entreprendre, etc.

Puisqu'Internet n'est pas vraiment une salle, cette partie du procédé parlementaire qui fait taire les uns pendant que les autres parlent ne nous concerne pas. Mais quand on en vient aux techniques de gestion de l'information on voit que les projets Open Source bien dirigés utilisent ce procédé parlementaire boosté aux stéroïdes. Puisque presque toute la communication dans les projets Open Source se fait par écrit, des systèmes élaborés ont évolué pour permettre le cheminement et l'étiquetage des données de façon appropriée, pour minimiser les répétitions afin d'éviter des divergences inutiles, pour stocker et rechercher les données, pour corriger les informations fausses ou désuètes et pour connecter ensemble des bribes d'informations disparates au fur et à mesure que de nouveaux liens se créent. Les participants actifs dans les projets Open Source ont fait leurs plusieurs de ces techniques et réalisent souvent de complexes opérations manuelles afin de s'assurer que l'information est correctement transmise. Mais le plus gros de l'effort repose finalement sur la sophistication du logiciel sous-jacent. Les médias de communications eux-mêmes devraient assurer l'acheminement autant que faire se peut, l'étiquetage et l'enregistrement devraient mettre l'information à disposition de l'humain de la façon la plus commode possible. Dans la pratique, évidement, l'intervention humaine reste nécessaire à de nombreuses étapes du processus, et il est important que le logiciel rende de telles interventions aussi aisées que possible. En règle générale, si l'humain fait bien attention à l'étiquetage et à l'acheminement de l'information en entrée du système, le logiciel doit être configuré pour utiliser au mieux toutes ces méta-données.

Le contenu de ce chapitre est principalement pratique, basé sur des expériences avec des logiciels spécifiques et des modèles d'utilisation. Mais l'essentiel n'est pas simplement d'enseigner une collection de techniques particulières. L'essentiel est également de montrer, grâce à de nombreux petits exemples, quelle est l'attitude générale qui servira au mieux la bonne gestion de l'information dans votre projet. Cette attitude est la somme de qualités techniques et humaines. Les qualités techniques sont essentielles parce qu'un logiciel de gestion de l'information exige toujours d'être configuré, en plus d'une certaine dose de maintenance continue et de contournements au moment où de nouveaux besoins se font sentir (pour un exemple je vous renvoie à la discussion sur la façon de gérer la croissance d'un projet dans la section « Filtrer le système de suivi de bogues en amont » plus loin dans ce chapitre). Les qualités humaines sont nécessaires parce que la communauté humaine a, elle aussi, besoin de maintenance : il n'est pas toujours évident au premier abord de tirer le maximum de ces outils, et, dans certains cas, des conventions contradictoires existent (voir par exemple la discussion sur la configuration de l'en-tête du « Répondre à » dans le cas des listes de diffusion, dans la section appelée « Liste de diffusion »). Chaque personne impliquée dans le projet devra être encouragée, au bon moment et de la bonne façon, à faire sa part du travail pour que l'information du projet reste bien organisée. Lorsqu'un participant s'implique davantage, il est plus susceptible d'apprendre des techniques complexes et spécialisées.

Pour la gestion de l'information, il n'y a pas de recette miracle. Il y a trop de paramètres. Vous pouvez très bien être parvenu à tout configurer de manière optimale en regard de vos besoins et avoir une communauté active, il arrivera sûrement un moment où la croissance du projet rendra certaines de ces pratiques inadaptables. Il se peut aussi que la croissance du projet se stabilise, et que les communautés de développeurs et d'utilisateurs s'installent dans une relation confortable avec l'infrastructure technique, puis quelqu'un arrivera, et inventera un tout nouveau service de gestion de l'information, et aussitôt on vous demandera pourquoi votre projet ne l'emploie pas. C'est, par exemple, ce qui arrive en ce moment à beaucoup de projets Open Source antérieurs à l'invention du wiki (voir le lien http://fr.wikipedia.org/wiki/Wiki). Beaucoup d'interrogations relèvent surtout d'une question de point de vue, comme la différence entre coté pratique pour ceux qui produisent l'information et coté pratique pour ceux qui la consomment, ou entre le temps requis pour configurer un logiciel de gestion de l'information et les avantages qu'il peut apporter au projet.

Prenez garde à la tentation de sur-automatiser, c'est-à-dire, d'automatiser les choses qui exigent vraiment une attention humaine. L'infrastructure technique est importante, mais ce qui fait qu'un projet Open Source fonctionne, c'est l'attention, ainsi que l'expression intelligente de cette attention, que les humains impliqués vont déployer. Le but principal d'une infrastructure technique est de fournir à l'humain les outils les plus adaptés pour faire cela.

Les besoins d'un projet

La plupart des projets Open Source offrent un minimum d'outils pour la gestion de l'information :

• Site Web

La vitrine de votre projet aux yeux du public (centralisé et à sens unique). Le site Web peut également servir d'interface administrative à d'autres outils du projet.

• Listes de diffusion

Traditionnellement le principal moyen de communication, et aussi le plus actif, au sein du projet et le « médium d'enregistrement »

• Contrôle de versions

Permet aux développeurs de contrôler facilement les changements apportés au code, les régressions et de gérer les branches de développements parallèles. Elle permet à chacun d'observer les modifications du code.

• Référencement de bogues

Permet aux développeurs d'avoir l'historique de leurs travaux, de se coordonner les uns avec les autres et de planifier les correctifs. Permet à chacun de connaître le statut précis des bogues, et les informations liées (par exemple, les conditions de leur reproductibilité). La même méthode peut d'ailleurs être employée pour faire le suivi, non seulement des bogues, mais également des tâches, des versions, des nouvelles fonctionnalités, etc.

• Messagerie instantanée / chat en temps réel

Un endroit pour les discussions et les échanges en mode questions/réponses rapides et simples. N'est pas toujours archivé complètement.

Chaque outil, dans cet ensemble, satisfait un besoin particulier, mais leurs fonctions sont étroitement liées et ces outils doivent être conçus pour fonctionner ensemble. Plus loin, nous verrons comment ils peuvent le faire, et surtout, comment faire pour que les gens les utilisent. Le site Web ne sera pas évoqué tout de suite, car il s'agit plus d'un ciment pour les autres composants que d'un outil à part entière.

Vous pouvez vous éviter les prises de tête liées au choix et à la configuration de tous ces outils en optant pour une forge : un serveur qui offre, prêts à l'emploi, des modèles avec tous les outils nécessaires pour gérer un projet Open Source. Voir la section appelée « Les forges » plus loin dans ce chapitre pour une évaluation des avantages et des inconvénients des forges.

Les listes de diffusion

Les listes de diffusion sont la base de la communication au sein d'un projet. Si un utilisateur est confronté à un espace de dialogue, en dehors des pages Web, il y a de fortes chances que ce soit une des listes de diffusion du projet. Mais avant d'expérimenter la liste de diffusion elle-même, il sera en contact avec l'interface de la liste de diffusion ; c'est à dire le mécanisme par lequel il peut rejoindre la liste (« souscrire »). Ceci nous amène à la règle #1 des listes de diffusion :

N'essayez pas de gérer une liste de diffusion à la main: procurez-vous un logiciel de gestion de listes.

Il serait tentant de repousser cela à plus tard. Le temps passé à installer un logiciel de gestion de listes peut sembler peu rentable au début. Gérer à la main de petites listes générant peu de trafic semble séduisant : établissez simplement une adresse d'abonnement qui redirige vers votre boîte mail, et quand quelqu'un l'utilise, ajoutez (ou enlevez) son adresse mail dans un fichier texte qui contient toutes les adresses de la liste. Qu'y a-t-il de plus simple ?

Le hic, c'est qu'une bonne gestion de listes de diffusion, ce que les gens sont en droit d'attendre, n'est pas simple du tout. Il ne s'agit pas simplement d'abonner et de désabonner les utilisateurs quand ils le demandent. Il s'agit également de faire de la modération pour empêcher le spam, d'offrir des versions résumées, et, message par message, de fournir de l'information standard et de l'information orientée projet grâce à des messages pré-écrits, ainsi que diverses autres choses. Un être d'humain gérant lui-même une adresse de souscription ne peut assurer que le strict minimum, et même en cela, il n'est pas aussi fiable et performant qu'un logiciel.

Les logiciels modernes de gestion de liste offrent au minimum les fonctionnalités suivantes :

Inscription par e-mail et par le Web

Quand un utilisateur s'abonne à une liste, il devrait recevoir rapidement un message d'accueil automatique en réponse, lui indiquant ce à quoi il s'est abonné, quels sont les possibilités offertes par le logiciel de liste de diffusion, et (ce qui est le plus important) comment se désinscrire. Bien sûr, cette réponse automatique peut être personnalisée pour donner plus d'informations sur le projet, comme par exemple l'adresse du projet, où trouver la FAQ, etc.

L'abonnement en mode résumé ou message par message

En mode résumé, l'abonné reçoit un courrier par jour contenant toutes les activités du jour de la liste. Pour les gens qui suivent une liste de manière détachée, sans participer, le mode résumé est souvent préférable car il permet de survoler rapidement tous les sujets et évite la distraction de recevoir des e-mails à n'importe quel moment.

Les possibilités de modération

La modération sert à vérifier les messages pour s'assurer que ce n'est pas a) du spam et b) hors sujet avant qu'ils ne soient envoyés à la liste entière. La modération demande une intervention humaine, mais les logiciels peuvent mâcher une grosse partie du travail. Nous reviendrons à la modération plus tard.

Interface administrative

L'interface administrative permet, entre autres choses, à l'administrateur de retirer les adresses obsolètes facilement. Cela peut devenir urgent quand l'adresse d'un destinataire commence à renvoyer automatiquement des messages du type « Je ne suis plus à cette adresse » à la liste à chaque e-mail (certains logiciels de listes de diffusion peuvent même les détecter seuls et désabonner ces personnes automatiquement).

Manipulation des en-têtes

Beaucoup de gens ont mis en place des filtrages sophistiqués et des règles de réponse dans leur logiciel de messagerie. Les logiciels de listes de diffusion peuvent ajouter et manipuler certains en-têtes standards pour permettre à ces personnes d'en tirer partie (nous y reviendrons).

Archivage

Tous les messages des listes sont enregistrés et mis à disposition sur le Web, certains logiciels de listes de diffusion proposent des interfaces spéciales pour assurer leur compatibilité avec des utilitaires d'archivage tiers comme MHonArc (http://www.mhonarc.org/). Comme nous le verrons dans la section « Utilisation visible des archives » dans le Chapitre 6, Communication, l'archivage est crucial.

Retenez simplement ici que la gestion des listes de diffusion est un problème complexe, ayant déjà reçu beaucoup d'attention, mais en grande partie résolu. Vous n'êtes pas obligé de devenir expert sur le sujet, mais vous devriez savoir qu'il y a toujours de nouvelles choses à découvrir et que la gestion des listes demandera votre attention de temps à autres au cours de la vie de votre projet de logiciel libre. Ci-dessous nous allons examiner quelques uns des principaux problèmes rencontrés lors de la configuration des listes de diffusion.

Se prémunir du spam

Entre le moment où j'écris cette phrase et le moment où elle sera publiée, le problème du spam sur Internet aura sûrement pris des proportions beaucoup plus importantes ou, en tout cas, on le ressentira comme tel. Il fut un temps, il n'y a pas si longtemps, où l'on pouvait créer une liste de diffusion sans avoir à prendre de mesures de protection contre le spam. De temps en temps, on pouvait recevoir un e-mail égaré, mais c'était suffisamment rare pour que cela reste peu gênant. Cette âge d'or est révolu. De nos jours, une liste de diffusion qui ne se prémunie pas du spam sera rapidement noyée sous les e-mails indésirables, au point qu'elle en devienne inutilisable. Les protections contre le spam sont indispensables. On peut séparer les protections contre le spam en deux catégories : celles qui empêchent les courriers indésirables d'apparaître sur la liste de diffusion et celles qui protègent les listes de diffusions contre les collecteurs d'adresses des spammeurs. La première étant la plus importante, c'est celle que nous allons détailler en premier.

Filtrer les messages

Il existe trois techniques de base pour éviter les messages indésirables, la plupart des logiciels de listes de diffusions les proposent toutes les trois. Il vaut mieux les utiliser de concert :

1. Autoriser automatiquement les messages uniquement envoyés par les abonnés.

Cette méthode remplit très bien son rôle, et ne demande que peu de travail puisqu'en général il suffit de modifier un paramètre dans les réglages du logiciel de liste de diffusion. Mais prenez garde, les messages qui ne sont pas automatiquement approuvés ne doivent pas être rejetés pour autant. Ils devraient subir une inspection pour deux raisons. D'abord, vous feriez mieux de laisser la possibilité aux non-abonnés d'envoyer des messages. Une personne ayant une question, ou une idée à soumettre, ne devrait pas avoir besoin de s'inscrire à la liste de diffusion juste pour y envoyer un message. Ensuite, même les abonnés envoient parfois des messages depuis d'autres adresses que celle qu'ils ont utilisées pour s'inscrire. Les adresses mails ne sont pas une méthode sure pour identifier les personnes, et par conséquent ne doivent pas servir à cela.

2. Filtrer les messages grâce à un logiciel de filtrage.

Si la liste de diffusion le permet (la plupart le font), vous pouvez filtrer les messages grâce à un logiciel de filtrage de spam. Le filtrage automatique des spams n'est pas parfait et ne le sera jamais vu que les spammeurs et les développeurs de filtres se sont engagés dans une course à l'armement sans fin. Malgré cela, le filtre peut largement réduire le nombre de spams en attente de modération. Comme la longueur de la liste d'attente se traduit en temps de travail manuel, tout gain obtenu à ce niveau grâce au filtrage automatique est bon à prendre.

Je ne peux pas détailler ici la mise en place des filtres à spam. Je vous renvoie donc à la documentation de votre logiciel de liste de diffusion pour en savoir plus (voir la section appelée « Logiciel » plus loin dans ce chapitre). Les logiciels de liste de diffusion incluent souvent des fonctionnalités anti-spam, mais vous pouvez aussi choisir d'utiliser un programme de filtrage tiers. J'apprécie ces deux programmes : SpamAssassin (http://spamassassin.apache.org/) et SpamProbe (http://spamprobe.sourceforge.net/). Je ne ferai pas de liste exhaustive, il existe bien d'autres logiciels de filtrage de spam Open Source, et certains semblent également très performants. C'est simplement que j'ai utilisé moi même les deux logiciels pré-cités et j'en ai été très satisfait.

3. Modération

En ce qui concerne les courriers qui ne sont pas automatiquement admis parce qu'ils n'émanent pas d'un abonné, et qui passent au travers du logiciel anti-spam, s'il est présent, la dernière étape est la modération : le mail est redirigé vers une adresse spéciale où une personne l'examinera et l'acceptera ou le rejettera.

Accepter un message peut se faire de deux manières différentes : vous pouvez autoriser le message juste cette fois, ou encore, dire au logiciel de liste de diffusion de laisser passer dans le futur tous les messages de cet expéditeur. En général, c'est la deuxième option qui est favorisée afin de faciliter la tâche de modération à l'avenir. La manière de procéder est différente selon les systèmes, mais en général il faut répondre à une adresse particulière en incluant la commande « accepter » (ce qui signifie « accepter uniquement ce message ») ou « autoriser » (autoriser ce message ainsi que tous les futurs messages).

Le rejet se fait en général simplement en ignorant le courrier de modération. Si le logiciel de la liste de diffusion ne reçoit jamais de consigne pour dire qu'un message est valide, alors, il ne fera pas suivre ce message sur la liste : laisser le message de côté aura donc l'effet désiré. Il arrivera aussi parfois que vous ayez la possibilité de répondre avec une commande « rejeter » ou « empêcher » pour rejeter automatiquement et de façon permanente les messages de cet utilisateur sans même qu'ils ne repassent par la case « Modération ». En général, ce n'est pas très utile puisque la modération sert principalement à éviter le spam, et que, de toute façon, les spammeurs utilisent rarement la même adresse deux fois .

La modération doit servir uniquement au filtrage des spams et des messages hors-sujet, ainsi quand quelqu'un envoie un message sur la mauvaise liste de diffusion. Le système de modération devrait vous fournir un moyen de répondre directement à l'expéditeur, mais n'employez pas cette méthode pour répondre directement à une question adressée à la liste de diffusion, même si vous pouvez fournir une réponse rapidement. Fonctionner ainsi empêcherait le projet de se faire une idée précise du genre de questions que les gens se posent et enlèverait aux membres l'occasion de répondre aux questions eux-mêmes et/ou de voir les réponses des autres. La modération des listes de diffusion doit se borner à l'entretien de la liste de diffusion, rien d'autre.

Masquer les adresses dans les archives

Pour éviter que vos listes de diffusion ne deviennent une mine d'adresses pour les spammeurs, une technique courante est de masquer les adresses e-mail des personnes dans les archives en remplaçant par exemple

a.nonyme@undomaine.com

par

a.nonyme_AT_undomaine.com

ou par

a.nonymeNOSPAM@undomaine.com

ou d'autres codes similaires évidents pour un humain. Comme les collecteurs d'adresses à spammer fonctionnent souvent en naviguant sur les pages Web, y compris vos archives en ligne des listes de diffusion, à la recherche de séquences contenant « @ », coder les adresses est une manière de rendre les adresses e-mail invisibles ou inutilisables par les spammeurs. Cela ne change rien à la quantité de spam envoyée directement à la liste de diffusion évidemment, mais au moins vous évitez d'augmenter encore la quantité de spams envoyés directement aux utilisateurs des listes.

Le masquage d'adresse peut être sujet à controverse. Certaines personnes appréciant beaucoup cette technique seront surprises si vos archives ne le font pas automatiquement. D'autres pensent plutôt que c'est un désagrément (parce que les vraies personnes doivent aussi traduire les adresses avant de les utiliser). Certains doutent de l'efficacité de la méthode puisqu'un collecteur peut en théorie s'adapter aux codes les plus répandus. Notez malgré tout que, par expérience, le masquage d'adresse se montre efficace, voir http://www.cdt.org/speech/spam/030319spamreport.shtml.

Idéalement, le programme de gestion de listes devrait laisser le choix à chaque abonné, grâce à une en-tête oui/non ou un paramètre dans les préférences du compte de l'abonné. Mais je ne connais aucun logiciel qui donne un choix individuel ou par message, donc pour l'instant le responsable des listes doit faire ce choix pour tout le monde (en supposant que le logiciel d'archivage propose cette option, ce qui n'est pas toujours le cas). Je penche légèrement en faveur du masquage d'adresse. Certaines personnes sont très prudentes et n'affichent par leur adresse e-mail sur les pages Web ou n'importe quel endroit où un collecteur d'adresse pourrait tomber dessus, elles seraient déçues de voir tous les efforts réduits à néant par une archive de liste de diffusion. De plus, le désagrément imposé aux utilisateurs des archives par le masquage est très faible puisqu'il est très simple de « traduire » ces adresses si vous avez besoin de contacter quelqu'un. Mais n'oubliez pas qu'au final, cela reste une course à l'armement: au moment où vous lirez ceci, les collecteurs auront peut-être évolués au point qu'ils pourront reconnaître les techniques classiques de masquage d'adresse e-mail et nous devrons trouver alors une autre parade.

Identification et gestion des en-têtes

Les utilisateurs des listes rangeront souvent les messages dans des dossiers réservés au projet, séparés de leurs autres courriers. Leur logiciel de lecture de courrier peut faire cela automatiquement en vérifiant les en-têtes du message. Les en-têtes sont le champs au début du courrier qui indiquent l'expéditeur, le destinataire, le sujet, la date et d'autres informations à propos du message. Certains en-têtes sont bien connus et obligatoires :

De : ...

À : ...

Sujet : ...

Date : ...

D'autres sont optionnels bien que plutôt courants. Par exemple, vous n'êtes pas obligés de remplir l'en-tête :

Répondre à : expéditeur@adresse.e-mail.ici

Mais la plupart des gens le font puisque cela permet au destinataire de répondre de manière certaine à l'auteur du message (c'est particulièrement utile si l'auteur a dû recourir à une adresse différente de celle à laquelle les réponses devraient être adressées).

Certains logiciels de courrier fournissent une interface simple d'emploi pour trier les messages en fonction du sujet. Certaines personnes demandent par conséquent que les listes de diffusions ajoutent automatiquement un préfixe aux sujets afin que leur logiciel puisse automatiquement ranger ces messages dans le bon dossier. L'idée est que l'auteur du message écrive :

Sujet : Préparation de la version 2.5

mais que le message au final soit envoyé sous cette forme :

Sujet : [discussion@listes.exemple.org] Préparation de la version 2.5 (par exemple).

Bien que la plupart des logiciels de gestion de listes de diffusion proposent cette option, je ne vous recommande pas de l'activer. Le problème réglé ici peut l'être par des moyens beaucoup moins marqués, et le prix à payer, l'utilisation de l'espace dans le champ « Sujet », est bien trop élevé. Les utilisateurs habitués aux listes de diffusion passent en général en revue les sujets des messages pour décider ce qu'ils vont lire et ce à quoi ils vont répondre. Ajouter le nom de la liste au sujet peut repousser la partie importante du sujet hors de l'écran, la rendant ainsi invisible. Cela masque les informations sur lesquels les gens se reposent durant leur inspection des sujets, réduisant par conséquent l'utilité de la liste de diffusion. Plutôt que de grignoter une partie du champ « Sujet », enseignez aux utilisateurs à utiliser les autres champs, en commençant par le champ « À : » qui devrait afficher le nom de la liste :

À : <discussion@listes.exemple.org>.

N'importe quel logiciel de messagerie pouvant filtrer les sujets devrait également pouvoir filtrer aussi facilement le champ « À : ». D'autres champs optionnels sont en général remplis pour les listes de diffusion. Baser le filtrage sur ces champs est encore plus efficace que d'utiliser les champs « À : » ou « Cc » puisque ces champs sont remplis automatiquement par le logiciel de la liste de diffusion, certains utilisateurs s'attendent à les trouver :

list-help: <mailto:discuss-help@lists.example.org>

list-unsubscribe: <mailto:discuss-unsubscribe@lists.example.org>

list-post: <mailto:discuss@lists.example.org>

Delivered-To: mailing list discuss@lists.example.org

Mailing-List: contact discuss-help@lists.example.org; run by ezmlm

Pour la plupart, leur fonction est évidente. Voir http://www.nisto.com/listspec/list-manager-intro.html pour plus d'informations à ce sujet, ou, si vous cherchez des spécifications vraiment détaillées et formelles voir http://www.faqs.org/rfcs/rfc2369.html.

Vous remarquerez que ces champs suggèrent que si vous avez une liste nommée « list », alors vous possédez aussi les listes administratives « list-help » et « list-unsubscribe ». En plus de celles-ci, il est normal que vous proposiez « list-subscribe » pour s'inscrire et « list-owner » pour contacter les administrateurs des listes. En fonction du logiciel utilisé pour gérer vos listes, ces adresses et/ou plusieurs autres adresses administratives peuvent être mises en place, vous trouverez des explications dans la documentation. En général, un descriptif complet de toutes ces adresses spéciales est communiqué à chaque nouvel utilisateur au sein d'un message de bienvenue lors de l'inscription. Vous recevrez aussi certainement une copie de ce courrier. Si vous ne le recevez pas, alors demandez en une copie afin de savoir ce que reçoive les utilisateurs lorsqu'ils s'inscrivent à une liste. Gardez ce message à portée afin de pouvoir répondre aux questions concernant les fonctions de la liste de diffusion ou, encore mieux, affichez le sur une page Web, ainsi quand quelqu'un perd sa copie des instructions et envoie un message concernant les modalités de désinscription, vous n'avez qu'à lui envoyer l'URL.

Certains logiciels de liste de diffusion possèdent une option pour ajouter les instructions de désabonnement à chaque message. Si cette option est présente, activez là. Cela n'ajoute que quelques lignes au message, ne gène pas sa lecture, et peut vous faire gagner beaucoup de temps en évitant que les gens ne vous écrivent, ou pire encore, n'écrivent à toute la liste, pour demander comment se désinscrire.

Le grand débat du « Répondre à »

Précédemment, dans une partie appelée « Éviter les discussions privées », j'ai insisté sur l'importante du fait que les discussions doivent se dérouler dans les forums publics, et j'ai dit que parfois des mesures devaient être prises pour éviter que les conversations ne se transforment en échanges privés d'e-mails. Ce chapitre traite de la mise en place des logiciels de communication du projet afin qu'ils facilitent au maximum la vie du projet. Par conséquent, si le logiciel de gestion des listes de discussion vous offre la possibilité de garder automatiquement les discussions sur la liste, vous vous direz qu'il est logique d'activer cette fonctionnalité. En fait ce n'est pas si évident. Cette option existe, mais elle comporte des inconvénients plutôt restrictifs. Son utilisation est sujette à l'un des plus importants débats concernant la gestion des listes de diffusion, rien qui ne fera la une des journaux du soir, mais parfois les discussions à ce propos peuvent devenir tendues au sein des projets de logiciels libres. Ci-dessous je vais décrire la fonctionnalité, donner les principaux arguments de chaque camp et je vous donnerai mes meilleures recommandations.

La fonctionnalité en elle-même est très simple : le logiciel peut, si vous le souhaitez, remplir le champ « Répondre à : » automatiquement afin que les réponses soient redirigées sur la liste de diffusion. C'est à dire que, peu importe ce que l'expéditeur met dans le champ « Répondre à : » (ou même s'il ne le remplit pas), quand les abonnés de la liste recevront le message l'en-tête contiendra l'adresse de la liste :

Répondre à : discuss@lists.example.org

De prime abord, cela semble être une bonne chose parce que quasiment tous les logiciels de messagerie inspectent le champ « Répondre à : » et donc quand quelqu'un enverra une réponse, elle sera automatiquement envoyée à la liste entière: pas uniquement à l'expéditeur du message auquel on répond. Bien sûr, la personne qui répond peut modifier à la main le destinataire du message, mais l'important est que, par défaut, les réponses sont directement envoyées à la liste. C'est un très bon exemple d'utilisation de la technologie pour encourager la collaboration.

Malheureusement, il existe quelques inconvénients. Le premier est connu sous le nom du problème de « Je ne peux plus retrouver mon chemin » : il se peut que l'expéditeur mette sa « véritable » adresse e-mail dans le champ « Répondre à : » parce que, pour une raison ou pour une autre, il a utilisé une autre adresse pour envoyer le message que celle qu'il utilise pour les recevoir. Les personnes, qui expédient et lisent les messages à partir de la même adresse, n'ont pas ce problème, et sont même parfois surprises d'apprendre son existence. Mais, pour ceux qui utilisent leurs comptes mail de manière particulière ou qui n'ont pas de contrôle sur le champ « De : » dans leurs courriers (parce qu'ils écrivent depuis leur travail, ou parce qu'ils n'ont pas assez d'influence sur le département informatique), utiliser le champ « Répondre à : » peut être la seule manière d'être sûr que les réponses leur parviennent. Quand une personne dans cette situation envoie un message à une liste de diffusion à laquelle il n'est pas abonné, l'adresse dans le champ « Répondre à : » devient une information essentielle. Si le logiciel remplace cette adresse, il se peut qu'il ne reçoive jamais de réponse.

Le deuxième inconvénient est lié aux attentes et, d'après moi, c'est l'argument qui a le plus de poids contre l'automatisation du champ « Répondre à : ». La majorité des gens ayant l'habitude de se servir des e-mails sont accoutumés à deux choix simples pour répondre : Répondre à tous et Répondre. Tous les logiciels de messagerie modernes possèdent deux boutons distincts pour ces deux fonctions. Les utilisateurs savent que pour répondre à tout le monde (ce qui inclut la liste), ils doivent utiliser le bouton « Répondre à tous », et que pour répondre en privé à l'auteur ils doivent utiliser le bouton « Répondre ». Même si votre but est d'encourager les gens à répondre à toute la liste le plus souvent possible, il y aura parfois des circonstances qui font qu'une réponse privée est plus appropriée, par exemple, si une personne veut dire quelque chose de confidentiel à l'auteur du message original, quelque chose qui n'aurait pas sa place sur la liste publique.

Maintenant penchons nous sur le cas où la liste a ré-écrit le champ « Répondre à : ». La personne qui répond appuie sur le bouton « Répondre » en s'attendant à envoyer un message privé à l'auteur du courrier. Puisque c'est ce qu'il se passe normalement, il ne prendra par forcément la peine de vérifier l'adresse du destinataire du message. Il écrit alors son message privé et confidentiel, où il pourrait dire des choses gênantes sur une autre personne de la liste, et appuie ensuite sur « Envoi ». Alors qu'il ne s'y attendait pas, quelques minutes plus tard son message apparaît sur la liste de diffusion ! Il aurait effectivement, en théorie, dû prendre le temps de regarder avec précaution le champ « Destinataire », et n'aurait pas dû supposer qu'il n'avait pas à se soucier du champ « Répondre à : ». Mais les expéditeurs règlent quasiment à chaque fois le champ « Répondre à : » de telle sorte qu'ils reçoivent la réponse (ou pour être plus précis, c'est leur logiciel de messagerie qui le fait pour eux), et beaucoup d'utilisateurs expérimentés le prennent pour argent comptant. En fait, lorsqu'une personne met une autre adresse que celle de l'expéditeur dans le champ « Répondre à : », comme celle de la liste par exemple, il prendra en général la peine de le notifier dans le message, ainsi les gens ne seront pas surpris par ce qui se passe lorsqu'ils appuient sur « Répondre ».

À cause des lourdes conséquences potentielles que cela peut entraîner, je préfère configurer le logiciel de gestion de liste de manière à ce qu'il ne modifie pas le champ « Répondre à : ». C'est l'un des cas où l'utilisation de la technologie pour encourager la collaboration peut, à mon sens, avoir des effets pervers. Mais l'autre camp a également d'excellents arguments à faire valoir. Quelque soit votre choix, des gens de temps à autres vous demanderont pourquoi vous n'avez pas fait l'autre choix. Comme c'est quelque chose que vous ne voulez pas voir prendre de trop grandes proportions, il vaut mieux que vous ayez une réponse toute prête, une réponse qui mettra un terme au débat plutôt que de l'encourager. Ne faites pas paraître votre décision, que vous choisissiez une solution ou l'autre, comme étant la seule, l'unique valable et la bonne (même si vous pensez que c'est le cas). Insistez plutôt sur le fait que c'est un très vieux débat, que les deux camps possèdent de bon arguments, mais qu'aucun choix ne peut satisfaire tous les utilisateurs, en conséquence, vous avez pris la décision qui vous semblait la meilleure. Demandez poliment à ce que le sujet ne soit pas ré-ouvert, à moins que quelqu'un ait quelque chose de vraiment nouveau à apporter au débat, puis ne participez plus à la discussion en espérant qu'elle s'éteigne d'elle-même. Quelqu'un pourrait suggérer de voter pour choisir une méthode ou l'autre. Vous pouvez le faire si c'est votre choix, mais je ne pense pas qu'un vote à main levée soit la meilleure solution dans ce cas. Le risque que quelqu'un se fasse surprendre par la modification du champ « Répondre à : » est trop important et le désagrément pour chacun est plutôt faible (devoir rappeler occasionnellement aux gens de répondre à la liste entière) pour qu'une majorité, même si c'est la majorité, impose un tel risque à une minorité. Je n'ai pas abordé, ici, tous les aspects de ce problème, seulement ceux qui semblaient les plus importants. Si le sujet vous intéresse je vous conseille de lire ces deux documents canoniques toujours cités dans ce débat :

• Leave Reply-to alone, de Chip Rosenthal http://www.unicom.com/pw/reply-to-harmful.html
• Set Reply-to to list, de Simon Hill http://www.metasystema.net/essays/reply-to.mhtml

Malgré cette légère préférence énoncée ci-dessus, je ne pense pas qu'il existe une vérité « transcendante » dans ce débat, et je participe gaiement à de nombreuses listes imposant le « Répondre à : ». Le mieux que vous puissiez faire, est d'opter assez tôt pour une solution ou pour l'autre, et d'éviter de vous faire attirer dans un débat par la suite.

Deux rêves

Un jour, quelqu'un aura cette idée brillante d'ajouter un bouton « Répondre à la liste » dans un logiciel de messagerie. Pour ce faire, il se servirait des en-têtes afin de déterminer l'adresse de la liste de diffusion, et enverrait donc la réponse directement à la liste, en ne se préoccupant pas des adresses d'autres destinataires puisqu'ils sont pour la plupart déjà inscrits à la liste de toute façon. Finalement, d'autres logiciels de messagerie reprendraient l'idée et le débat deviendrait obsolète (en fait, le logiciel de messagerie Mutt propose déjà cette fonctionnalité. Il ne reste plus aux autres qu'à la copier [13]).

Une meilleure solution : laisser le choix à chaque abonné. Ceux qui veulent que la liste remplisse le champ « Répondre à : » (que se soit pour leurs propres messages ou ceux des autres) pourraient régler cette option et ceux qui ne le veulent pas pourraient aussi choisir. Je ne connais cependant aucun logiciel de gestion de liste qui permette ce choix individuel. Pour le moment on doit faire avec une configuration identique pour tous.[14]

L'archivage

Les détails techniques concernant la mise en place de l'archivage d'une liste de diffusion sont particuliers au logiciel qui fait fonctionner la liste et dépassent le cadre de ce livre. Lors du choix, ou de la configuration, de l'archive, vous devez prendre en compte les facteurs suivants :

Mise à jour rapide

Les gens se réfèreront souvent à un message archivé envoyé une ou deux heures auparavant. Si possible, le logiciel devrait archiver chaque message instantanément afin que, dès qu'un message apparaît dans la liste de diffusion, il soit aussi présent dans les archives. Si cette option n'est pas disponible, alors essayez de faire en sorte que l'archive soit remise à jour au moins toutes les heures (par défaut certains logiciels d'archives se mettent à jour automatiquement chaque nuit, mais dans la pratique ce délai est bien trop important pour une liste de diffusion active).

La stabilité du référentiel

Une fois qu'un message est archivé à une URL donnée, il devrait rester accessible par la même URL à tout jamais, ou le plus longtemps possible en tout cas. Même si les archives sont reconstruites, rétablies à partir d'une sauvegarde ou réparées d'une quelconque manière, chaque URL qui a été rendue publique ne devrait pas être modifiée. Des coordonnées stables rendent possible l'indexation des archives par les moteurs de recherche qui sont les meilleures compagnons des utilisateurs en quête de réponses. Des coordonnées stables sont aussi importantes, car les messages et les sujets, dans les listes de diffusion, contiennent souvent des liens vers le système de suivi de bogues (voir la section nommée « Système de suivi de bogues » plus loin dans ce chapitre) ou vers d'autres documents du projets.

Idéalement, les logiciels de listes de diffusion devraient inclure l'URL du message dans les archives, ou, au moins, une portion particulière de l'URL dans les en-têtes du message lorsqu'il est distribué aux destinataires. Ainsi, ceux qui ont une copie du message peuvent savoir où est rangé le message dans les archives sans avoir à se rendre sur la page des archives. C'est utile en effet, car toute opération nécessitant l'utilisation d'un navigateur prend du temps. Par contre, je ne sais pas s'il existe un logiciel proposant cette fonctionnalité. Ceux que j'ai utilisés ne le faisaient pas. C'est quand même une fonctionnalité que vous devriez chercher (ou, si vous écrivez un logiciel de gestion de listes de diffusion, c'est une fonctionnalité que vous devriez penser à ajouter, s'il vous plaît).

Les sauvegardes

La méthode de sauvegarde des archives devrait être plutôt évidente, et la manière de les restaurer ne devrait pas être trop compliquée non plus. En d'autres termes, ne voyez pas votre logiciel d'archivage comme une boîte noire. On (vous ou quelqu'un de votre projet) devrait savoir où les messages sont classés, et comment recréer la page d'archives depuis les messages sauvegardés si nécessaire. Ces archives sont des données précieuses, un projet qui perd ses archives perd une grande partie de sa mémoire collective.

La gestion des sujets

Il devrait être possible de naviguer depuis n'importe quel message vers le sujet (groupe de messages ayant un lien) auquel appartient ce message. Chaque sujet devrait avoir sa propre URL, différente de l'URL des messages composant ce sujet.

Recherche

Un logiciel d'archivage ne proposant pas d'outil de recherche, ni dans le corps des messages, ni par auteur ou par sujet, est quasiment inutile. Remarquez que certains logiciels proposent un outil de recherche simplement en sous-traitant le travail à un moteur de recherche tiers comme Google. Ça peut passer, mais un outil de recherche natif est en général plus précis, puisqu'il permet à la personne effectuant la recherche de spécifier que le mot doit se trouver dans le sujet et pas dans le corps du texte par exemple.

Ceci n'est qu'une liste technique pour vous aider à évaluer et mettre en place un outil d'archivage. Comment amener les gens à vraiment utiliser cet outil pour le bien du projet, est un sujet différent ,qui sera abordé dans d'autres chapitres, plus loin dans ce livre, en particulier dans la section intitulée « Utilisation visible des archives ».

Les logiciels

Voici une liste d'outils Open Source pour la gestion et l'archivage de listes. Si le site qui héberge votre projet propose déjà une configuration par défaut, vous n'aurez peut-être jamais à faire de choix. Mais si vous devez en installer un vous même, en voici quelques uns. Ceux que j'ai utilisés sont Mailman, Ezmlm, MHonArc et Hypermail, mais cela ne veut pas dire que les autres ne sont pas bons (et bien sûr, il existe probablement d'autres outils sur lesquels je ne suis pas tombé, cette liste n'a rien d'exhaustif.). Les logiciels de gestion de listes de diffusions sont :

• Mailman — http://www.list.org/ (Possède un outil d'archivage inclus, et s'adapte bien aux outils d'archivage tiers.)
• SmartList — http://www.procmail.org/ (Fait pour être utilisé avec le système d'envoi de courrier Procmail.)
• Ecartis — http://www.ecartis.org/
• ListProc — http://listproc.sourceforge.net/
• Ezmlm — http://cr.yp.to/ezmlm.html (Fait pour être utilisé avec le système d'envoi de courrier Qmail.)
• Dada — http://mojo.skazat.com/ (Malgré les tentatives étranges faites sur le site Web pour s'en cacher, c'est bien un logiciel libre, publié sous licence GNU General Public License. Il propose aussi un outil d'archivage incorporé.)

Les logiciels d'archivage sont :

• MHonArc — http://www.mhonarc.org/
• Hypermail — http://www.hypermail.org/
• Lurker — http://sourceforge.net/projects/lurker/
• Procmail — http://www.procmail.org/ (Logiciel fonctionnant de pair avec SmartList, c'est un système d'envoi de courrier qui peut apparemment être configuré pour réaliser l'archivage également.)

Les logiciels de gestion de versions

La bonne utilisation d'un logiciel de gestion de versions (ou logiciel de gestion de révisions) est un mélange de technologie et de bonnes pratiques pour traquer et contrôler les modifications apportées aux fichiers d'un projet, en particulier au code source, à la documentation et aux pages Web. Si vous n'avez jamais utilisé un logiciel de gestion de version, la première chose que vous devriez faire est de trouver quelqu'un en ayant déjà utilisé, et le convaincre de rejoindre le projet. De nos jours, tout le monde s'attend au minimum à ce que le code source du projet soit sous la surveillance d'un logiciel de gestion de versions, et votre projet ne sera pas pris au sérieux s'il n'utilise pas efficacement un logiciel de gestion de versions.

Les logiciels de gestion de versions sont devenus des standards, car ils fournissent une aide précieuse dans quasiment chaque domaine d'un projet efficace : la communication entre développeurs, la gestion des sorties, la gestion des bogues, la stabilité du code, le développement expérimental, les attributions et les autorisations de modifications. La gestion de versions vous fournit un contrôle centralisé sur tous ces domaines. Le cœur de la gestion de versions est la gestion des modifications : l'identification de chaque petit changement apporté aux fichiers du projet, l'annotation de chaque modification par des méta-données comme la date du changement et son auteur, et, ensuite, la possibilité de ressortir ces données pour toute demande, ceci quelqu'en soit la manière. C'est un mécanisme de communication pour lequel le changement est l'unité de base de l'information.

Nous n'aborderons pas tous les aspects de l'utilisation d'un logiciel de gestion de versions dans cette partie. La gestion de versions étant un vaste sujet, nous l'étudierons au fur et à mesure, tout au long du livre. Ici, nous allons nous intéresser plus particulièrement au choix et à l'installation d'un logiciel de gestion de versions, avec comme objectif la promotion du développement coopératif.

Vocabulaire de la gestion de versions

Ce livre ne vous enseignera pas l'emploi de la gestion de versions si vous ne l'avez pas déjà expérimenté auparavant, cependant il serait impossible de parler de ce sujet sans quelques termes clés. Ces termes sont utiles, indépendamment de tout système de gestion de versions : ce sont les noms et verbes de base de la collaboration en réseau, et ils seront employés de manière générique tout au long de ce livre. Même s'il n'existait aucun système de gestion de versions, le problème de gestion des modifications serait quand même présent, et ces mots nous fournissent un langage pour parler de ce problème de manière concise.

Commit

Apporter une modification au projet, ou, plus formellement, enregistrer un changement dans la base de données de gestion de versions, pour qu'il puisse être ajouté dans une version futures du projet. « Commit » peut être utilisé comme un verbe ou un nom. En tant que nom, il est surtout synonyme de « modification ». Par exemple : « Je viens juste d'enregistrer un correctif pour le bogue de crash de serveur que les gens ont rapporté sur Mac OS X. Jay, pourrais-tu, s'il te plaît, vérifier le commit, et t'assurer que je ne me trompe pas au sujet de l'allocation ? »

Messages enregistrés

Quelques commentaires joints à chaque commit, décrivant la nature et le but du commit. Les messages enregistrés font parti des documents les plus importants d'un projet : ils font le lien entre le langage très technique des modifications du code et le langage plus compréhensible qui se rapporte aux fonctionnalités, aux corrections de bogues et à la progression du projet. Par la suite, dans cette section, nous étudierons comment distribuer les messages enregistrés au bon public, de plus, la section nommée « Codifier la tradition » dans le Chapitre 6, Communication, aborde les manières d'encourager les participants à écrire des messages enregistrés concis et utiles.

Mise à jour

Demander que les autres modifications (commit) soient incorporées dans votre propre version du projet, c'est à dire, mettre votre copie à jour. C'est une opération de routine, la plupart des développeurs mettent à jour leur code plusieurs fois par jour. Ainsi, ils savent qu'ils utilisent sensiblement la même chose que les autres. En conséquence, s'ils détectent un bogue, il y a peu de chance qu'il ait déjà été corrigé. Par exemple : « Salut, j'ai remarqué que le code d'indexation oublie toujours le dernier nombre. Est-ce un nouveau bogue ? » « Oui, mais il a été réparé la semaine dernière, fais une mise à jour, il devrait disparaître. »

Dépôt

Une base de données au sein de laquelle les modifications sont stockées. Certains logiciels de gestion de versions sont centralisés : il y a un unique dépôt maître qui conserve toutes les modifications du projet. D'autres sont décentralisés : chaque développeur possède son propre dépôt et les modifications peuvent être partagées entre les dépôts de manière arbitraire. Le logiciel de gestion de versions conserve un suivi des dépendances entre les modifications. Au moment de la publication d'une nouvelle version, un ensemble particulier de modifications est approuvé pour la sortie. Quant à savoir quel système est le meilleur, centralisé ou décentralisé... Cette question est l'une des vieilles guerres du développement de logiciel, essayez de ne pas vous laisser entraîner dans ce débat sur l'une des listes du projet.

Retrait

L'obtention d'une copie du projet depuis le dépôt. Un retrait produit en général une arborescence de répertoires appelée « copie de travail » (voir ci-dessous), à partir de laquelle des changements peuvent être intégrés au dépôt originel. Pour certains logiciels décentralisés de gestion de versions, chaque copie de travail est, elle même, un dépôt, et les modifications peuvent être envoyées (ou aspirées) vers les dépôts les acceptant.

Copie de travail

L'arborescence personnelle d'un développeur contient les fichiers du code source du projet, et peut également contenir pages Web et autres documents. Une copie de travail contient également quelques méta-données prises en charge par le logiciel de gestion de version, indiquant à la copie de travail de quel dépôt elle provient, quelles « révisions » (voir ci-dessous) des fichiers sont présentes, etc. Généralement, chaque développeur possède sa propre copie de travail dans laquelle il réalise et teste les modifications, et à partir de laquelle il commit.

Révision, Modification et Ensemble de modifications

Une « révision » est en général une incarnation précise d'un fichier ou dossier particulier. Par exemple, si le projet commence avec la révision 6 du fichier F et qu'ensuite quelqu'un modifie F on parlera alors de la révision 7 de F. Certains systèmes parlent aussi de « révision », « modification » ou « ensemble de modifications » pour se référer à un ensemble de modifications ajoutées en même temps comme une unité conceptuelle.

Ces termes ont parfois une signification technique distincte selon le logiciel de gestion de versions, mais l'idée générale est toujours la même : ils fournissent un moyen de parler sans ambiguïté d'un point précis dans l'histoire d'un fichier ou d'un ensemble de fichier (par exemple : immédiatement avant ou après la correction d'un bogue). Par exemple : « Ah oui, elle a corrigé cela dans la révision 10 » ou « Elle a corrigé cela dans la révision 10 de foo.c. »

Quand quelqu'un parle d'un fichier ou d'un ensemble de fichiers sans préciser de révision particulière, on comprend généralement qu'il s'agit de la révision la plus récente.

Diff

La représentation textuelle d'une modification. Un diff montre quelles lignes ont été modifiées et comment, en ajoutant quelques lignes de contexte d'un côté ou de l'autre. Pour un développeur déjà familier avec le code, la lecture d'un diff et du code suffisent, en général, à comprendre l'impact des modifications, voire même à détecter des bogues.

Mot-clé

Une étiquette pour un ensemble de fichiers donnés à une révision donnée. Les mots-clés sont en général utilisés pour résumer les idées majeures du projet. Par exemple, un mot-clé est généralement utilisé pour chaque sortie publique afin qu'on puisse obtenir, directement depuis le logiciel de gestion de versions, l'ensemble exact des fichiers/révisions compris dans cette version. Des mots-clés courants sont Release-1-0, Delivery_00456, etc.

Branche

Une copie du projet, sous gestion de versions mais isolée, afin que les modifications de cette branche n'affectent pas le reste du projet (et vice versa) , sauf quand les modifications sont « fusionnées » volontairement dans un sens ou l'autre (voir plus bas). Les branches sont aussi connues sous le nom de « lignes de développement ». Même dans un projet n'ayant pas explicitement de branches, on considère toujours que le développement s'effectue sur la « branche principale », également connue sous le nom de « ligne principale » ou « tronc ».

Les branches offrent la possibilité d'isoler différentes lignes de développement les unes des autres. Par exemple, une branche peut être employée pour faire du développement expérimental qui serait trop déstabilisant pour le tronc principal. Ou, à l'inverse, une branche peut être utilisée pour stabiliser une nouvelle version. Au cours du processus de sortie, le développement normal continue sans interruption dans la branche principale du dépôt, tandis que dans la branche de sortie aucun changement n'est accepté, sauf ceux approuvés par les responsables de la parution. Ainsi, la conception de la nouvelle version n'interfère pas avec le travail de développement en cours. Voir la section « Utilisez les branches pour éviter les embouteillages », plus loin dans ce chapitre pour une discussion plus détaillée à propos des branches.

Fusion (ou port)

Transférer une modification d'une branche à une autre. Cela englobe la fusion du tronc principal vers d'autres branches et inversement. En fait, ce sont les types de fusion les plus courants, il est rare de porter une modification entre deux branches secondaires. Voir la section appelée « Unicité de l'information » pour en savoir plus sur ce type de fusion.

« Fusion » a un deuxième sens proche : c'est ce que fait le logiciel de gestion de versions quand il voit que deux personnes ont modifié le même fichier à des endroits différents. Puisque les deux modifications n'interfèrent pas entre elles, quand l'une des personnes met à jour sa copie du fichier (contenant déjà ses propres changements), les modifications de l'autre personne seront automatiquement fusionnées. C'est très courant, particulièrement dans les projets où plusieurs personnes travaillent sur le même code. Quand deux modifications différentes se chevauchent il en résulte un « conflit », voir ci-dessous.

Conflit

C'est ce qui se passe quand deux personnes tentent de faire des changements au même endroit du code. Tous les systèmes de gestion de version détectent automatiquement les conflits, et avertissent au moins l'un des humains responsable de ces modifications conflictuelles. C'est alors à l'humain de régler le conflit, et d'envoyer la résolution au logiciel de gestion de version.

Verrouiller

Une manière de se réserver les modifications sur un fichier ou un dossier particulier. Par exemple : « Je ne peux pas envoyer de modifications des pages Web en ce moment. Il semblerait qu'Alfred les ait verrouillées pendant qu'il modifie leur image de fond. » Tous les systèmes de gestion de version ne permettent pas ceci, et ceux qui l'autorisent n'imposent pas l'utilisation de cette fonctionnalité.

On dit que les systèmes de gestion de version, imposant le verrouillage avant d'enregistrer des modifications, utilisent le modèle verrouillage-modification-déverrouillage. Ceux qui ne le font pas utilisent le modèle dit de copie-modification-fusion. Vous trouverez à l'adresse http://svnbook.red-bean.com/svnbook-1.0/ch02s02.html une excellente explication détaillée et une comparaison de ces deux modèles. En général, le modèle copie-modification-fusion est plus adapté au développement Open Source, et tous les logiciels de gestion de versions abordés dans ce livre prennent en charge ce modèle.

Choisir un logiciel de gestion de versions

Au moment de l'écriture de ces lignes, le logiciel de gestion de versions libre le plus populaire est le Concurrent Versions System ou CVS (http://www.cvshome.org/). Il y a longtemps maintenant qu'existe CVS. La plupart des développeurs expérimentés y sont déjà familiers, il fait plus ou moins ce que vous voulez, et puisque c'est le choix par défaut, il n'y aura guère de longs débats sur la validité de votre choix. CVS possède, cependant, quelques inconvénients. Il ne propose pas de manière simple de se référer à des modifications de plusieurs fichiers, il ne vous permet pas de renommer ou de copier des fichiers sous gestion de versions (et donc si vous avez besoin de réorganiser l'arbre de votre code après avoir lancé le projet, cela peut être très pénible), les possibilités de fusion laissent à désirer, il ne gère pas très bien les fichiers volumineux ou les fichiers binaires, et certaines opérations sont lentes quand elles concernent un grand nombre de fichiers.

Aucun de ces défauts n'étant rédhibitoire, il reste plutôt populaire. Cependant, depuis quelques années, Subversion, plus récent, gagne en popularité, particulièrement auprès des nouveau projets [15]. Si vous démarrez un nouveau projet, je vous conseille d'opter pour Subversion.

Mais d'un autre côté, étant impliqué dans le développement de Subversion, on peut raisonnablement mettre en doute mon objectivité. De plus, au court des dernières années, de nouveaux logiciels de gestion de versions ont fait leur apparition. L'Annexe A, « Logiciels de gestion de versions libres » dresse une liste de tous ceux que je connais. Comme cette liste le montre clairement, le choix d'un logiciel de gestion de versions peut facilement devenir une quête sans fin. Il se peut que cette décision vous soit épargnée parce qu'elle sera prise par votre hébergeur. Mais si vous devez choisir, consulter vos développeurs, demandez leur avec quel système ils ont l'habitude de travailler, puis, choisissez en un et utilisez le. N'importe quel logiciel de gestion de version stable et opérationnel fera l'affaire, votre choix n'est pas irréversible. Si vous n'arrivez pas à vous décider, choisissez alors CVS. Toujours le standard, il le restera certainement encore pour des années. De plus, de nombreux systèmes supportent la conversion depuis CVS, vous pourrez donc toujours changer d'avis ensuite.

Utilisation du logiciel de gestion de versions

Les recommandations, dans cette partie, ne se concentrent pas sur un logiciel de gestion de versions particulier : elles devraient être simples à mettre en œuvre dans n'importe lequel d'entre eux. Référez vous à la documentation de votre système pour plus de détails.

Tout versionner

Non seulement vous devez garder le code source de votre projet sous gestion de versions, mais aussi : ses pages Web, la documentation, la FAQ et tout ce que les gens pourraient éditer. Conservez les proches du code source, dans le même arbre de dépôt. Ce qui est suffisamment important pour être écrit l'est aussi pour être « versionné », ce qui englobe donc toute information modifiable. Les objets invariables devraient être archivés, et non pas « versionnés ». Par exemple, un e-mail une fois envoyé ne change pas, donc le « versionner » est inutile (à moins qu'il fasse partie d'un plus grand document en constante évolution).

Il est important de tout « versionner » ensemble au même endroit afin que les gens n'aient à apprendre qu'un seul mécanisme pour envoyer des changements. Il arrive souvent qu'un contributeur débute en modifiant des pages Web ou de la documentation, puis plus tard, se met à apporter de petites contributions au code. Si le mécanisme est le même pour toutes les contributions, les participants ne doivent l'apprendre qu'une seule fois. Tout « versionner » ensemble permet aussi d'accompagner les nouvelles fonctionnalités d'une mise-à-jour de la documentation correspondantes, et implique aussi qu'une création de branche du code créera également une branche dans la documentation, etc.

Ne gardez pas les fichiers générés sous gestion de version. Ce ne sont pas vraiment des données éditables puisqu'elles ont été produites automatiquement à partir d'autres fichiers. Par exemple, certains systèmes de construction créent des configurations basées sur le modèle configure.in. Pour modifier la configuration, on devra alors éditer configure.in puis régénérer, en conséquence, seul le modèle configure.in est un « fichier éditable ». Ne « versionnez » que le modèle, si vous « versionnez » le fichier résultant également, les gens oublieront inévitablement de le régénérer au moment de l'application d'une modification au modèle, et les incompatibilités causeront des confusions sans fin. [16]

Il existe cependant une exception malheureuse à cette règle du « versionnage » de tout fichier éditable : le système de suivi de bogues. La base de données de bogues contient un grand nombre de données éditables, mais, pour des raisons techniques, ne peut pas ranger ces données dans le logiciel de gestion de version principal (certains systèmes de suivi possèdent leur propre système de « versionnement » primitif, mais il est indépendant du dépôt principal du projet).

Navigabilité

Le dépôt du projet devrait être navigable sur le Web. Ce qui veut dire que vous devez fournir à vos visiteurs, non seulement la possibilité de voir les dernières révisions des fichiers du projet, mais aussi la possibilité de remonter le temps et voir les révisions précédentes, les différences entre les révisions, lire les messages enregistrés pour certaines modifications, etc.

La navigabilité est importante : c'est le portail qui donne accès aux données du projet. Si le dépôt ne peut pas être vu grâce à un navigateur, et que quelqu'un veut voir un fichier particulier (pour voir si un certain correctif de bogue a été intégré par exemple), il devra d'abord installer le logiciel de gestion de versions localement, transformant de fait sa petite recherche de deux minutes en une tâche d'une demi heure.

Des URL pour accéder aux révisions spécifiques des fichiers et voir les dernières révisions, à tout moment, sont indispensables à une bonne navigabilité. Cela peut-être très utile au cours de discussions techniques ou lorsqu'on oriente les gens vers la documentation. Par exemple, plutôt que de dire « Pour des conseils en vue de déboguer le serveur voir le fichier www/hacking.html dans votre copie de travail » on pourra dire « Pour des conseils en vue de déboguer le serveur voir http://svn.collab.net/repos/svn/trunk/www/hacking.html », donnant ainsi une URL qui renvoie toujours vers la dernière révision du fichier hacking.html. Il vaut mieux donner l'URL car, ainsi, vous levez toute ambiguïté, et la personne se réfère à la toute dernière version du document.

Certains systèmes de gestion de versions possèdent leurs propres mécanismes de navigation de dépôt intégrés, alors que d'autres s'appuient sur des programmes tiers. Trois de ces outils sont ViewCVS (http://viewcvs.sourceforge.net/), CVSWeb (http://www.freebsd.org/projects/cvsWeb.html) et WebSVN (http://Websvn.tigris.org/). Le premier est compatible avec CVS et Subversion, le deuxième avec CVS seulement, et le troisième avec Subversion seulement.

E-mails de commit

Chaque ajout au dépôt devrait générer un e-mail précisant l'auteur des modifications, quels fichiers et dossiers ont été affectés,de quelle manière et quand. L'e-mail devrait être envoyé à une liste de diffusion spécialement faite pour les e-mails de commit, bien distincte des listes de diffusion où ce sont des humains qui écrivent. Les développeurs et toutes les personnes intéressées devraient être encouragés à souscrire à cette liste de diffusion car c'est le moyen le plus efficace de suivre ce qui se passe dans le projet au niveau du code. En plus des avantages techniques évidents en matière de vérification par les collègues (voir la section « Effectuez une inspection visible du code »), les e-mails de commit participent au développement du sentiment de communauté parce qu'ils établissent un environnement partagé dans lequel les gens peuvent réagir à des évènements (les commits) qu'ils savent visibles de tous.

Selon votre logiciel de gestion de versions, la mise en place d'e-mails de commit sera différente, mais, en général, il existe un script ou d'autres outils sous forme de paquets pour le faire. Si vous avez du mal à le trouver, essayez de chercher de la documentation sur les mécanismes, en particulier sur les mécanismes post-commit, aussi appelés mécanismes loginfo dans CVS. Les mécanismes post-commit permettent d'automatiser certaines tâches en réponse à un commit. Le mécanisme,déclenché par un commit, engrange toutes les informations à propos de ce commit : il est ensuite libre d'utiliser ces informations pour réaliser de nombreuses tâches, comme par exemple envoyer un e-mail.

Avec un système d'e-mail de commit prêt à l'emploi, vous pouvez toujours modifier certaines options par défaut :

1. Certains systèmes d'envoi d'e-mail de commit n'incluent pas les diffs dans les e-mails, mais proposent, à la place, une URL pour voir les changements sur le Web en utilisant le système de navigation du dépôt. Même s'il est acceptable de donner une URL, on peut ainsi se référer à la dernière modification, il est aussi très important que l'e-mail de commit comprenne les diffs complets. La lecture de l'e-mail fait déjà partie de la routine des gens, donc si le contenu de la modification est visible directement dans l'e-mail de commit, les développeurs peuvent l'examiner instantanément, sans sortir de leur messagerie. La plupart ne feront pas l'effort de cliquer sur un lien pour examiner quelque chose parce que cela implique une nouvelle action interrompant la continuité de leurs activités en cours. De plus, si cette personne veut poser une question à propos de la modification, il est nettement plus simple d'appuyer sur le bouton « Répondre », et d'annoter simplement le diff cité, que de se rendre sur le site Web et copier/coller laborieusement des parties du diff, du navigateur Web vers votre messagerie.

(Évidemment, si le diff est très gros, par exemple, au moment de l'ajoût d'un gros morceau de nouveau code au dépôt, il paraît plus normal de ne pas inclure le diff et de mettre un lien. La plupart des systèmes d'envoi d'e-mail de commit peuvent appliquer ce genre de limitations automatiquement. Si le votre ne le permet pas, il vaut mieux inclure les diffs tout le temps, et se faire aux occasionnels mails énormes, plutôt que d'abandonner définitivement les diffs. Le développement coopératif repose sur l'aisance à modifier et commenter, c'est bien trop important pour s'en passer.)

2. Par défaut, l'option « Répondre à » pour les e-mails de commit devrait renvoyer à la liste de développement normale, pas à la liste d'e-mails de commit. Dans la pratique, quand quelqu'un examine un commit et écrit une réponse, celle-ci devrait être automatiquement envoyée à la liste de développeurs, là où les problèmes techniques sont normalement débattus. Voici quelques raisons pour appuyer ce choix. En premier lieu, il vaut mieux regrouper toutes les discussions techniques sur une même liste, parce que c'est là que les gens s'attendent à les voir, mais aussi, parce que c'est une manière de n'avoir qu'une seule archive à interroger en cas de recherche. En deuxième lieu, il se peut que des gens intéressés ne soient pas inscrits à la liste d'e-mails de commit. Ensuite, la liste de commit se présente comme un service de suivi des commits, pas pour suivre les commits et d'occasionnelles discussions techniques. Ceux qui se sont inscrits sur la liste d'e-mails de commit ne se sont pas abonnés à autre chose qu'un liste d'e-mails de commit, en leur envoyant d'autres informations par le biais de cette liste, vous dénaturez un contrat tacite. Enfin, les gens écrivent souvent des programmes qui lisent les listes d'e-mails de commit, et qui traitent les résultats (pour les afficher sur une page Web par exemple). Ces programmes sont fait pour gérer des e-mails de commit automatiquement générés, pas des e-mails rédigés à la main.

Remarquez que ces conseils sur le « Répondre à » ne sont pas en contradiction avec les recommandations abordées précédemment dans la section « Le grand débat du Répondre à » . Il est préférable que l'expéditeur d'un message remplisse la case « Répondre à ». Ici, l'expéditeur est le logiciel de gestion de version lui même, lequel configure le « Répondre à » afin d'indiquer que l'endroit approprié pour répondre est la liste de diffusion de développement, pas la liste de commit.

Utilisez les branches pour éviter les embouteillages

Les utilisateurs non-expert en gestion de versions ont parfois un peu peur de créer des branches et d'en fusionner. C'est certainement l'un des effets secondaire de la popularité de CVS : l'interface de CVS pour créer des branches, et les fusionner, est en quelque sorte contre-intuitive, beaucoup ont donc appris à éviter complètement ces opérations.

Si vous faites parti de ces personnes, il est urgent de vaincre cette peur et d'apprendre la création et la fusion de branches. Ces opérations ne sont pas difficiles une fois maitrisées, or elles prennent de plus en plus d'importance à mesure que de nouveaux développeurs se joignent au projet.

Les branches sont importantes parce qu'elles transforment une ressource rare, l'espace pour travailler dans le code du projet, en une ressource abondante. Normalement, tous les développeurs travaillent ensemble, dans le même bac à sable, à construire le même château de sable. Quand quelqu'un veut ajouter un nouveau pont-levis, mais qu'il n'arrive pas à convaincre tout le monde de l'une amélioration potentielle, créer une branche lui permet de travailler dans son coin et de faire des essais. Si ses efforts sont couronnés de succès, il peut inviter les autres développeurs à examiner son travail. Si tout le monde s'accorde à dire que le résultat est bon, il est possible de dire au logiciel de gestion de version de déplacer (« fusionner ») le pont-levis du château image vers le château principal.

Cette liberté supplémentaire est évidemment essentielle dans le cadre du développement collaboratif. Les gens ont besoin de liberté pour essayer de nouvelles choses sans avoir peur d'interférer avec le travail des autres. De même, le code a parfois besoin d'être isolé de l'agitation du développement régulier pour que les développeurs puissent corriger un bogue ou stabiliser une version sans avoir l'impression de viser une cible en mouvement perpétuel (voir la section « Stabiliser une version » et la section « Maintenir plusieurs lignes de sortie » dans le Chapitre 7, Paquets, sorties et développement quotidien).

Utilisez les branches librement et encouragez les autres à en faire de même. Mais assurez vous aussi qu'une branche donnée n'est active que pour le temps nécessaire, pas plus. Chaque branche active dilue l'attention de la communauté. Même ceux qui ne travaillent pas sur la branche gardent toujours un œil dessus pour savoir ce qu'il s'y passe. Une telle attention est bonne, bien sûr, et les e-mails de commit devraient être envoyés pour un commit dans une branche comme pour n'importe quel autre commit. Mais les branches ne devraient pas devenir un mécanisme qui disperse la communauté de développeurs. À de rares exceptions près, le destin d'une branche est d'être fusionnée à la ligne principale et de disparaître.

Unicité de l'information

De la possibilité de fusion découle un corollaire important : n'enregistrez jamais deux fois la même modification. Un changement donné ne devrait intégrer le logiciel de gestion de versions qu'une seule fois. À ce moment, la révision (ou l'ensemble de révisions), par laquelle la modification est entrée, est son unique identificateur. S'il doit être appliqué à d'autres branches (que celle par laquelle il est entré), il devrait être fusionné aux autres destinations à partir de son point d'entrée d'origine, plutôt que d'être enregistré comme un changement parfaitement identique. L'effet sur le code est le même, mais le suivi ou la gestion de cette modification deviendraient impossible.

Concrètement, les implications sont différentes d'un logiciel de gestion de versions à l'autre. Dans certains systèmes, les fusions sont des évènements spéciaux, fondamentalement distincts des commits, et sont identifiés par leurs propres méta-données. Dans d'autres, les résultats des fusions sont enregistrés de la même manière que les modifications, donc la première manière de distinguer un « commit fusionné » d'un « commit pour une nouvelle modification » est d'inspecter les messages enregistrés. Lors d'une fusion, le message enregistré ne doit pas répéter le message enregistré du changement d'origine. Indiquez simplement que c'est une fusion, et donnez l'identifiant de la révision du changement d'origine, avec, tout au plus, une phrase résumant les effets . Si quelqu'un désire voir le message enregistré en entier, il devrait consulter l'original.

Il est important d'éviter de répéter les messages enregistrés parce qu'ils peuvent être édités après avoir été enregistrés. Si un message enregistré est répété dans chaque cible de la fusion, et que le message d'origine est modifié les copies ne le sont pas, ce qui ne peut que mener à des incohérences.

Il en va de même pour l'annulation d'un changement. Si une modification est retirée du code, alors le message enregistré pour ce retour en arrière devrait simplement annoncer que cette (ces) révision(s) particulière(s) est (sont) retirée(s), pas décrire le changement de code entraîné puisque ces informations peuvent être déduites de la lecture du message enregistré original. Évidemment, le message enregistré pour ce retour en arrière devrait également dire pourquoi ce changement a été retiré, mais il ne devrait rien copier du message enregistré originel. Si possible, éditez le message enregistré d'origine pour établir clairement qu'il a été retiré.

Toutes ces instructions impliquent que vous devriez utiliser une syntaxe cohérente lorsque vous vous référez à des révisions. Vous en verrez les bienfaits non seulement pour les messages enregistrés, mais aussi dans les e-mails, le système de suivi de bogues, etc. Si vous utilisez CVS, je vous conseille « path/to/file/in/project/tree:REV », ou REV est un numéro de révision dans CVS, comme par exemple « 1.76 ». Si vous utilisez Subversion, la syntaxe standard pour la révision 1729 est « r1729 » (le chemin d'accès n'est pas indispensable puisque Subversion utilise des numéros de révision généraux). Les autres systèmes emploient, en général, une syntaxe standard pour exprimer le nom de l'ensemble de modifications. Quelque soit la syntaxe appropriée à votre système, encouragez les gens à l'utiliser lorsqu'ils parlent des modifications. La cohérence dans l'expression des noms des modifications permet un suivi du projet plus aisé (comme nous le verrons dans le Chapitre 6, Communication et le Chapitre 7, Paquets, sorties et développement quotidien), étant donné qu'une grande partie de ce suivi sera faite par des volontaires, il doit être aussi simple que possible.

Voir aussi la section « Sorties et développement quotidien » dans le Chapitre 7, Paquets, sorties et développement quotidien.

Autorisation

La plupart des logiciels de gestion de versions proposent une option permettant d'offrir aux participants le droit d'enregistrer des modifications dans des domaines précis du dépôt. En suivant le principe qu'avec un marteau en main, on se met à chercher des clous, nombreux sont les projets utilisant cette fonctionnalité sans réserve en accordant ces droits d'accès aux seuls domaines où il est autorisé d'enregistrer des modifications, tout en s'assurant qu'il est impossible de le faire nulle part ailleurs (voir la section « Committers » dans le Chapitre 8, Encadrer les volontaires pour savoir comment les projets attribuent ces droits).

Si un contrôle strict ne gênera personne, des règles plus souples conviendront aussi. Certains projets fonctionnent avec un système d'honneur : quand on accorde l'accès de commit à une personne, même pour une sous-partie du dépôt, celle-ci reçoit en fait un mot de passe lui permettant d'enregistrer des modifications n'importe où dans le projet. Il lui est juste demandé de se limiter à ce domaine. Le risque n'est pas très grand, tous les commits sont examinés de toute façon. Si quelqu'un enregistre quelque chose qu'il n'était pas censé faire, d'autres le remarqueront et le signaleront. Tout est sous gestion de versions de toute façon, si une modification doit être retirée il vous suffit simplement de l'annuler.

L'approche plus souple possède quelques avantages. D'abord les développeurs s'ouvrent à d'autres domaines (ce qu'ils feront de toute façon s'ils s'impliquent durablement dans le projet), leur accorder des privilèges étendus ne demande pas plus de travail administratif. Une fois que la décision est prise, la personne peut commencer à enregistrer des modifications dans le nouveau domaine immédiatement.

Ensuite, l'ouverture peut être faite de manière plus progressive. En général, un committer dans le domaine X qui voudrait s'ouvrir au domaine Y commencera par envoyer des correctifs pour Y en demandant à ce qu'ils soient examinés. Si quelqu'un ayant déjà l'accès de commit dans le domaine Y voit ce correctif, et l'approuve, il peut simplement demander au requérant de l'enregistrer directement (en mentionnant évidemment le nom de l'examinateur/celui qui approuve dans le message enregistré ). Ainsi, le commit proviendra de la personne qui a effectivement fait la modification, ce qui est préférable à la fois du point de vue de la gestion de l'information et de celui de la reconnaissance.

Dernier point, et non des moindres, l'utilisation du système d'honneur encourage une atmosphère de confiance et de respect mutuel. Obtenir l'accès de commit à un sous-domaine est la reconnaissance de compétences techniques, cela signifie : « Nous remarquons que tu as les compétences pour faire des commits dans un certain domaine, nous te donnons le feu vert ». Mais en imposant un contrôle strict sur les autorisations vous dites : « Non seulement nous pensons que tes compétences ont des limites, mais nous sommes en plus suspicieux quant à tes intentions. » Ce n'est pas une déclaration que vous feriez si vous pouviez l'éviter. Donner l'accès de commit à quelqu'un, pour le faire entrer dans le projet, est une chance de lui ouvrir l'accès à un cercle de confiance mutuelle. Accorder plus de pouvoirs aux committers qu'ils ne sont censés avoir, et, leur dire ensuite que c'est à eux de respecter leurs limites est une bonne manière de procéder.

Le projet Subversion a adopté le système d'honneur depuis plus de quatre ans maintenant, avec 33 committers non-restreints et 43 committers aux droits restreints au moment où j'écris ces lignes. Le système ne distingue que ces deux catégories : ceux qui ont les droits de committers et ceux qui ne les ont pas, les sous-divisions plus précises ne sont établies que par les humains. Pourtant, jamais personne n'a dépassé les limites de son domaine. Une ou deux fois nous avons eu une légère incompréhension au niveau de l'étendue des privilèges de commit, mais ce problème a toujours été réglé rapidement et calmement.

Évidemment, dans les rares situations où l'autogestion est impraticable, vous devrez vous fier à un contrôle plus strict des autorisations. Cependant, devant des millions de lignes de code et des centaines ou des milliers de développeurs, un commit, pour n'importe quelle partie du code, devrait toujours être vérifié par ceux travaillant sur cette partie : ils pourront juger si quelqu'un a enregistré une modification alors qu'il n'aurait pas dû. Si une vérification régulière des commits n'est pas effectuée, le problème du système d'autorisation devrait être le cadet des soucis du projet.

Pour résumer, ne perdez pas trop de temps avec les autorisations du logiciel de gestion de versions, à moins que vous n'ayez des raisons particulières de le faire. Cela n'apporte en général pas d'amélioration tangible, et ne vous dispense pas des contrôles humains.

Il ne faut pas comprendre ici que les restrictions en elles-mêmes ne sont pas importantes bien sûr. Il serait dommageable pour le projet d'encourager les gens à enregistrer des modifications dans les parties où ils n'ont pas les compétences requises. De plus, dans de nombreux projets, un accès de commit non restreint possède un statut particulier : il va de pair avec le droit de vote sur les questions concernant le projet dans sa globalité. Cet aspect politique de l'accès de commit est discuté dans la section « Qui vote ? » du Chapitre 4, Infrastructure sociale et politique.

Suivi de bogues

Vaste sujet que le suivi de bogues: au travers de ce livre, nous en abordons différents aspects. Ici, je me concentrerai principalement sur l'installation et les considérations techniques, mais, avant d'aborder ces points, nous devons répondre à une question : quel genre d'informations doivent être exactement conservées dans le système de suivi de bogues ?

Le terme suivi de bogue est trompeur. Les systèmes de suivi de bogues sont aussi souvent utilisés pour les demandes de nouvelles fonctionnalités, des tâches ponctuelles, des correctifs non-sollicités : vraiment tout ce qui peut avoir un état initial et final différent, avec des états de transitions optionnels, et qui accumule des informations au cours de son existence. Pour cette raison, les systèmes de suivi de bogues sont également appelés systèmes de suivi de problèmes, suivi de défauts, suivi des artéfacts, suivi de requêtes, file d'attente des problèmes, etc. Voir l'Annexe B, Systèmes de suivi de bogues libres pour une liste de logiciels.

Dans ce livre je continuerai à utiliser « système de suivi de bogues » pour désigner le logiciel qui s'occupe du suivi, parce que c'est ainsi que les gens l'appellent, mais je parlerai de problème pour désigner un objet particulier dans la base de données du système de suivi de bogues. Cela nous permet de faire la distinction entre le comportement, ou le mauvais comportement, auquel l'utilisateur à fait face (c'est à dire, le bogue en lui-même) et l'historique de découverte de bogues du système, du diagnostic et de la résolution finale. N'oubliez pas que, bien que la plupart des problèmes se rapportent à de vrais bogues, les problèmes peuvent être utilisés pour suivre d'autres types de tâches aussi.

Le cycle de vie classique d'un problème ressemble à cela :

1. Quelqu'un enregistre le problème. Il fournit un résumé, une description basique (en incluant la recette pour reproduire le bogue si elle existe, voir la section nommée « Considérez tous les utilisateurs comme des volontaires potentiels » dans le Chapitre 8, Encadrer les volontaires pour savoir comment encourager les rapports de bogue), et tout autre information demandée par le système de suivi. La personne enregistrant le problème peut être complètement étrangère aux rapports de bogues du projet, et les requêtes de fonctionnalités pourront aussi bien provenir de la communauté d'utilisateurs que des développeurs.

Une fois enregistré, le problème est dans ce qu'on appelle un état ouvert. Parce qu'aucune action n'a encore été prise, certains systèmes le classent dans non vérifié et/ou non commencé. Il n'est assigné à personne, ou, dans certains systèmes, il est assigné à un utilisateur factice pour montrer qu'il n'est pas concrètement assigné. À partir de là, il est dans une zone d'attente : le problème a été enregistré, mais pas encore intégré à la conscience du projet.

2. D'autres lisent le problème, y ajoutent des commentaires et, si besoin est, demandent des clarifications, sur certains points, à celui qui a créé l'entrée.

3. Le bogue est reproduit. C'est peut-être le moment le plus important dans son cycle de vie. Même si le bogue n'est pas encore corrigé, le fait que quelqu'un d'autre que l'auteur de l'entrée ait été capable de le reproduire, prouve son existence, et confirme à l'auteur qu'il a contribué au projet en rapportant un vrai bogue, ce qui est tout aussi important.

4. Le bogue est diagnostiqué : ses causes sont identifiées et, si possible, l'effort requit pour le corriger est estimé. Assurez vous que tout ceci soit enregistré dans le problème, si la personne qui a fait le diagnostic du bogue doit soudainement quitter le projet pour un certain temps (comme cela arrive souvent avec les développeurs volontaires), quelqu'un d'autre pourra continuer le travail sur les bases de ce qui avait été fait.

À cette étape, ou parfois dans les précédentes, un développeur peut « prendre possession » du problème, et se l'assigner (la section nommée « Distinguer clairement requête et assignation » dans le Chapitre 8, Encadrer les volontaires, éclaire plus en détails le processus d'assignation). La priorité du problème peut aussi être décidée à cette étape. Par exemple, un problème grave, au point de retarder la prochaine sortie, doit être identifié tôt, et le suivi devrait fournir un moyen de le noter.

5. Un calendrier est prévu pour la résolution du problème. Prévoir ne signifie par nécessairement donner une date à laquelle le problème sera corrigé. Parfois, c'est simplement qu'il a été décidé dans quelle future version (par forcément la prochaine) le bogue devrait être corrigé, ou qu'on a décidé qu'il n'était pas nécessaire de se fixer une version particulière. On peut se passer d'une prévision, si le bogue peut être corrigé rapidement.

6. Le bogue est corrigé (ou la tâche accomplie ou le correctif appliqué, peu importe). La modification, ou l'ensemble des modifications, qui l'a corrigé, devrait être enregistrée dans un commentaire du problème, après quoi le problème est clos et/ou marqué comme résolu.

Ce cycle connait des variantes classiques. Il arrive qu'un incident soit clos très rapidement après avoir été enregistré, parce qu'il s'avère que ce n'est pas un bogue du tout, mais plutôt une mauvaise compréhension de la part de l'utilisateur. Ce genre de faux positif est de plus en plus fréquent à mesure qu'un projet fédère plus d'utilisateurs, et les développeurs les fermeront avec de moins en moins de tact. Essayez de contenir cette tendance. Cela n'apporte rien à personne, un utilisateur particulier n'est pas responsable des mauvais rapports précédents, seul les développeurs sont témoins de cette augmentation, pas les utilisateurs (dans la section nommée « Filtrer le système de suivi de bogues en amont » plus loin dans ce chapitre nous aborderons les techniques pour réduire le nombre de rapports non valides). Il faut voir également que, si plusieurs utilisateurs expriment sans arrêt la même incompréhension, il pourrait être bon de repenser cette partie du logiciel. Ce genre de répétition est détectée plus aisément si un responsable incident surveille la base de données de bogues, voir la section appelée « Responsable incidents » dans le Chapitre 8, Encadrer les volontaires.

Souvent un incident sera identifié comme étant un doublon, et sera clos peu après la première étape, c'est une autre variante fréquente du cycle de vie d'un incident. Un doublon est un incident enregistré par quelqu'un alors qu'il est déjà connu du projet. Les doublons ne sont pas confinés aux incidents ouverts : il est possible qu'un bogue revienne après avoir été corrigé (on appelle cela une régression), dans ce cas, la voie choisie est en général de ré-ouvrir l'incident d'origine, et de fermer tout nouveau rapport doublon du premier. Le système de suivi de bogue devrait garder en mémoire les relations dans les deux sens, afin que les informations de reproduction dans les duplicatas soient disponibles dans l'incident originel et vice versa.

Une troisième variation peut se produire quand les développeurs ferment l'incident, pensant avoir réglé le problème, dans le seul but que le rapporteur original rejette finalement la correction, et le présente à nouveau. C'est, en général, parce que les développeurs n'ont simplement pas accès aux ressources nécessaires pour reproduire le bogue, ou, parce qu'ils n'ont pas testé le correctif en employant la même recette de reproduction que le rapporteur. En plus de ces variations, d'autres petits détails du cycle de vie peuvent changer selon le logiciel de suivi. Mais de manière générale, c'est toujours pareil, et même si le cycle de vie n'est pas particulier aux logiciels Open Source, il a des implications sur l'usage que font les projets Open Source de leur système de suivi de bogues.

Comme l'étape 1 le laisse penser, le système de suivi est, au même titre que les listes de diffusion et les pages Web, la face visible du projet. N'importe qui peut rapporter un problème, n'importe qui peut jeter un œil à un incident, et n'importe qui peut parcourir la liste des incidents actuellement ouverts. Vous ne savez jamais, par conséquent, combien de personnes guettent les améliorations d'un problème particulier. Alors que la taille, et les compétences, de la communauté de développement détermine la vitesse de résolution des problèmes, le projet devrait, au minimum, tenter de reconnaître les incidents à mesure qu'ils apparaissent. Même si le problème dure un moment, une réponse encourage le rapporteur à rester engagé car il voit qu'un être humain a enregistré ce qu'il a fait (souvenez vous que rapporter un problème demande en général plus d'effort que, par exemple, envoyer un e-mail). De plus, une fois un problème repéré par un développeur, le projet en prend conscience, dans le sens où le développeur peut guetter d'autres exemples, peut en parler aux autres développeurs, etc.

Les réponses rapides sont possibles à deux conditions :

• Le système de suivi doit être lié à une liste de diffusion afin que chaque changement apporté à un incident, y compris sa création, envoie un mail décrivant les modifications. Cette liste de diffusion est en général distincte des listes de développement habituelles puisque tous les développeurs ne veulent pas forcément recevoir des mails de bogues automatisés, mais (tout comme les mails de commit) le bandeau « Répondre à » devrait renvoyer vers la liste de développement.
• Le fichier d'envoi d'incident devrait inclure l'adresse e-mail du rapporteur afin qu'il puisse être contacté pour demander plus d'informations (cependant, l'adresse e-mail ne devrait pas être obligatoire : certaines personnes préfèrent rapporter les bogues anonymement. Voir la section nommée « Anonymat et engagement » plus loin dans ce chapitre pour plus de détails sur l'importance de l'anonymat).

Interaction avec les listes de diffusion

Faites en sorte que le système de suivi de bogues ne se transforme pas en un forum de discussion. Il est important de garder une présence humaine dans le système de suivi, il n'est pas exactement fait pour mener des discussions en temps réel. Essayez de le voir plutôt comme un archiveur, une façon d'organiser les faits et les références à d'autres discussions, principalement celles développées dans les listes de discussions.

Cette distinction est importante pour deux raisons. En premier lieu, le système de suivi de bogues est moins commode à utiliser que les listes de diffusion (ou que les salons de discussion en temps réel d'ailleurs). Ce n'est pas parce que les systèmes de suivi ont une interface mal conçue, c'est simplement que leur interface a été conçue pour capturer et présenter des états discrets, pas des discussions continues. En second lieu, tous ceux devant être impliqués dans la discussion d'un problème particulier ne suivent pas forcément le système de suivi. Une bonne gestion des incidents demande que chaque problème soit porté à l'attention des bonnes personnes, il ne s'agit pas de demander à tous les développeurs de suivre tous les problèmes (voir la section appelée « Partager les tâches de gestion aussi bien que les tâches techniques » dans le Chapitre 8, Encadrer les volontaires). Dans la section « Pas de conversations dans le système de suivi de bogues » dans le Chapitre 6, Communication nous étudierons la manière de s'assurer que les gens ne détournent pas accidentellement les discussions hors du bon forum vers le système de suivi.

Certains systèmes de suivi de bogues peuvent surveiller les listes de diffusions, et enregistrer tous les e-mails se rapportant à un problème connu. Ils font en général cela en reconnaissant le numéro d'identification des incidents dans la sujet du mail, au sein d'un « string »* particulier, les développeurs apprennent à inclure ces « strings » dans les e-mails pour attirer l'attention du système. Le système de suivi peut soit sauvegarder l'e-mail entier soit simplement enregistrer un lien vers l'e-mail dans l'archive habituelle de la liste de diffusion (cette solution est meilleure). Dans tous les cas, c'est une fonctionnalité très utile, si votre système la propose assurez vous de l'activer et de rappeler aux gens de s'en servir.

Filtrer le système de suivi de bogues en amont

La plupart des bases de données d'incidents souffrent au final du même problème : un nombre écrasant de doublons, ou d'incidents invalides, enregistrés par des utilisateurs bien intentionnés mais inexpérimentés ou mal informés. La première chose à faire, pour combattre cette tendance, est en général, de mettre une note d'information bien en vue sur la première page du système de suivi indiquant comment différencier un bogue de ce qui ne l'est pas, comment faire des recherches pour savoir s'il n'a pas déjà été enregistré et, finalement, comment en rapporter un de manière efficace si l'on pense toujours avoir affaire à un nouveau bogue.

Cela devrait vous donner un peu de répit, mais, avec l'augmentation du nombre d'utilisateurs, le problème finira par revenir. Individuellement, aucun utilisateur n'est responsable. Chacun essaie simplement de contribuer au bien-être du projet, même si leur premier rapport de bogue n'est pas d'une grande aide, vous devez quand même les encourager à rester impliqué, et à mieux s'y prendre dans le futur. Parallèlement pourtant, le projet a besoin de garder une base de données d'incidents aussi propre que possible.

Les deux choses qui vous aideront le plus à prévenir ce problème sont : votre équipe, chargée de la surveillance du système de suivi de bogues, doit posséder les connaissances pour fermer les incidents invalides, ou les doublons, au fur et à mesure de leur arrivée. Il faut, de plus, imposer (ou encourager fortement) aux utilisateurs la confirmation de leurs bogues par une tierce personne avant l'enregistrement.

La première technique semble être largement répandue. Même les projets avec des bases de données énormes (par exemple, le système de suivi de bogues du projet Debian à l'adresse http://bugs.debian.org/ qui contient 315 929 incidents au moment de l'écriture) parviennent à faire vérifier chaque incident à son enregistrement. Plusieurs personnes peuvent assurer ce rôle selon le type d'incident. Par exemple, le projet Debian est un ensemble de paquets logiciels, donc Debian redirige automatiquement l'incident vers ceux en charge du paquet. Évidemment, les utilisateurs peuvent parfois se tromper de catégorie quand ils enregistrent un bogue, l'incident sera donc envoyé en premier à la mauvaise personne, laquelle devra alors à son tour le rediriger. Malgré tout, l'important ici est que la charge de travail soit bien partagée (que l'utilisateur ait vu juste ou pas au moment de l'enregistrement), la surveillance des incidents est toujours répartie plus ou moins équitablement entre les développeurs, ainsi chaque problème peut recevoir une réponse rapide.

La deuxième technique est moins répandue, sûrement parce qu'elle est plus difficile à automatiser. L'idée essentielle est que chaque nouvel incident doit être « parrainé » pour entrer dans la base de données. Quand un utilisateur pense avoir découvert un problème, on lui demande de le décrire dans une des listes de diffusion, ou dans un canal IRC, afin d'obtenir la confirmation de bogue de la part d'un tiers. Faire entrer ce second avis rapidement, peut vous éviter beaucoup de faux rapports. Parfois, la deuxième personne est capable de dire si ce comportement est un bogue ou pas, ou s'il a été corrigé dans une version plus récente. Il peut aussi bien connaître les symptômes d'un bogue précédent, et ainsi, éviter un doublon en dirigeant l'utilisateur vers l'incident précédent. Il suffit souvent de simplement demander à l'utilisateur « As-tu fait une recherche dans le système de suivi de bogues pour voir s'il n'a pas déjà été rapporté ? ». Nombreux sont ceux qui n'y pensent pas, et qui feront de bon cœur cette recherche une fois appris ce que l'on attend de leur part.

Le système de parrainage peut être très efficace pour maintenir en ordre la base de données, mais il a ses inconvénients également. De nombreuses personnes continueront à faire des rapports dans leur coin, par dédain pour les instructions permettant de trouver un parrain pour les nouveaux incidents, ou, parce qu'ils ne les auront pas vues. De plus, la plupart des nouveaux rapporteurs n'imaginent pas les efforts nécessaires pour maintenir une base de données d'incidents propre, il est donc injuste de les réprimander trop durement pour avoir ignoré les directives. Voilà pourquoi les volontaires doivent à la fois être vigilants et se montrer souples quand ils renvoient un incident non parrainé à son rapporteur. Le but est d'entraîner chaque rapporteur à utiliser le système de parrainage dans le futur, afin que le nombre de personnes comprenant le système de filtres des incidents augmente. Quand vous découvrez un incident non parrainé voici les étapes d'une réaction idéale :

1. Répondez immédiatement au problème, remerciez poliment l'utilisateur pour sa contribution, mais dirigez le vers les règles de parrainage (qui devraient évidemment être bien en évidence sur le site Web).

2. Si l'incident est valide et n'est pas un doublon, approuvez-le malgré tout, et lancez-le sur son cycle de vie normal. Après tout la personne ayant fait le rapport est maintenant au courant du parrainage, il n'y a donc pas de raison de perdre le travail accompli en fermant un rapport valide.

3. Autrement, si la validité du rapport n'est pas évidente, fermez-le, mais demandez au rapporteur de le rouvrir s'il obtient la confirmation d'un parrain. Quand il l'obtient, il devrait mettre une référence au sujet où il a obtenu confirmation (c'est à dire, une URL des archives de la liste de diffusion).

Ne pas oublier que ce système améliorera, avec le temps, le rapport signal/bruit dans la base de données des incidents, mais qu'il ne fera pas complètement disparaître les mauvais rapports. Ce n'est qu'en empêchant à tous, exceptés les développeurs, l'accès au système de suivi de bogues que vous les ferez disparaître intégralement : un remède bien souvent pire que le mal. Mieux vaut accepter que la résolution de problèmes tangents fera toujours partie de l'entretien routinier du projet, et essayer d'obtenir autant d'aide extérieure que possible. Voir aussi la section appelée « Responsable incident » dans le Chapitre 8, Encadrer les volontaires.

IRC et les chats en temps réel

De nombreux projets proposent des salons de discussion en temps réel par le biais d'IRC (Internet Relay Chat), ou encore de forums où utilisateurs et développeurs peuvent poser des questions et recevoir des réponses rapidement. N'hébergez pas de serveur IRC sur votre propre site Web, même si vous en avez la possibilité, ça n'en vaut pas la peine en général. Faites plutôt comme tout le monde : héberger votre canal IRC chez Freenode (http://freenode.net). Freenode vous donne le contrôle nécessaire pour administrer les canaux IRC de votre projet [17], tout en vous déchargeant de l'entretien assez conséquent d'un serveur IRC.

La première chose à faire est de choisir un nom de canal. Le choix le plus évident est le nom de votre projet, s'il est disponible chez Freenode, utilisez le. Si ce n'est pas le cas, essayez de choisir quelque chose d'aussi proche du nom du projet et facile à retenir que possible. Mettez en avant l'existence du canal sur le site Web de votre projet, ainsi un visiteur ayant une petite question le verra tout de suite. Par exemple, voici le message dans un cadre bien en vue en haut de la page de Subversion.

Si vous utilisez Subversion, nous vous recommandons de rejoindre la liste de diffusion users@subversion.tigris.org et de lire Subversion Book ainsi que la FAQ. Vous pouvez également poser vos questions sur IRC à irc.freenode.net canal #svn.

Certains projets utilisent plusieurs canaux, un par sous-sujet. Par exemple, un canal pour les problèmes d'installation, un autre pour les questions relatives à l'utilisation, un autre pour discuter du développement, etc. (la partie appelée « Gérer la croissance » dans le Chapitre 6, Communication aborde cette division en plusieurs canaux). Tant que votre projet est jeune, il ne devrait y avoir qu'un seul canal où tout le monde parle ensemble. Plus tard, quand le rapport utilisateur/développeur augmente, créer des canaux séparés pourra devenir nécessaire.

Comment connaître tous les canaux disponibles et savoir où poser les questions ? Et s'ils s'expriment, comment connaîtront-ils les règles en vigueur ?

Il faut le leur dire en créant un message d'accueil [18]. Le message d'accueil est un bref message vu par tous les utilisateurs en entrant dans un canal. Il indique brièvement les règles aux nouveaux venus et fournit des liens pour en apprendre davantage. Par exemple :

Vous discutez maintenant dans #svn

Le sujet de #svn est Forum concernant les questions des utilisateurs de Subversion,
voir également http://subversion.tigris.org/. || Les discussions relatives au 
développement se font dans #svn-dev. || S'il vous plait, n'y collez pas vos 
transcriptions, utilisez plutôt un site comme pastebin : http://pastebin.ca ||
NOUVEAUTÉS : Subversion 1.1.0 est terminé, voir http://svn110.notlong.com pour en savoir plus.

C'est succinct, mais un nouvel arrivant y apprend tout ce qu'il doit savoir. On connait le rôle exact du canal, l'adresse du site du projet (au cas où quelqu'un s'égare sur le canal, sans être d'abord passé par le site du projet), les autres canaux sont mentionnés et l'utilisateur y découvre les consignes à propos du collage (pasting).

Robots

Beaucoup de canaux IRC orientés technique possèdent un membre non-humain, appelé robot, capable d'enregistrer et de régurgiter des informations en réponse à des commandes particulières. On s'adresse au robot comme habituellement à n'importe quel autre membre du canal, c'est à dire que les commandes sont déclenchées en « parlant » au robot. Par exemple :

<kfogel> ayita: apprend diff-cmd = http://subversion.tigris.org/faq.html#diff-cmd
<ayita> Merci ! 

Cela indique au robot (qui participe au canal sous le nom de ayita) de se souvenir d'une certaine URL en réponse à la requête « diff-cmd ». Maintenant on peut commander ayita et demander au robot de donner des informations à un autre utilisateur à propos de la commande diff-cmd :

<kfogel> ayita : parle à a.nonyme de diff-cmd
<ayita> a.nonyme : http://subversion.tigris.org/faq.html#diff-cmd

La même chose peut-être accomplie via un raccourci pratique :

<kfogel> !a a.nonyme diff-cmd
<ayita> a.nonyme : http://subversion.tigris.org/faq.html#diff-cmd

L'ensemble des commandes exactes et des comportements diffèrent d'un robot à l'autre. L'exemple donné ci-dessus est celui d'ayita (http://hix.nu/svn-public/alexis/trunk/), lequel tourne généralement sur #svn chez freenode. On peut également citer Dancer (http://dancer.sourceforge.net/) et Supybot (http://supybot.com/). Sachez qu'aucun privilège sur le serveur n'est nécessaire pour utiliser un robot. Un robot est un programme client, n'importe qui peut en installer un, et le configurer pour qu'il suive un serveur ou un canal particulier.

Si vous retrouvez sans arrêt les mêmes questions sur votre canal, je vous recommande vivement d'installer un robot. Seul un faible pourcentage des utilisateurs de votre canal acquerront les compétences requises pour manipuler le bot, mais ceux-là pourront répondre à bien plus de questions grâce à l'efficacité du robot.

Archiver les conversations

Bien qu'il soit possible d'archiver tout ce qu'il se passe dans un canal IRC, on n'attend pas de vous, en général, que vous le fassiez. Les conversations IRC ont beau être publiques, beaucoup de gens les voient comme des conversations informelles semi-privées. Les utilisateurs ne prêteront pas forcément attention à la grammaire, et feront souvent part de leur opinion (à propos par exemple d'autres logiciels ou d'autres programmeurs), ils ne veulent pas forcément que tout cela soit conservé ad vitam æternam dans une archive en ligne.

Bien sûr, il y aura des cas de figure où des citations devraient être préservées, ce qui est normal. La plupart des clients IRC peuvent enregistrer une conversation dans un fichier à la demande de l'utilisateur, et, si ce n'est pas le cas, on peut simplement copier/coller une conversation IRC sur un forum permanent (le plus souvent dans le système de suivi de bogues). Mais un enregistrement hasardeux peut mettre certains utilisateurs mal à l'aise. Si vous archivez tout, assurez vous de l'annoncez clairement dans l'introduction du canal, et donnez le lien vers les archives.

Les flux RSS

RSS (Really Simple Syndication) est un mécanisme permettant de distribuer des résumés de nouvelles aux « abonnés », c'est à dire aux personnes qui ont manifesté le désir de recevoir ces résumés. Une source RSS donnée est, généralement, appelée un flux, et les abonnés y ont accès par ce qu'on appelle un lecteur de flux ou un agrégateur de flux. RSS Bandit ou le logiciel éponyme FeedReader [NdT : lecteur de flux] sont deux exemples de lecteurs de flux Open Source.

Nous n'avons pas ici la place pour une explication technique détaillée du fonctionnement des flux RSS [19], mais il y a deux choses que vous devriez savoir. En premier lieu, c'est l'abonné qui choisit son lecteur de flux, et c'est le même pour tous les flux suivis par l'abonné. En fait, c'est un des principaux argument des lecteurs de flux RSS : l'abonné choisit une interface pour lire tous ses flux, chaque flux pouvant se concentrer uniquement sur la distribution de contenu. En deuxième lieu, les flux RSS sont maintenant omniprésents, à tel point que la majorité des utilisateurs ne savent même pas qu'ils les utilisent. Pour monsieur Toutlemonde, RSS est un petit bouton sur une page Web avec une petite ligne annonçant « s'abonner à ce site » ou « Flux de nouvelles ». Il suffit d'appuyer sur ce bouton pour que votre lecteur de flux (parfois intégré à votre page d'accueil) se mette automatiquement à jour quand le site publie une nouvelle.

Tout ça pour dire que les projets Open Source devraient proposer un flux RSS (les forges en général le font automatiquement, voir la section « Forges »). Prenez toutefois garde à ne pas publier trop de nouvelles quotidiennement afin que vos abonnés puissent séparer le bon grain de l'ivraie. Si les mises à jour sont trop fréquentes, les gens finiront simplement par ignorer le flux ou se désabonner. L'idéal pour un projet est de proposer des flux distincts. Un pour les annonces importantes, un autre qui suivrait, par exemple, les évènements du suivi de bogues, un autre pour chaque liste de diffusion, etc. En pratique, ça n'est pas si simple à mettre en place correctement : les visiteurs du site du projet comme les administrateurs pourraient être un peu perdus. Mais le projet devrait fournir a minima un flux RSS pour la page d'accueil du site, afin d'envoyer les annonces importantes telles que sorties et alertes de sécurité [20].

Les wikis

Un wiki est un site Web permettant à quiconque d'en éditer ou d'en enrichir le contenu, le terme "wiki" (qui provient de l'hawaïen "rapide" ou "super vite") sert aussi à désigner les logiciels autorisant de telles modifications. Les wikis ont été inventés en 1995, mais leur popularité n'a vraiment décollée que depuis 2000 ou 2001, entraînée en partie par le succès de Wikipédia (http://www.wikipedia.org/), une encyclopédie libre basée sur un wiki. Le wiki se situe à mi-chemin entre une page Web et un canal IRC : les wikis n'évoluent pas en temps réel, les utilisateurs peuvent donc peser leurs mots et travailler leurs contributions, mais étant également vraiment très facile à éditer, on s'affranchit de toute la partie interface liée à une page Web classique.

Les wikis ne sont pas encore des outils courants pour les projets Open Source, mais ils le deviendront sans doute bientôt. Cette technologie étant relativement nouvelle, et les gens explorant encore différentes utilisations possibles, je ne vous donnerai ici que quelques mises en garde : il est plus simple, actuellement, d'analyser leur mauvais usages que leur succès.

Si vous décidez d'utiliser un wiki, concentrez vos efforts sur la mise en page, afin qu'elle soit claire et visuellement attirante pour que les visiteurs (c'est-à-dire les éditeurs potentiels) sachent instinctivement comment y intégrer leurs contributions. De même, postez ces standards sur le wiki lui-même, afin que les gens aient un guide auquel se référer. Ne croyez pas naïvement comme tant d'administrateurs de wiki que la somme de contributions individuelles de qualité sera automatiquement de qualité. Les sites Web ne fonctionnent pas ainsi. Chaque écrit individuel, ou paragraphe, considéré séparément peut être bon, mais ne le sera pas noyé dans un tout désorganisé et confus. Trop souvent les wikis souffrent de :

• Manque de principes de navigation. Grâce à un site bien organisé, les visiteurs ne se sentent jamais perdus. Si les pages sont bien conçues, par exemple, les lecteurs feront intuitivement la différence entre une zone « sommaire » et une zone « contenu ». Ceux qui participent au wiki respecteront ces différences également, mais seulement si elles sont présentes dès le départ.
• Doublons. Des pages au contenu semblable apparaitront immanquablement parce que les participants isolés n'avaient pas forcément remarqué le doublon. Ceci peut être, en partie, dû au manque de principes de navigation cités précédemment. Les contributeurs peuvent, en effet, ne pas trouver le doublon s'il ne se trouve pas là où ils l'attendent.
• L'incohérence du public visé. Ce problème est inévitable quand il y a trop d'auteurs, mais il peut être atténué si vous proposez des indications pour la création de contenu nouveau. Il peut, aussi, être utile d'éditer fermement les nouvelles contributions au départ, pour montrer l'exemple, afin que les normes commencent à s'imposer.

La solution commune à tous ces problèmes est la même : vous devez avoir des règles éditoriales et en faire la démonstration, non seulement en les affichant, mais aussi en les appliquant lors de l'édition de pages. En général, les wikis amplifient les défauts des exemples de base puisque les participants imitent les modèles donnés. Vous ne pouvez pas vous contenter de mettre en place le wiki en espérant que tout s'arrange tout seul. Vous devez aussi l'amorcer avec du contenu bien rédigé afin que les rédacteurs aient un modèle à suivre.

Un très bon exemple de wiki bien géré est Wikipédia, il faut dire aussi que le contenu (des entrées encyclopédiques) se prête naturellement au format wiki. Mais si vous examinez Wikipédia de plus près, vous remarquerez que ses administrateurs ont posé des bases très solides pour favoriser la coopération. Vous y trouverez une documentation bien détaillée sur l'écriture de nouvelles entrées, la manière de conserver un point de vue neutre, quel genre d'édition effectuer, lesquelles sont à éviter, un processus de résolution des conflits sur les éditions (incluant plusieurs étapes, jusqu'à l'arbitrage final), etc. Les administrateurs possèdent aussi un contrôle d'autorisation, ainsi, si une page est souvent vandalisée, ils peuvent en interdire l'édition jusqu'à la résolution du problème. En d'autres termes, ils ne se sont pas contentés de balancer des modèles sur un site Web en priant. Wikipédia fonctionne car ses fondateurs ont bien réfléchi à la manière d'amener des milliers d'inconnus à modifier leurs contributions selon une vision commune. Sans nécessairement atteindre ce niveau de préparation pour gérer un wiki de projet de logiciel libre, il est bon de s'en inspirer.

Pour de plus amples informations à propos des wikis, voir http://fr.wikipedia.org/wiki/Wiki. De même, le premier wiki reste en vie et en bonne santé et contient de nombreuses discussions sur comment s'occuper d'un wiki : voir http://www.c2.com/cgi/wiki?WelcomeVisitors, http://www.c2.com/cgi/wiki?WhyWikiWorks et http://www.c2.com/cgi/wiki?WhyWikiDoesntWork, vous y trouverez plusieurs points de vue.

Les sites Web

Il y a peu de chose à dire concernant la mise en place du site Web du projet d'un point de vue technique : la mise en page et la rédaction de pages Web est une tâche relativement simple, et la plupart des points importants realtifs à la mise en page ont été abordés dans la chapitre précédent. La principale fonction du site Web est de présenter, de manière claire et accueillante, le projet et de faire le lien entre les outils (le logiciel de gestion de versions, le système de suivi de bogues, etc.). Si vous n'avez pas les connaissances nécessaires à la mise en place d'un serveur Web, il n'est, en général, pas compliqué de trouver quelqu'un sachant le faire qui vous aidera avec plaisir. Néanmoins, pour s'économiser du temps et des efforts, les gens préfèrent souvent utiliser des sites d'hébergement ou forges.

Les forges

L'utilisation de forges possède deux gros avantages. Le premier est la capacité du serveur et la bande passante, ces serveurs sont des grosses boîtes reliées à des tuyaux vraiment bien larges. Peu importe le succès rencontré par votre projet, vous ne risquez pas de faire face à un problème d'espace disque ou de dépasser les limites de votre connexion. Le deuxième avantage est leur simplicité. Ils sont livrés avec un système de suivi de bogues, un logiciel de gestion de versions, un gestionnaire de liste de diffusion, un archiveur et tout ce dont vous avez besoin pour gérer un site. Les outils sont pré-configurés et la sauvegarde des données stockées dans les outils est gérée. Vous n'avez que peu de décisions à prendre. On vous demande simplement de remplir un formulaire, d'appuyer sur un bouton, et voilà, vous avez le site de votre projet.

Ce sont des avantages plutôt appréciables. L'inconvénient, bien sûr, reste que vous devez accepter leurs choix et leurs configurations, même si une autre solution serait mieux adaptée à votre projet. En général, les sites tout compris peuvent être quelque peu paramétrés, mais vous n'aurez jamais un contrôle aussi précis que si vous mettiez en place le site vous même en ayant un accès complet à l'administration du serveur.

Un très bon exemple de ceci est la gestion des fichiers générés. Certaines pages de projets peuvent être des fichiers générés, il existe des systèmes pour garder les FAQ dans un format maître facilement éditable, à partir duquel des fichiers HTML, PDF (ou encore d'autres formats) peuvent être générés. Comme déjà détaillé dans la section appelée « Tout versionner » précédemment dans ce chapitre, il n'est pas souhaitable de versionner les formats générés, seulement le fichier maître. Mais quand votre site Web est hébergé sur le serveur d'une autre personne, il peut se révéler impossible de mettre en place un système régénérant la version HTML en ligne de la FAQ dès que le fichier maître est modifié. La seule solution est de versionner également les formats générés afin qu'ils apparaissent sur le site Web.

Les conséquences peuvent être des plus importantes. Vous pourriez ne pas avoir autant de contrôle que souhaité sur la présentation. Certaines de ces forges vous permettent de personnaliser vos pages Web, mais la configuration par défaut du site finit habituellement par apparaître maladroite. Par exemple, certains projets qui s'hébergent eux-mêmes sur SourceForge ont des pages complètement personnalisées, mais placent toujours des liens vers leur « page chez SourceForge » pour plus d'informations. La page chez SourceForce représente ce qu'aurait été la page du projet, si le projet n'avait pas utilisé une page personnalisée. La page chez SourceForge contient des liens vers le système de suivi de bogues, le dépôt CVS, les téléchargements, etc. Malheureusement, une page chez SourceForge contient également une bonne quantité de contenu étranger. En haut de la page se trouve un bandeau publicitaire, souvent une image animée. À gauche, on voit, listés verticalement, des liens sans intérêt pour ceux intéressés par le projet. Le côté droit est affublé d'une autre publicité. Seul le centre de la page est dédié réellement au projet, mais, même cette partie est ordonnancée de manière confuse, en conséquence, les visiteurs ne sont jamais sûrs de l'endroit où cliquer.

Chaque petit détail du design de SourceForge est bien pensé, bien pensé du point de vue de SourceForge, ainsi les emplacements publicitaires. Mais du point de vue du projet, le résultat peut-être une page loin d'être idéale. Je ne m'en prends pas spécifiquement à SourceForge, les mêmes remarques s'appliquent à de nombreuses forges. Je veux simplement dire que tout n'est pas rose. Vous vous déchargez des tâches techniques de la gestion du site du projet, mais en contrepartie vous sacrifiez votre contrôle total.

Vous êtes le seul à pouvoir décider si les forges représentent le meilleur choix pour votre projet. Si vous choisissez une forge, gardez vous la possibilité de migrer sur vos propres serveurs plus tard, en utilisant, comme adresse du projet, un nom de domaine personnel. Vous pouvez rediriger l'URL vers le site hébergé ou avoir votre page complètement personnalisée sur cette URL publique, et rediriger les utilisateurs vers la forge pour les fonctionnalités plus sophistiquées. Assurez vous simplement de faire en sorte que, si vous optez pour une autre solution d'hébergement par la suite, l'adresse du projet n'ait pas besoin de changer.

Choisir un hébergeur

Le plus important et le mieux connu des sites d'hébergement est SourceForge. Deux autres sites proposent des services identiques ou similaires : savannah.gnu.org et BerliOS.de. Quelques organisations, comme l'Apache Software Foundation et Tigris.org [21], offrent un hébergement aux projets qui s'inscrivent dans leur mission et leur communauté de projets existants. Haggen So a effectué une évaluation minutieuse de différentes forges, au cours de ses recherches pour sa thèse de doctorat, Construction of an Evaluation Model for Free/Open Source Project Hosting (FOSPhost) sites [NdT : Construction d'un modèle d'évaluation des sites d'hébergement de projets libres/Open Source] Les résultats se trouvent sur la page http://www.ibiblio.org/fosphost/, je vous renvoie particulièrement à son graphique comparatif très clair : http://www.ibiblio.org/fosphost/exhost.htm.

Anonymat et engagement

Un problème qui n'est pas spécifique aux forges, mais que l'on y retrouve souvent, est le détournement des fonctionnalités d'identification. La fonctionnalité en elle-même est très simple : le site permet à chaque visiteur de s'enregistrer grâce à un nom d'utilisateur et un mot de passe. À partir de ce moment, il conserve un profil pour cet utilisateur, et les administrateurs du projet peuvent lui attribuer certaines permissions, par exemple, le droit de faire des ajouts au dépôt.

Cela peut-être très utile et c'est d'ailleurs l'un des principaux avantages des forges. Le problème étant que l'identifiant de l'utilisateur est requis pour des tâches qui devraient être permises aux visiteurs non enregistrés, en particulier pour ajouter un rapport dans le système de suivi de bogues ou pour commenter des problèmes existants. En demandant un nom d'utilisateur à l'enregistrement en vu de telles actions, le projet demande plus d'engagement pour des tâches se devant d'être rapides et aisées. Évidemment, on voudrait pouvoir contacter une personne ayant entré des données dans le système de suivi de bogues, mais il suffit d'avoir un champ où entrer son adresse e-mail (s'il le désire). Si un nouvel utilisateur détecte un bogue et veut le rapporter, devoir remplir un formulaire pour se créer un compte avant de pouvoir entrer le bogue dans le système de suivi ne peut que le décourager. Il pourrait simplement décider, finalement, de ne pas rapporter le bogue.

Les avantages de la gestion des utilisateurs compensent généralement ces inconvénients. Cependant, s'il est possible de choisir les actions pouvant être effectuées anonymement, assurez vous que, non seulement, les visiteurs non-enregistrés ont l'accès aux ressources en lecture seule, mais aussi, la possibilité d'entrer des données, en particulier dans le système de suivi de bogues et, si vous en avez un, dans le wiki.

Notes

[12] Tiré de son livre, Le Mythe du mois-homme, 1975. Voir http://fr.wikipedia.org/wiki/Le_Mythe_du_mois-homme et http://fr.wikipedia.org/wiki/Loi_de_Brooks.

[13] Peu après la publication de ce livre, Michael Bernstein m'a écrit pour m'informer que « Mutt n'est pas le seul logiciel de messagerie à proposer la fonction « Répondre à la liste ». Par exemple Evolution le propose grâce à un raccourci clavier, mais pas avec un bouton (Ctrl+L). »

[14] Depuis la rédaction de ce paragraphe, j'ai appris qu'il existe au moins un système de gestion de liste qui propose cette fonction : Siesta. Je vous encourage à lire cet article pour en savoir plus : http://www.perl.com/pub/a/2004/02/05/siesta.html.

[15] Voir http://cia.vc/stats/vcs et http://subversion.tigris.org/svn-dav-securityspace-survey.html, vous y trouverez des preuves de cette croissance.

[16] Alexey Makhotkin propose une vision différente du problème du versionnement des fichiers de configuration dans son message « configure.in et contrôle de version » consultable à l'adresse http://versioncontrolblog.com/2007/01/08/configurein-and-version-control/.

[17] Vous n'êtes pas obligé de faire un don à Freenode, mais, si votre projet peut se le permettre, je vous invite à réfléchir à un don. C'est déductible d'impôts.

[18] Pour configurer un message d'accueil utilisez la commande /topic. Toutes les commandes dans IRC commencent par « / ». Si vous souhaitez en apprendre plus sur l'utilisation d'IRC et son administration, lisez la page http://www.irchelp.org/. http://www.irchelp.org/irchelp/irctutorial.html en particulier est un très bon tutoriel.

[19] Voir http://www.xml.com/pub/a/2002/12/18/dive-into-xml.html à ce propos.

[20] Il faut rendre à César ce qui appartient à César : cette section n'apparaissait pas dans la version originale du livre, mais l'article sur le blog de Brian Aker « Release Criteria, Open Source, Thoughts On... » m'a rappelé l'importance des flux RSS pour les projets Open Source.

[21] Avertissement : je suis employé par CollabNet qui finance Tigris.org, et j'utilise Tigris régulièrement.

---

Chapitre 2 : Bien démarrer

Page d'accueil du projet

Chapitre 4 : Infrastructure sociale et politique