POSSFR Chap 6

De Framalang Wiki.

(Différences entre les versions)

(L'effet « minorité bruyante »)
Ligne 192 : Ligne 192 :
Toute personne qui a été membre d'un groupe de décision reconnaîtra ce dont parle Kamp. Cependant, il est généralement impossible de convaincre tout le monde d'éviter de peindre l'abri à vélos. La meilleure chose que vous puissiez faire est de signaler le phénomène quand il se produit et convaincre les développeurs expérimentés, ceux dont les messages ont le plus de poids, de déposer leurs pinceaux avant les autres pour qu'eux au moins ne renforcent pas le bruit. Les manifestations pour-la-peinture-de-l'abri-à-vélo ne disparaîtront jamais complètement mais on peut les rendre plus brèves et moins fréquentes en instillant la prise de conscience du phénomène dans la culture du projet.
Toute personne qui a été membre d'un groupe de décision reconnaîtra ce dont parle Kamp. Cependant, il est généralement impossible de convaincre tout le monde d'éviter de peindre l'abri à vélos. La meilleure chose que vous puissiez faire est de signaler le phénomène quand il se produit et convaincre les développeurs expérimentés, ceux dont les messages ont le plus de poids, de déposer leurs pinceaux avant les autres pour qu'eux au moins ne renforcent pas le bruit. Les manifestations pour-la-peinture-de-l'abri-à-vélo ne disparaîtront jamais complètement mais on peut les rendre plus brèves et moins fréquentes en instillant la prise de conscience du phénomène dans la culture du projet.
 +
=== Éviter les trolls ===
=== Éviter les trolls ===
Ligne 198 : Ligne 199 :
Une fois que le troll est lâché il ne pourra pas être remis en cage sans que certains ne se sentent lésés. C'est inutile de déclarer en plein milieu d'un troll qu'il s'agit d'un troll. Tout le monde le sait déjà.  
Une fois que le troll est lâché il ne pourra pas être remis en cage sans que certains ne se sentent lésés. C'est inutile de déclarer en plein milieu d'un troll qu'il s'agit d'un troll. Tout le monde le sait déjà.  
-
Malheureusement une caractéristique des trolls est la divergence d'opinion sur le règlement du conflit, la discussion peut-elle aboutir ? Vu de l'extérieur, il apparaît clairement qu'aucun des camps n'est en mesure de faire changer l'autre d'avis. Vu de l'intérieur, la partie adverse est obtuse et n'a pas les idées claires, mais on peut en avoir raison à force d'intimidation. Attention : je ne dis pas qu'il n'y a pas de cause juste dans un troll. Parfois il y en a une, dans les trolls auxquelles j'ai participé c'était toujours la mienne évidemment. Mais peu importe, car il n'y a pas d'algorithme qui permette de démontrer de manière convaincante que l'une partie a raison et l'autre tort.
+
Malheureusement une caractéristique des trolls est la divergence d'opinion sur le règlement du conflit, la discussion peut-elle aboutir ? De l'extérieur, il apparaît clairement qu'aucun des camps n'est en mesure de faire changer l'autre d'avis. De l'intérieur, la partie adverse est obtuse et n'a pas les idées claires, mais on peut en avoir raison à force d'intimidation. Attention : je ne dis pas qu'il n'y a pas de cause juste dans un troll. Parfois il y en a une, dans les trolls auxquelles j'ai participé c'était toujours la mienne évidemment. Mais peu importe, car il n'y a pas d'algorithme qui permette de démontrer de manière convaincante qu'un camp a raison et l'autre tort.
-
Souvent, pour achever un troll, quelqu'un dira : « Nous avons déjà perdu trop de temps et d'énergie à discuter ! Vous voulez pas juste laisser tomber ? », mais ce n'est pas une approche satisfaisante. Il y a deux problèmes ici. D'abord, le temps et l'énergie perdus ne pourront plus être rattrapés, la question maintenant est de savoir : quel effort reste-t-il à faire ? Si certains pensent que continuer la discussion un peu plus amènera à la résolution du conflit, alors cela vaut encore la peine (de leur point de vue) de poursuivre.
+
Souvent, pour achever un troll, quelqu'un dira : « Nous avons déjà perdu trop de temps et d'énergie à discuter ! Vous voulez pas juste laisser tomber ? », mais ce n'est pas la bonne manière de faire. Il y a deux problèmes ici. D'abord, le temps et l'énergie perdus ne pourront plus être rattrapés, la question maintenant est de savoir l'effort qu'il reste à faire. Si certains pensent que poursuivre un peu la discussion amènera à la résolution du conflit, alors cela vaut encore la peine (de leur point de vue) de poursuivre.
L'autre problème quand on demande aux gens de laisser tomber c'est que cela équivaut souvent à permettre à l'une des parties, celle du statu quo, de se déclarer vainqueur par forfait. Et dans certains cas, le statu quo n'est pas acceptable : tout le monde est d'accord, il faut prendre des décisions et agir dans un sens ou dans l'autre. Il vaut mieux poursuivre l'argumentation plutôt que d'abandonner le sujet. Mais comme le dilemme s'applique à tous de la même manière il est aussi possible que la discussion continue éternellement.
L'autre problème quand on demande aux gens de laisser tomber c'est que cela équivaut souvent à permettre à l'une des parties, celle du statu quo, de se déclarer vainqueur par forfait. Et dans certains cas, le statu quo n'est pas acceptable : tout le monde est d'accord, il faut prendre des décisions et agir dans un sens ou dans l'autre. Il vaut mieux poursuivre l'argumentation plutôt que d'abandonner le sujet. Mais comme le dilemme s'applique à tous de la même manière il est aussi possible que la discussion continue éternellement.
Ligne 208 : Ligne 209 :
Voici un début de réponse : faites en sorte qu'ils ne soient pas libérés. Ce n'est pas aussi irréalisable qu'il n'y parait.
Voici un début de réponse : faites en sorte qu'ils ne soient pas libérés. Ce n'est pas aussi irréalisable qu'il n'y parait.
-
Vous pouvez anticiper certains trolls classiques : ils surgissent quand il est question de langages de programmation, de licences (voir la section intitulée « La GPL et la compatibilité de licence » du [[POSSFR_Chap_9|Chapitre 9, Licences, droits d'auteurs et brevets]]), de déguisement des adresses e-mail (voir la section  « Le grand débat du Répondre à » du [[POSSFR_Chap_3|Chapitre 3, Infrastructure technique]]) et encore de quelques autres sujets. Chaque projet a également un ou deux trolls qui lui sont propres, avec lesquelles les développeurs de longue date se familiariseront rapidement. Les techniques pour stopper les trolls ou pour en limiter les dégâts sont à peu près les mêmes partout. Même si vous êtes certain que votre camp a raison, essayez de trouver un moyen de montrer votre compréhension et votre sympathie quand l'autre camp marque des points. Souvent dans les sujets à troll chaque camp a construit des murs si haut et a tellement claironné que l'opinion adverse est pure folie que le fait de céder ou de changer d'avis devient psychologiquement insoutenable : cela reviendrait à reconnaître non seulement que l'on a tort, mais que l'on a eu tort tout en étant sûr de soi. En montrant précisément que vous comprenez les arguments de la partie adverse et que vous les trouvez sensés, même s'ils ne vous convainquent pas entièrement, vous rendrez cet aveu acceptable par l'autre camp. Faites un geste qui en appelle un autre en retour et la situation s'améliorera. Si cela ne modifie pas vos chances d'obtenir le résultat technique souhaité, au moins vous pouvez éviter des dommages collatéraux portant atteinte au moral du projet.  
+
Vous pouvez anticiper certains trolls classiques : ils surgissent quand il est question de langages de programmation, de licences (voir la section intitulée « La GPL et la compatibilité de licence » du [[POSSFR_Chap_9|Chapitre 9, Licences, droits d'auteurs et brevets]]), de déguisement des adresses e-mail (voir la section  « Le grand débat du Répondre à » du [[POSSFR_Chap_3|Chapitre 3, Infrastructure technique]]) et encore de quelques autres sujets. Chaque projet a également un ou deux trolls qui lui sont propres, avec lesquelles les développeurs ayant de l'ancienneté se familiariseront rapidement. Les techniques pour stopper les trolls ou pour en limiter les dégâts sont à peu près les mêmes partout. Même si vous êtes certain que votre camp a raison, essayez de trouver un moyen de montrer votre ouverture et votre sympathie quand l'autre camp marque des points. Souvent dans les sujets à troll chaque camp a construit des murs si haut et a tellement claironné que l'opinion adverse est pure folie que le fait de céder ou de changer d'avis devient psychologiquement insoutenable : cela reviendrait à reconnaître non seulement que l'on a tort, mais que l'on a eu tort tout en étant sûr de soi. En montrant précisément que vous comprenez les arguments de la partie adverse et que vous les trouvez sensés, même s'ils ne vous convainquent pas entièrement, vous rendrez cet aveu acceptable par l'autre camp. Faites un geste qui en appelle un autre en retour et la situation s'améliorera. Même si vos chances d'obtenir le résultat technique souhaité n'en sont pas meilleures pour autant, vous aurez au moins évité des dommages collatéraux portant atteinte au moral du projet.  
Lorsqu'un troll ne peut être évité déterminez rapidement combien vous êtes prêt à sacrifier et soyez disposé à céder publiquement. Ce faisant, vous pouvez dire que vous reculez car la guerre ne vaut pas le coup, mais faites le sans amertume et n'en profitez pas pour tirer une dernière salve sur les arguments du camp opposé. Le renoncement n'est efficace que s'il est fait de bonne grâce.
Lorsqu'un troll ne peut être évité déterminez rapidement combien vous êtes prêt à sacrifier et soyez disposé à céder publiquement. Ce faisant, vous pouvez dire que vous reculez car la guerre ne vaut pas le coup, mais faites le sans amertume et n'en profitez pas pour tirer une dernière salve sur les arguments du camp opposé. Le renoncement n'est efficace que s'il est fait de bonne grâce.
-
Les trolls sur les langages de programmation sont un peu spéciaux car bien qu'ils impliquent souvent un haut degré de technicité, nombreux sont ceux qui se sentent qualifiés pour y prendre part et les enjeux sont importants puisque de l'issue dépendra le langage de l'essentiel du code du projet. Il vaut mieux choisir tôt le langage, en suivant l'avis des développeurs influents de départ, et le défendre pour la bonne raison que c'est celui avec lequel vous êtes tous plus à l'aise et non pas qu'il est meilleur qu'un autre qui aurait pu être utilisé à la place. Ne laissez jamais la conversation dégénérer en une comparaison académique entre langages de programmation (ceci semble se produire plus généralement quand quelqu'un évoque Perl, pour je ne sais quelle raison) ; c'est une impasse dans laquelle vous devez refuser de vous laisser entraîner.
+
Les trolls sur les langages de programmation sont un peu spéciaux car bien qu'ils impliquent souvent un haut degré de technicité, nombreux sont ceux qui se sentent qualifiés pour y prendre part et les enjeux sont importants puisque de l'issue des débats dépendra le langage de l'essentiel du code du projet. Il vaut mieux choisir tôt le langage, en suivant l'avis des développeurs influents de départ et le défendre pour la bonne et simple raison que c'est celui avec lequel vous êtes tous plus à l'aise et non pas qu'il est meilleur qu'un autre qui aurait pu être utilisé à la place. Ne laissez jamais la conversation dégénérer en une comparaison académique entre langages de programmation (ceci semble se produire plus généralement quand quelqu'un évoque Perl, pour je ne sais quelle raison) ; c'est une impasse dans laquelle vous devez refuser de vous laisser entraîner.
Pour plus de références historiques aux trolls, voir http://catb.org/~esr/jargon/html/H/holy-wars.html ainsi que l'article de Danny Cohen qui a rendu ce terme populaire, http://www.ietf.org/rfc/ien/ien137.txt.
Pour plus de références historiques aux trolls, voir http://catb.org/~esr/jargon/html/H/holy-wars.html ainsi que l'article de Danny Cohen qui a rendu ce terme populaire, http://www.ietf.org/rfc/ien/ien137.txt.
Ligne 218 : Ligne 219 :
=== L'effet « minorité bruyante » ===
=== L'effet « minorité bruyante » ===
-
Sur les listes de discussion il est très facile pour une petite minorité de donner l'impression qu'il y a de grandes divergences en noyant la liste par une profusion de longs messages. C'est un peu une technique de pirate, une minorité de blocage, si ce n'est que l'illusion d'un désaccord diffus est encore plus puissante, car elle est disséminée à travers un nombre arbitraire de messages discrets et que la plupart des gens ne se donneront pas la peine de suivre à la trace qui a dit quoi et quand. Ils auront juste l'impression instinctive que le sujet est controversé et attendront que le soufflé retombe.
+
Sur les listes de discussion il est très facile pour une petite minorité de donner l'impression qu'il y a de grandes divergences en noyant la liste sous une avalanche de longs messages. C'est un peu une technique de pirate, une minorité de blocage, si ce n'est que l'illusion d'un désaccord diffus est encore plus puissante, car elle est disséminée à travers un nombre arbitraire de messages discrets et que la plupart des gens ne se donneront pas la peine de suivre à la trace qui a dit quoi et quand. Ils auront juste l'impression instinctive que le sujet est controversé et attendront que le soufflé retombe.
-
La meilleure façon de contrer cet effet est de montrer très clairement, preuves à l'appui, à quel point le groupe en désaccord est petit comparé à tous ceux qui sont d'accord. Pour rendre la disproportion plus évidente vous pourrez sonder en privé ceux qui ont gardé le silence mais que vous supposez en accord avec la majorité. Ne dites rien qui puisse faire croire que les dissidents essayaient de gonfler la portée de leur impact. Ce n'était pas nécessairement leur but et s'ils l'ont fait cela n'offre aucun avantage stratégique de le faire remarquer. Il vous suffit de mettre en avant les chiffres réels pour que les gens réalisent que leur perception de la situation ne correspond pas à la réalité.
+
La meilleure façon de contrer cet effet est de montrer très clairement, preuves à l'appui, à quel point le groupe en désaccord est petit comparé à tous ceux qui sont d'accord. Pour rendre la disproportion plus évidente vous pourrez sonder en privé ceux qui ont gardé le silence mais que vous supposez en accord avec la majorité. Ne dites rien qui puisse faire croire que les dissidents essayaient de gonfler la portée de leur impact. Ce n'était pas nécessairement leur but et même si c'était le cas il n'y a aucun avantage stratégique à le faire remarquer. Il vous suffit de mettre en avant les chiffres réels pour que les gens réalisent que leur perception de la situation ne correspond pas à la réalité.
-
Ce conseil ne s'applique pas qu'aux problèmes où les camps sont bien marqués. Il s'applique à toutes les discussions faisant couler beaucoup d'encre numérique mais dont le sujet n'est pas nécessairement un vrai problème aux yeux des gens. Après un certain temps, si vous convenez que le sujet ne mérite pas d'action et que vous voyez qu'il n'avance pas (même s'il a généré beaucoup d' e-mails), vous pouvez simplement faire observer publiquement qu'il n'y a pas de progrès. Si l'effet « Minorité bruyante » s'était mis en place, votre message ressemblera à une bouffée d'air frais. La perception générale de la discussion ne sera plus aussi nette : « Heu, c'est vrai qu'on dirait que c'est important parce qu'il y a beaucoup de messages, mais je n'ai pas l'impression qu'on progresse. » En expliquant que la forme de la discussion l'a fait paraître plus animée qu'elle ne l'est vraiment vous lui donnez rétrospectivement une nouvelle forme à travers laquelle les participants peuvent se refaire une opinion de ce qui résulte de la discussion.
+
Ce conseil ne s'applique pas qu'aux problèmes où les camps sont bien marqués. Il s'applique à toutes les discussions faisant couler beaucoup d'encre virtuelle mais dont le sujet n'est pas nécessairement un vrai problème aux yeux des gens. Après un certain temps, si vous convenez que le sujet ne mérite pas d'action et que vous voyez qu'il n'avance pas (même s'il a généré beaucoup d' e-mails), vous pouvez simplement faire observer publiquement qu'il n'y a pas de progrès. Si l'effet « Minorité bruyante » s'était mis en place, votre message ressemblera à une bouffée d'air frais. La perception générale de la discussion ne sera plus aussi nette : « Heu, c'est vrai qu'on dirait que c'est important parce qu'il y a beaucoup de messages, mais je n'ai pas l'impression qu'on progresse. » En expliquant que la forme de la discussion l'a fait paraître plus animée qu'elle ne l'est vraiment vous lui donnez rétrospectivement une nouvelle forme à travers laquelle les participants peuvent se refaire une opinion de ce qui résulte de la discussion.
== Les personnes difficiles ==
== Les personnes difficiles ==
-
Il n'est pas plus facile de traiter avec les gens difficiles sur les forums électroniques que dans la réalité. Par « difficiles » je ne veux pas dire « grossiers ». Les gens grossiers sont embêtants, mais pas nécessairement difficiles. Nous avons déjà abordé dans cet ouvrage comment s'en occuper : faites leur remarquer leur grossièreté une première fois, à partir de quoi ignorez-les ou traitez-les comme n'importe qui d'autre. S'ils continuent à être grossiers, ils se rendront si impopulaires qu'ils n'auront plus d'influence sur les autres au sein du projet ; le problème qu'ils posent se résout ainsi de lui-même.
+
Il n'est pas plus facile de traiter avec les gens difficiles sur les forums électroniques que dans la vraie vie. Par « difficiles » je ne veux pas dire « grossiers ». Les gens grossiers sont embêtants, mais pas nécessairement difficiles. Nous avons déjà abordé dans cet ouvrage comment s'en occuper : faites leur remarquer leur grossièreté une première fois, à partir de quoi ignorez-les ou traitez-les comme n'importe quelle autre personne. S'ils continuent à être grossiers, ils se rendront si impopulaires qu'ils n'auront plus d'influence sur les autres au sein du projet ; le problème qu'ils posent se résout ainsi de lui-même.
-
Les cas réellement difficiles sont ceux qui n'étant pas ouvertement grossiers manipulent les autres ou abusent des processus du projet de telle sorte qu'ils monopolisent le temps et l'énergie des autres sans rien apporter de positif au projet. Ce genre de personnes cherchent souvent les points d'achoppement des procédures mises en place et s'en servent comme levier pour obtenir plus d'influence qu'ils n'en auraient autrement. C'est bien plus insidieux que de la simple grossièreté, car ni le comportement ni les dommages qu'ils causent ne sont visibles pour un observateur occasionnel. Un exemple classique est celui du bloqueur, quelqu'un (qui a l'air on ne peut plus raisonnable bien sûr) ne cesse de répéter à qui veut bien l'entendre que la réflexion n'est pas encore mure pour qu'on prenne une résolution et qui propose toujours plus de solutions ou de nouvelles approches sur de vielles solutions alors que ce qu'il se passe vraiment c'est qu'il sens que le consensus ou que le vote est en train de prendre forme et qu'il n'aime pas la direction qu'il prend. Un autre exemple est celui du débat qui n'aboutit pas à un consensus, mais dans lequel le groupe essaie au moins de clarifier les points de désaccord et de produire un compte-rendu auquel chacun pourra se référer par la suite. L'obstructionniste, qui sait que le compte-rendu peut avoir une issue qui lui déplaît, essaiera de reporter le compte-rendu en compliquant sans cesse la question de ce qui devrait y figurer, soit en s'opposant aux suggestions raisonnables soit en introduisant de nouveaux points inattendus.
+
Les cas réellement difficiles sont ceux qui n'étant pas ouvertement grossiers manipulent les autres ou abusent des processus du projet de telle sorte qu'ils monopolisent le temps et l'énergie des autres sans rien apporter de positif au projet. Ce genre de personnes cherchent souvent les points d'achoppement des procédures mises en place et s'en servent comme levier pour obtenir plus d'influence qu'ils n'en auraient autrement. C'est bien plus insidieux que de la simple grossièreté, car ni le comportement ni les dommages qu'ils causent ne sont visibles pour un observateur occasionnel. Un exemple classique est celui du bloqueur, quelqu'un (qui a l'air on ne peut plus raisonnable bien sûr) ne cesse de répéter à qui veut bien l'entendre que la réflexion n'est pas encore mure pour qu'on prenne une décision et qui propose toujours plus de solutions ou de nouvelles approches sur de vielles solutions alors qu'au fond il sent que le consensus ou le vote est en train de prendre forme et qu'il n'aime pas la direction qu'il prend. Un autre exemple est celui du débat qui n'aboutit pas à un consensus, mais dans lequel le groupe essaie au moins de clarifier les points de désaccord et de produire un compte-rendu auquel chacun pourra se référer par la suite. L'obstructionniste, qui sait que le compte-rendu peut avoir une issue qui lui déplaît, essaiera de reporter le compte-rendu en compliquant sans cesse la question de ce qui devrait y figurer, soit en s'opposant aux suggestions raisonnables soit en introduisant de nouveaux points inattendus.
=== Gérer les personnes difficiles ===
=== Gérer les personnes difficiles ===
-
Pour contrer ce genre de comportements il est utile de comprendre la mentalité de ceux qui y recourent. De manière générale ils ne le font pas consciemment. Personne ne se réveille le matin en se disant : « Tiens, aujourd'hui je vais manipuler cyniquement les procédures pour faire mon obstructionniste agaçant. » En revanche, de telles actions sont souvent précédées d'un sentiment semi-paranoïaque de mise à l'écart des échanges et des décisions du groupe. La personne a l'impression qu'on ne la prend pas au sérieux ou, dans les cas plus graves, qu'il y a une conspiration contre elle : que les autres membres du projet ont décidé de créer un club fermé dont elle n'est pas membre. Ce qui justifie, à ses yeux, de prendre le règlement à la lettre et de s'engager dans une manipulation formelle des procédures du projet, afin que les autres la prennent au sérieux. Dans les cas extrêmes, la personne peut même croire qu'elle se bat seule contre tous pour sauver le projet lui-même.
+
Pour contrer ce genre de comportements il est utile de comprendre la mentalité de ceux qui y recourent. De manière générale ils ne le font pas consciemment. Personne ne se réveille le matin en se disant : « Tiens, aujourd'hui je vais manipuler cyniquement les procédures pour faire mon obstructionniste agaçant. » En revanche, de telles actions sont souvent précédées d'un sentiment semi-paranoïaque de mise à l'écart des échanges et des décisions du groupe. La personne a l'impression qu'on ne la prend pas au sérieux ou, dans les cas plus graves, qu'il y a une conspiration contre elle : que les autres membres du projet ont décidé de créer un club fermé dont elle est exclue. Ce qui justifie, à ses yeux, de prendre le règlement à la lettre et de s'engager dans une manipulation formelle des procédures du projet, afin que les autres la prennent au sérieux. Dans les cas extrêmes, la personne peut même croire qu'elle se bat seule contre tous pour sauver le projet lui-même.
-
Il est dans la nature même de ces attaques de l'intérieur que tout le monde ne les remarque pas au même moment et certains ne les verront que si on leur en donne des preuves solides. Ce qui veut dire que les neutraliser peut demander pas mal d'efforts. Il ne suffit pas de vous convaincre de ce qui est en train de se produire ; il vous faudra aligner des preuves suffisantes pour convaincre les autres et les présenter de manière réfléchie.
+
Tout le monde ne remarquera pas ces attaques de l'intérieur au même moment, c'est dans leur nature même et certains ne les verront que si on leur en fournit des preuves solides. Par conséquent, neutraliser ces attaques peut demander pas mal d'efforts. Il ne suffit pas de vous convaincre de ce qui est en train de se produire ; il vous faudra aligner des preuves suffisantes et les présenter de manière réfléchie pour convaincre les autres.
-
Etant donné que combattre demande beaucoup d'efforts, la tolérance momentanée peut être votre meilleur choix. Pensez-y comme à une maladie parasitaire bénigne : si elle n'affaiblit pas trop le projet on peut accepter de rester infecté alors que les médicaments pourraient avoir des effets secondaires négatifs. Cependant, si tolérer l'infection cause trop de dommages il est alors temps d'agir. Commencez à rassembler des notes sur les faits que vous observez. Assurez-vous d'y inclure des références à des archives publiques, c'est là une des raisons pour lesquelles le projet garde des traces, vous pouvez donc les utiliser. Lorsque vous avez bien documenté l'affaire, entamez une phase de conversations privées avec d'autres participants. Ne leur dites pas ce que vous avez observé : recueillez d'abord leurs propres impressions. C'est sans doute votre dernière chance pour avoir un retour non filtré sur comment les autres voient le comportement du trublion ; une fois que vous commencerez à en parler ouvertement les avis seront polarisés et personne ne se souviendra de ce qu'il pensait avant sur la question.
+
Ces combats demandent beaucoup d'efforts, votre meilleure solution sera peut-être de tolérer momentanément ces comportements. C'est un peu comme une maladie parasitaire bénigne : si elle n'affaiblit pas trop le projet on peut la tolérer, les médicaments pourraient avoir des effets secondaires négatifs. Cependant, si la tolérer cause trop de dommages il est alors temps d'agir. Commencez à rassembler des notes sur les faits que vous observez. Assurez-vous d'y inclure des références à des archives publiques, c'est là une des raisons pour lesquelles le projet garde des traces, vous pouvez donc les utiliser. Lorsque vous avez bien documenté l'affaire, entamez une phase d'échanges privés avec d'autres participants. Ne leur dites pas ce que vous avez observé : recueillez d'abord leurs propres impressions. C'est sans doute votre dernière chance pour avoir un retour non filtré sur leur perception de la situation ; une fois que vous commencerez à en parler ouvertement les avis seront polarisés et personne ne se souviendra de son avis initial sur la question.
-
Si les discussions privées montrent qu'au moins quelques autres voient également qu'il y a un problème, il est temps de faire quelque chose. C'est là qu'il faut être vraiment prudent, car il est très facile pour ce genre de personnes d'essayer de faire croire qu'on leur tombe dessus injustement. Quoi que vous fassiez, ne les accusez jamais de détourner les procédures du projet de manière malintentionnée, d'être paranoïaques, ni de tout autre chose que vous soupçonnez être vraie. Votre stratégie doit être de vous montrer à la fois plus raisonnable et plus concerné par le bien-être global du projet, avec l'objectif de soit réformer le comportement de cette personne, soit de lui faire quitter le projet. Suivant les autres développeurs et vos relations avec eux, il peut être avantageux de réunir d'abord des alliés en privé... ou pas : cela pourrait créer des réticences en coulisse, si les gens pensent que vous vous lancez dans une campagne de rumeurs abusives.
+
Si les discussions privées montrent que vous n'êtes pas seul il est temps de faire quelque chose. C'est là qu'il faut être vraiment prudent, car il est très facile pour ce genre de personnes d'essayer de faire croire qu'on leur tombe dessus injustement. Quoi que vous fassiez, ne les accusez jamais de détourner les procédures du projet de manière malintentionnée, d'être paranoïaques, ni de tout autre chose que vous soupçonnez être vraies. Votre stratégie doit être de vous montrer à la fois plus raisonnable et plus concerné par le bien-être global du projet, avec l'objectif de soit réformer le comportement de cette personne, soit de lui faire quitter le projet. Selon les autres développeurs et vos relations avec eux, il peut être avantageux de réunir d'abord des alliés en privé... ou pas : cela pourrait créer des réticences en coulisse si les gens pensent que vous vous lancez dans une campagne de rumeurs abusives.
-
Souvenez-vous que, bien que l'autre personne soit celle qui agit de manière destructrice, c'est vous qui paraîtrez destructeur si vous faites des accusations publiques sans pouvoir les étayer. Soyez certain d'avoir de nombreux exemples pour démontrer ce que vous avancez et dites-le aussi gentiment que possible tout en étant direct. Vous ne persuaderez peut-être pas la personne en question, mais peu importe, du moment que vous arrivez à convaincre les autres.
+
Souvenez-vous que, bien que l'autre personne soit celle qui agit de manière destructrice, c'est vous qui paraîtrez destructeur si vous faites des accusations publiques sans pouvoir les étayer. Soyez certain d'avoir de nombreux exemples pour démontrer ce que vous avancez et dites-le aussi gentiment que possible tout en étant direct. Vous ne persuaderez peut-être pas la personne en question, mais ce n'est pas très important du moment que vous arrivez à convaincre les autres.
-
'''Etude de cas'''
+
'''Étude de cas'''
-
Je ne me souviens que d'une seule fois, au cours des dix années que j'ai passées dans le logiciel libre, où les choses sont arrivées à un point où nous avons dû demander à quelqu'un de cesser de poster des messages. Comme c'est souvent le cas, il n'était pas grossier et voulait vraiment être utile. Mais il ne savait pas quand il fallait poster et quand il ne le fallait pas. Nos listes étaient ouvertes au public et il postait si souvent pour poser des questions sur tellement de sujets qu'il devenait une source de bruit pour la communauté. Nous avions déjà essayé de lui demander gentiment de chercher un peu plus les réponses avant de poster, sans résultat.
+
Je ne me souviens que d'une seule fois, au cours des dix années que j'ai passées dans le logiciel libre, où les choses sont arrivées à un point où nous avons dû demander à quelqu'un de cesser de poster des messages. Comme c'est souvent le cas, il n'était pas grossier et voulait vraiment être utile. Mais il ne savait pas quand il fallait poster et quand il ne le fallait pas. Nos listes étaient ouvertes au public et il postait si souvent pour poser des questions sur tellement de sujets qu'il devenait une nuisance pour la communauté. Nous avions déjà essayé de lui demander gentiment de chercher un peu plus les réponses avant de poster, sans résultat.
-
La stratégie qui finit par payer est un exemple parfait de comment monter un dossier solide à partir de données neutres, quantitatives. Un de nos développeurs alla fouiller dans les archives, puis envoya le message suivant en privé à quelques développeurs. Le contrevenant (le troisième nom dans la liste ci-dessous, apparaissant ici comme « A. Nonyme ») avait très peu de relation avec le projet, il n'avait contribué ni au code ni à la documentation. Il était pourtant le troisième à avoir posté le plus de messages sur les listes :
+
La stratégie qui finit par payer est un exemple parfait de l'utilisation de données neutres, quantitatives pour monter un dossier solide. Un de nos développeurs alla fouiller dans les archives, puis envoya le message suivant en privé à quelques développeurs. Le contrevenant (le troisième nom dans la liste ci-dessous, apparaissant ici comme « A. Nonyme ») avait très peu de relation avec le projet, il n'avait contribué ni au code ni à la documentation. Et pourtant, parmi les participants, il était troisième en nombre de messages envoyés sur les listes :
Ligne 268 : Ligne 269 :
aux 5 autres, sans parler de la liste dans son ensemble, ralentissant ainsi
aux 5 autres, sans parler de la liste dans son ensemble, ralentissant ainsi
(fût-ce involontairement) le développement de Subversion. Je n'ai pas fait
(fût-ce involontairement) le développement de Subversion. Je n'ai pas fait
-
une analyse fil par fil, mais un vgrepp sur mon spool de mail Subversion
+
une analyse fil par fil, mais un vgrepp sur mon spool d'e-mail Subversion
-
me dit que chaque mail de cette personne reçoit une réponse au moins
+
me dit que pour chaque e-mail de cette personne, au moins deux des cinq
-
une fois par au minimum 2 des 5 autres personnes de la liste ci-dessus.
+
autres personnes de la liste ci-dessus prennent le temps de lui répondre.
Je pense qu'une intervention musclée est nécessaire, quitte à effrayer la
Je pense qu'une intervention musclée est nécessaire, quitte à effrayer la
-
personne mentionnée plus haut. Les délicatesses et la gentillesse se sont
+
personne mentionnée plus haut. La délicatesse et la gentillesse se sont
avérées sans effet.
avérées sans effet.
Ligne 279 : Ligne 280 :
logiciel de gestion de version, ce n'est pas une séance de thérapie de groupe.
logiciel de gestion de version, ce n'est pas une séance de thérapie de groupe.
-
-Fitz, cherchant à ne pas se noyer dans trois jours de mails svn
+
-Fitz, qui cherche à ne pas se noyer dans trois jours d'e-mails svn
-
qu'il a laissés s'empiler.
+
qu'il a laissés s'accumuler.
-
Bien qu'il n'en eût pas l'air au début, le comportement de A. Nonyme était un cas classique d'abus des procédures. Il ne faisait pas rien de flagrant comme retarder un vote, mais il tirait profit de la politique de la liste de diffusion reposant sur l'auto-modération par ses membres. C'était à chaque membre de juger quand et sur quoi poster. Donc, nous n'avions pas de procédure de recours pour faire face à une personne qui soit n'avait pas, soit n'exerçait pas, cette capacité de discernement. On ne pouvait pas dire que ce gars violait des règles mais pourtant tout le monde savait que ses messages fréquents devenaient un problème sérieux.
+
Bien qu'il n'en eût pas l'air au début, le comportement de A. Nonyme était un cas classique d'abus des procédures. Il ne faisait rien de flagrant comme retarder un vote, mais il tirait profit de la politique d'auto-modération de la liste de diffusion. C'était à chaque membre de juger quand et sur quoi poster. Donc, nous n'avions pas de procédure de recours pour faire face à une personne qui soit n'avait pas, soit n'exerçait pas, cette capacité de discernement. On ne pouvait pas dire que ce gars violait des règles mais pourtant tout le monde savait que ses messages fréquents devenaient un problème sérieux.
La stratégie de Fitz s'est avérée, rétrospectivement, excellente. Il a réuni des preuves accablantes, mais les a diffusées discrètement, les communiquant d'abord aux quelques personnes dont le soutien s'avérait décisif pour une action drastique. Ils étaient d'accord sur le fait que des mesures étaient nécessaires et finalement nous avons appelé A. Nonyme au téléphone, nous lui avons décrit le problème directement et lui avons demandé de cesser de poster. Il n'en a jamais vraiment compris les raisons ; s'il avait été en mesure de les comprendre il aurait probablement fait preuve de discernement dès les début. Mais il accepta de ne plus poster et la liste devint utilisable à nouveau. Une des raisons pour lesquelles cette stratégie a fonctionné, peut-être, était la menace implicite que nous pourrions mettre en place un filtrage de ses messages 'via' le logiciel de modération couramment utilisé pour prévenir le spam (voir la section « Se prémunir du Spam » dans le Chapitre 3, Infrastructure technique). Mais si nous avions cette option en réserve, c'est parce que Fitz avait d'abord réuni le soutien nécessaire de personnages clés.
La stratégie de Fitz s'est avérée, rétrospectivement, excellente. Il a réuni des preuves accablantes, mais les a diffusées discrètement, les communiquant d'abord aux quelques personnes dont le soutien s'avérait décisif pour une action drastique. Ils étaient d'accord sur le fait que des mesures étaient nécessaires et finalement nous avons appelé A. Nonyme au téléphone, nous lui avons décrit le problème directement et lui avons demandé de cesser de poster. Il n'en a jamais vraiment compris les raisons ; s'il avait été en mesure de les comprendre il aurait probablement fait preuve de discernement dès les début. Mais il accepta de ne plus poster et la liste devint utilisable à nouveau. Une des raisons pour lesquelles cette stratégie a fonctionné, peut-être, était la menace implicite que nous pourrions mettre en place un filtrage de ses messages 'via' le logiciel de modération couramment utilisé pour prévenir le spam (voir la section « Se prémunir du Spam » dans le Chapitre 3, Infrastructure technique). Mais si nous avions cette option en réserve, c'est parce que Fitz avait d'abord réuni le soutien nécessaire de personnages clés.
== Gérer la croissance ==
== Gérer la croissance ==
-
Le prix du succès est lourd dans le monde de l'Open Source. Au fur et à mesure que votre logiciel devient populaire le nombre de personnes cherchant des renseignements augmente de manière très importante tandis que le nombre de personnes capables de fournir ces renseignements croît bien plus lentement. De plus, même si la proportion entre les deux était à peu près équilibrée, il resterait encore un problème fondamental : l'adaptation de la gestion de la communication. Prenons les listes de diffusion par exemple. La plupart des projets disposent d'une liste pour les questions générales des utilisateurs, cette liste s'appelle parfois « utilisateurs », « discussion », « aide » ou quelque chose comme ça. Quel qu'en soit le nom, le but de cette liste est toujours le même : fournir un lieu où les gens trouvent des réponses à leurs questions, tandis que d'autres observent et (normalement) s'imprègnent des connaissances en observant ces échanges.
+
Le prix du succès est lourd dans le monde de l'Open Source. Au fur et à mesure que votre logiciel devient populaire le nombre de personnes cherchant des renseignements augmente de manière très importante tandis que le nombre de personnes capables de fournir ces renseignements croît bien plus lentement. De plus, même si la proportion entre les deux était à peu près équilibrée, il resterait encore un problème fondamental : la gestion de la communication. Prenons les listes de diffusion par exemple. La plupart des projets disposent d'une liste pour les questions générales des utilisateurs, cette liste s'appelle parfois « utilisateurs », « discussion », « aide » ou quelque chose comme ça. Quel qu'en soit le nom, le but de cette liste est toujours le même : fournir un lieu où les gens trouvent des réponses à leurs questions, tandis que d'autres observent et (normalement) s'imprègnent des connaissances en observant ces échanges.
-
Il n'y a pas d'explosion quand les forums atteignent le point culminant. Il y a seulement une suite de discrets évènements néfastes : les gens se désabonnent des listes ou désertent le canal IRC ou cessent d'une manière ou d'une autre de se donner la peine de poser des questions car ils comprennent qu'ils ne seront pas entendus au milieu de tout ce bruit. Comme de plus en plus de personnes font ce choix bien compréhensible l'activité du forum semblera se maintenir à un niveau gérable. Mais elle reste gérable justement parce que les gens rationnels (ou du moins expérimentés) ont commencé à chercher l'information ailleurs, tandis que les gens inexpérimentés restent et continuent à poster. En d'autres termes, quand on continue à utiliser des modèles de communication non modulables alors que le projet grandit, l'un des effets secondaires est que la qualité moyenne des questions et des réponses tend à baisser, ce qui donne l'impression que les nouveaux utilisateurs sont plus bêtes qu'ils ne l'étaient dans le temps alors qu'en fait ce n'est probablement pas le cas. C'est juste que la rentabilité de ces forums à grande audience est plus bas, donc naturellement ceux qui en ont l'expérience s'adressent en priorité ailleurs pour obtenir leurs réponses. Ajuster les mécanismes de communication pour faire face à la croissance du projet implique deux stratégies liées :
+
Il n'y a pas d'explosion quand les forums atteignent leur point culminant. Il y a seulement une suite d' évènements ponctuels néfastes : les gens se désabonnent des listes ou ils désertent le canal IRC ou ils cessent d'une manière ou d'une autre de se donner la peine de poser des questions car ils comprennent qu'ils ne seront pas entendus au milieu de tout ce bruit. Comme de plus en plus de personnes font ce choix bien compréhensible l'activité du forum semblera se maintenir à un niveau gérable. Mais elle reste gérable justement parce que les gens rationnels (ou du moins expérimentés) ont commencé à chercher l'information ailleurs, tandis que les gens inexpérimentés restent et continuent à poster. En d'autres termes, quand on continue à utiliser des modèles de communication non modulables alors que le projet grandit la qualité moyenne des questions et des réponses tend à baisser, ce qui donne l'impression que les nouveaux utilisateurs sont plus bêtes qu'ils ne l'étaient dans le temps alors qu'en fait ce n'est probablement pas le cas. C'est juste que la rentabilité de ces forums à grande audience est plus bas, donc naturellement ceux qui en ont l'expérience chercheront ailleurs leurs réponsesen priorité. Ajuster les mécanismes de communication pour faire face à la croissance du projet implique deux stratégies liées :
-
:#Identifier les parties spécifiques d'un forum qui ne subissent pas une croissance débridée, même si c'est le cas pour le forum dans son ensemble, et les détacher dans un nouveau forum plus spécialisé (c-à-d ne laissez pas le mauvais tirer le bon vers le bas.)
+
:#Identifier les parties spécifiques d'un forum qui ne subissent pas une croissance débridée, contrairement au reste du forum, et les détacher dans un nouveau forum plus spécialisé (''i.e.'' ne laissez pas le mauvais tirer le bon vers le bas.)
-
:#S'assurer qu'il existe plusieurs sources d'information automatisées, qu'elles sont bien organisées, mises à jour et faciles à trouver.
+
:#S'assurer que plusieurs sources d'information automatisées sont à la disposition des utilisateurs, qu'elles sont bien organisées, mises à jour et faciles à trouver.
-
La stratégie n°1 est généralement assez facile à mettre en œuvre. La plupart des projets démarre avec un forum principal : une liste de discussion générale dans laquelle les propositions de fonctionnalités, les questions de conception et les problèmes liés au code sont abordées en vrac. Tous les gens impliqués dans le projet y sont inscrits. Au bout d'un certain temps, il devient évident que la liste a évolué en plusieurs sous-listes orientées chacune sur un sujet. Par exemple, certains fils concernent clairement le développement et la conception ; d'autres sont des questions d'utilisateurs sur le fonctionnement « Comment faire X ? » ; une troisième lignée porte peut-être sur le traitement des rapports de bogue et les demandes d'améliorations, etc. Un individu donné peut bien sûr prendre part à plusieurs types de fils différents, mais ce qui compte est que ces catégories ne se recoupent pas trop. Ils pourraient être répartis dans des listes séparées sans causer un cloisonnement nuisible car les fils traversent rarement la frontière des sujets.
+
La stratégie n°1 est généralement assez facile à mettre en œuvre. La plupart des projets démarre avec un forum principal : une liste de discussion générale dans laquelle les propositions de fonctionnalités, les questions relatives à la conception et les problèmes liés au code sont abordées en vrac. Tous les gens impliqués dans le projet y sont inscrits. Au bout d'un certain temps, il devient évident que la liste a évolué en plusieurs sous-listes orientées chacune sur un sujet. Par exemple, certains fils concernent clairement le développement et la conception ; d'autres sont des questions d'utilisateurs sur le fonctionnement « Comment faire X ? » ; une troisième lignée porte peut-être sur le traitement des rapports de bogue et les demandes d'améliorations, etc. Un individu donné peut bien sûr prendre part à plusieurs types de fils différents, mais il faut voir que ces catégories ne se recoupent pas trop. Ils pourraient être répartis dans des listes séparées sans causer un cloisonnement nuisible car les fils traversent rarement la frontière des sujets.
-
Procéder à cette division est un processus en deux étapes. On crée d'abord la nouvelle liste (ou canal IRC, ou autre), puis on passe le temps nécessaire à gentiment harceler les gens et leur rappeler l'utilisation appropriée des nouveaux forums. Cette dernière étape peut durer des semaines, mais un jour les gens s'y feront. Vous devez simplement vous astreindre à prévenir systématiquement l'expéditeur quand son message est posté au mauvais endroit, et le faire de manière visible, pour que les autres soient encouragés à vous relayer dans l'aiguillage. Il est utile également d'avoir une page Web avec un guide de toutes les listes disponibles ; vos réponses peuvent simplement renvoyer à cette page et, en prime, le destinataire aura appris à se reporter au guide d'utilisation avant de poster.
+
Procéder à cette division est un processus en deux étapes. On crée d'abord la nouvelle liste (ou canal IRC, ou autre), puis on passe le temps nécessaire à gentiment harceler les gens et leur rappeler l'utilisation appropriée des nouveaux forums. Cette dernière étape peut durer des semaines, mais un jour les gens s'y feront. Vous devez simplement vous astreindre à prévenir systématiquement l'expéditeur quand son message est posté au mauvais endroit, et le faire de manière visible, pour que les autres soient encouragés à vous relayer dans l'aiguillage. Il est utile également d'avoir une page Web avec un index de toutes les listes disponibles ; vos réponses peuvent simplement renvoyer à cette page et, en prime, le destinataire aura appris à se reporter au guide d'utilisation avant de poster.
-
La stratégie n° 2 est un processus à long terme, qui dure tant que dure le projet et implique plusieurs participants. Bien sûr, c'est en partie une question de documentation à jour (voir la section « Documentation » du Chapitre 2, Bien démarrer) et d'orientation des gens. Mais c'est bien plus que cela. La section qui suit examine cette stratégie en détail.
+
La stratégie n° 2 est un processus à long terme, qui dure tant que dure le projet et implique plusieurs participants. Bien sûr, il est question ici de documentation à jour (voir la section « Documentation » du [[POSSFR_Chap_2|Chapitre 2, Bien démarrer]]) et d'orientation des gens. Mais c'est bien plus que cela. La section qui suit examine cette stratégie en détail.
=== Utilisation visible des archives ===  
=== Utilisation visible des archives ===  
Ligne 305 : Ligne 306 :
Traditionnellement, toutes les communications échangées dans un projet Open Source (exceptées parfois les conversations IRC) sont archivées. Les archives sont publiques et consultables et elles ont une stabilité référentielle : c'est-à-dire qu'une fois qu'une information a été enregistrée à une adresse donnée, elle y reste pour toujours.
Traditionnellement, toutes les communications échangées dans un projet Open Source (exceptées parfois les conversations IRC) sont archivées. Les archives sont publiques et consultables et elles ont une stabilité référentielle : c'est-à-dire qu'une fois qu'une information a été enregistrée à une adresse donnée, elle y reste pour toujours.
-
Utilisez ces archives autant que possible et aussi visiblement que possible. Même si vous connaissez par cœur la réponse à une question, si vous pensez qu'il y a dans les archives une référence qui contient la réponse, prenez le temps d'aller la chercher et de la montrer. Chaque fois que vous faites ceci publiquement et de manière visible, quelqu'un apprend pour la première fois que les archives sont là et qu'elles contiennent des réponses aux questions. De même, en vous référant aux archives plutôt qu'en ré-écrivant la réponse, vous renforcez la règle sociale qui lutte contre la duplication de l'information. Pourquoi avoir la même réponse à deux endroits différents ? Les gens retrouveront plus facilement une réponse qu'ils ont déjà dénichée si celle-ci n'est pas répliquée x fois. Des références faciles à localiser contribuent également à la qualité des résultats des recherches en général car elles renforcent la classification des ressources ciblées par les moteurs de recherche Internet.
+
Utilisez ces archives autant que possible et aussi visiblement que possible. Même si vous connaissez par cœur la réponse à une question, si vous pensez qu'il y a dans les archives une référence qui contient la réponse, prenez le temps d'aller la chercher et de la montrer. Chaque fois que vous faites ceci publiquement et de manière visible, quelqu'un apprend pour la première fois que les archives sont là et qu'elles contiennent des réponses aux questions. De même, en vous référant aux archives plutôt que de ré-écrire la réponse vous renforcez la règle sociale qui lutte contre la duplication de l'information. Pourquoi avoir la même réponse à deux endroits différents ? Les gens retrouveront plus facilement une réponse qu'ils ont déjà dénichée si celle-ci n'est pas répliquée x fois. Des références faciles à localiser contribuent également à la qualité des résultats des recherches en général car elles renforcent la classification des ressources ciblées par les moteurs de recherche Internet.
Il existe pourtant des cas où dupliquer l'information peut avoir un sens. Imaginez par exemple qu'il y a déjà une réponse dans les archives, pas de vous, qui dit :
Il existe pourtant des cas où dupliquer l'information peut avoir un sens. Imaginez par exemple qu'il y a déjà une réponse dans les archives, pas de vous, qui dit :
Ligne 315 : Ligne 316 :
#Redémarrez le serveur.
#Redémarrez le serveur.
-
Puis, des mois plus tard, vous verrez un autre message expliquant que les index de quelqu'un ont été embrouillés. Vous cherchez dans les archives et trouvez l'ancienne réponse ci-dessus, mais vous vous rendez compte qu'il y manque quelques étapes (soit par erreur, soit parce que le logiciel a changé depuis la rédaction du message). La meilleure façon de procéder consiste à poster de nouvelles instructions, plus complètes, et de rendre explicitement obsolète le message précédent en le mentionnant :
+
Puis, des mois plus tard, vous verrez un autre message expliquant que les index de quelqu'un ont été embrouillés. Vous cherchez dans les archives et trouvez l'ancienne réponse ci-dessus, mais vous vous rendez compte qu'il y manque quelques étapes (soit par erreur, soit parce que le logiciel a changé depuis la rédaction du message). Il vaut alors mieux poster de nouvelles instructions, plus complètes, et de rendre explicitement obsolète le message précédent en le mentionnant :
Il s'avère que vos index de Scanley ont été embrouillés. Nous avons vu ce problème en juillet dernier et A. Nonyme avait posté une solution à l'adresse http://blablabla/bla. Vous trouverez ci-dessous des indications plus complètes pour désembrouiler vos index, basées sur celles de A. Nonyme mais un peu plus développées :
Il s'avère que vos index de Scanley ont été embrouillés. Nous avons vu ce problème en juillet dernier et A. Nonyme avait posté une solution à l'adresse http://blablabla/bla. Vous trouverez ci-dessous des indications plus complètes pour désembrouiler vos index, basées sur celles de A. Nonyme mais un peu plus développées :
Ligne 325 : Ligne 326 :
#Redémarrez le serveur
#Redémarrez le serveur
-
(Dans un monde idéal, il serait possible d'attacher une note à l'ancien message précisant qu'il y a des informations plus récentes et pointant vers le nouvel article. Cependant, je ne connais aucun logiciel d'archivage qui propose une fonction « rendu obsolète par », peut-être parce qu'il serait difficile à mettre en oeuvre de façon à ce que l'intégrité des archives soit préservée en tant que trace verbatim. C'est là une autre raison qui justifie la création de pages Web dédiées consignant les réponses aux questions courantes.)
+
(Dans un monde idéal il serait possible d'attacher une note à l'ancien message précisant que des informations plus récentes ont été apportées et d'y inclure un lien vers le nouvel article. Cependant, je ne connais aucun logiciel d'archivage qui propose une fonction « rendu obsolète par », peut-être parce qu'il serait difficile à mettre en oeuvre de façon à ce que l'intégrité des archives soit préservée en tant que trace verbatim. C'est là une autre raison qui justifie la création de pages Web dédiées consignant les réponses aux questions courantes.)
-
Les archives sont le plus souvent utilisées pour chercher des réponses aux questions techniques, mais leur importance pour le projet va au-delà. Si les règles d'utilisation formelles du projet constituent la loi ordinaire, les archives représentent le droit coutumier : des archives de toutes les décisions prises et de comment on y est parvenu. Dans toute discussion récurrente il est plus ou moins obligatoire de nos jours de commencer par une recherche dans les archives. Ceci permet de commencer la discussion par une résumé de l'état actuel des choses, d'anticiper des objections, de parer aux réticences et probablement de trouver des idées auxquelles vous n'auriez pas pensé. Du point de vue des autres participants aussi vous êtes censé avoir fait une recherche dans les archives. Même si les discussions précédentes n'ont mené nulle part vous devriez mettre un lien qui y renvoi au moment de remettre la question sur le tapis pour que les gens constatent par eux-mêmes que : a) elles n'ont mené nulle part et b) vous avez fait votre boulot. Ils seront alors en mesure de dire quelque chose qui n'a pas été dit auparavant.
+
Les archives sont le plus souvent utilisées pour chercher des réponses aux questions techniques, mais leur importance pour le projet va au-delà. Si les règles formelles d'utilisation du projet constituent la loi ordinaire, les archives représentent le droit coutumier : des archives de toutes les décisions prises et des discussions qui y ont mené. Dans toute discussion récurrente il est plus ou moins obligatoire de nos jours de commencer par une recherche dans les archives. Ceci permet de commencer la discussion par une résumé de l'état actuel des choses, d'anticiper des objections, de parer aux réticences et probablement de trouver des idées auxquelles vous n'auriez pas pensé. Les autres participants aussi estimeront que vous êtes censé avoir fait une recherche dans les archives. Même si les discussions précédentes n'ont mené nulle part vous devriez mettre un lien qui y renvoi au moment de remettre la question sur le tapis pour que les gens constatent par eux-mêmes que : a) elles n'ont mené nulle part et b) vous avez fait votre boulot. Ils seront alors en mesure de dire quelque chose qui n'a pas été dit auparavant.
=== Traitez toutes les ressources comme des archives ===
=== Traitez toutes les ressources comme des archives ===
Ligne 336 : Ligne 337 :
:#Ils veulent pouvoir y chercher des mots et des phrases
:#Ils veulent pouvoir y chercher des mots et des phrases
-
:#Ils veulent pouvoir la parcourir, aller à la pêche aux informations sans chercher nécessairement de réponses à des questions spécifiques
+
:#Ils veulent pouvoir la parcourir, aller à la pêche aux informations sans chercher nécessairement de réponses à des questions particulières
-
:#Ils s'attendent à ce que le contenu de la FAQ soit accessible aux moteurs de recherche tel que Google, de façon à ce que les recherches pointent vers les rubriques de la FAQ
+
:#Ils s'attendent à ce que le contenu de la FAQ soit accessible aux moteurs de recherche tel que Google, de manière à ce que les recherches pointent vers les rubriques de la FAQ
:#Ils veulent pouvoir indiquer à d'autres personnes des articles spécifiques de la FAQ
:#Ils veulent pouvoir indiquer à d'autres personnes des articles spécifiques de la FAQ
:#Ils veulent pouvoir ajouter de nouveaux éléments à la FAQ. Notez néanmoins que ceci est bien moins courant que la recherche de réponses : on lit plus souvent une FAQ qu'on y écrit
:#Ils veulent pouvoir ajouter de nouveaux éléments à la FAQ. Notez néanmoins que ceci est bien moins courant que la recherche de réponses : on lit plus souvent une FAQ qu'on y écrit
-
Le point 1 implique que la FAQ soit disponible sous forme de texte. Les point 2 et 3 impliquent que la FAQ doit être disponible au format HTML et le point 2 indique de plus que le HTML doit être conçu pour la lecture (c'est-à-dire en tenant compte de l'apparence) et proposer une table des matières. Le point 4 signifie que chaque entrée de la FAQ doit faire l'objet d'une ancre à son nom, une étiquette qui permet d'atteindre un endroit particulier de la page. Le point 5 suppose que les fichiers source de la FAQ doivent être accessibles de manière commode (voir la section « Tout versionner » du Chapitre 3, Infrastructure technique), dans un format facile à éditer.
+
Le point 1 implique que la FAQ soit disponible sous forme de texte. Les point 2 et 3 impliquent que la FAQ doit être disponible au format HTML et le point 2 indique de plus que le HTML doit être adapté à la lecture (c'est-à-dire en tenant compte de l'apparence) et proposer une table des matières. Le point 4 signifie que chaque entrée de la FAQ doit faire l'objet d'une ancre à son nom, une étiquette qui permet d'atteindre un endroit particulier de la page. Le point 5 suppose que les fichiers sources de la FAQ doivent être accessibles de manière commode (voir la section « Tout versionner » du [[POSSFR_Chap_3|Chapitre 3, Infrastructure technique]]), dans un format facile à éditer.
=== Ancres nommées (named anchors) et attributs ID ===
=== Ancres nommées (named anchors) et attributs ID ===
Ligne 365 : Ligne 366 :
...bien que normalement il devrait y avoir un texte, comme un titre de section.
...bien que normalement il devrait y avoir un texte, comme un titre de section.
-
Que vous utilisiez une ancre nommée, un attribut id ou les deux, rappelez-vous que ne sera pas visible à ceux qui parcourent la page sans utiliser l'étiquette. Mais cette personne peut vouloir connaître l'étiquette d'une section en particulier, pour pouvoir envoyer l'URL de la réponse de la FAQ à un ami par exemple. Pour l'y aider, ajoutez un titre aux éléments auxquels vous avez ajouté un « nom » et/ou un « id », par exemple :
+
Que vous utilisiez une ancre nommée, un attribut id ou les deux, rappelez-vous que les visiteurs qui parcourent la page sans utiliser d'étiquette ne voient pas la différence. Mais cette personne peut vouloir connaître l'étiquette d'une section en particulier, pour pouvoir envoyer l'URL de la réponse de la FAQ à un ami par exemple. Pour l'y aider, ajoutez un titre aux éléments auxquels vous avez ajouté un « nom » et/ou un « id », par exemple :
<nowiki><a name="monetiquette" title="#monetiquette">...</a></nowiki>
<nowiki><a name="monetiquette" title="#monetiquette">...</a></nowiki>
Ligne 375 : Ligne 376 :
=== Codifier la tradition ===
=== Codifier la tradition ===
-
Quand l'histoire d'un projet s'étoffe et gagne en complexité, la quantité de données que chaque nouvel arrivant doit assimiler augmente. Ceux qui participent au projet depuis longtemps ont pu apprendre, voire forger, les conventions du projet en cours de route. Très souvent, ils n'auront pas clairement conscience du corpus de traditions qui s'est accumulé et seront surpris des nombreux impairs que les nouveaux sont susceptibles de commettre. Bien sûr, le problème n'est pas que les nouveaux venus sont moins bien qu'avant ; c'est que l'effort d'acclimatation qu'ils doivent consentir est plus important que pour les nouveaux venus d'avant.
+
Quand l'histoire d'un projet s'étoffe et gagne en complexité, la quantité de données que chaque nouvel arrivant doit assimiler augmente. Ceux qui participent au projet depuis longtemps ont pu apprendre, voire forger, les conventions du projet en cours de route. Très souvent, ils n'auront pas clairement conscience du corpus de traditions qui s'est accumulé et seront surpris des nombreux impairs que les nouveaux sont susceptibles de commettre. Bien sûr, le problème n'est pas que les nouveaux venus sont moins bon qu'avant ; c'est que l'effort d'acclimatation qu'ils doivent consentir est plus important que pour les nouveaux venus d'avant.
-
Les traditions qu'un projet accumule portent aussi bien sur la communication et la préservation de l'information que sur la qualité du code ou d'autres détails techniques. Nous avons déjà examiné ces deux types de mesures respectivement dans la section « Documentation développeur » du Chapitre 2 et dans la section intitulée « Tout mettre par écrit » du Chapitre 4 où des exemples ont été fournis. Cette partie se concentre plus sur le maintien de ces guides d'utilisation à jour avec l'évolution du projet, plus particulièrement le guide concernant la gestion des communications, car c'est ce qui change le plus quand le projet croît en taille et en complexité.
+
Les traditions qu'un projet accumule portent aussi bien sur la communication et la préservation de l'information que sur la qualité du code ou d'autres détails techniques. Nous avons déjà examiné ces deux cas de figure dans les sections « Documentation développeur » du [[POSSFR_Chap_2|Chapitre 2]] et « Tout mettre par écrit » du [[POSSFR_Chap_4|Chapitre 4]], respectivement, où des exemples ont été fournis. Ici nous allons plus particulièrement nous concentrer sur la mise à jour de ces informations avec l'évolution du projet et plus particulièrement celles relatives à la gestion des communications, c'est en effet le domaine qui évolue le plus quand le projet gagne en taille et en complexité.
-
Premièrement, cherchez ce qui est le plus déroutant pour les gens. Si vous voyez les mêmes situations revenir sans cesse, particulièrement avec les nouveaux participants, il y a des chances que le guide ne soit pas documenté. Deuxièmement, ne vous lassez pas de répéter cent fois les mêmes choses et n'ayez pas l'air las en les répétant. Vous, ainsi que les autres vétérans du projet, aurez à vous répéter souvent ; c'est un effet secondaire inévitable généré par l'arrivée de nouveaux.  
+
Premièrement, cherchez ce qui est le plus déroutant pour les gens. Si les mêmes situations se répètent sans cesse, particulièrement avec les nouveaux participants, il y a des chances que le guide ne soit pas documenté. Deuxièmement, ne vous lassez pas de répéter cent fois les mêmes choses et n'ayez pas l'air las en les répétant. Vous, ainsi que les autres vétérans du projet, aurez à vous répéter souvent ; c'est un effet secondaire inévitable de l'arrivée de nouveaux participants.  
-
Chaque page Web, chaque message de la liste, chaque canal IRC doivent être considérés comme des espaces publicitaires : non pas pour passer des annonces commerciales, mais pour faire la réclame des ressources propres au projet. Ce que vous mettrez dans chaque espace dépend de la population susceptible de le lire. Un canal IRC consacré aux questions des utilisateurs, par exemple, amènera des gens qui n'ont jamais été en relation avec le projet auparavant, généralement quelqu'un qui vient d'installer le logiciel et qui aimerait une réponse immédiate à sa question (après tout, si ça pouvait attendre, il l'aurait postée sur la liste de diffusion, ce qui lui prendrait probablement moins de temps dans l'ensemble, bien que le délai pour la réponse soit plus long). Les gens n'investissent généralement pas le canal IRC sur la durée : ils surgissent, posent leur question et s'en vont.
+
Chaque page Web, chaque message de la liste, chaque canal IRC doivent être considérés comme des espaces publicitaires : non pas pour passer des annonces commerciales, mais pour faire la réclame des ressources propres au projet. Ce que vous mettrez dans chaque espace dépend de la population susceptible de le lire. Un canal IRC consacré aux questions des utilisateurs, par exemple, amènera des gens qui n'ont jamais été en relation avec le projet auparavant, typiquement quelqu'un qui vient d'installer le logiciel et qui aimerait une réponse immédiate à sa question (après tout, si ça pouvait attendre, il l'aurait postée sur la liste de diffusion, ce qui lui prendrait probablement moins de temps dans l'ensemble, bien que le délai pour la réponse soit plus long). Les gens n'investissent généralement pas le canal IRC sur la durée : ils surgissent, posent leur question et s'en vont.
-
C'est pourquoi le sujet du canal doit viser les gens qui cherchent des réponses techniques sur le logiciel de manière immédiate, plutôt que, disons, des gens qui pourraient s'investir dans le projet à long terme et pour qui le manuel des usages de la communauté serait plus approprié. Voici comment un canal réellement actif gère la question (à comparer avec l'exemple précédent dans la section « IRC et les chats en temps réel » du Chapitre 3, Infrastructure Technique) :
+
C'est pourquoi le sujet du canal doit viser les gens qui cherchent des réponses techniques immédiates, plutôt que, disons, des gens qui pourraient s'investir dans le projet à long terme et pour qui le manuel des usages de la communauté serait plus approprié. Voici comment un canal réellement actif gère la question (à comparer avec l'exemple précédent dans la section « IRC et les chats en temps réel » du [[POSSFR_Chap_3|Chapitre 3, Infrastructure Technique]]) :
Ligne 393 : Ligne 394 :
:du canal se trouvent ici : http://www.nerdfest.org/lh_rules.html <nowiki>| </nowiki>Veuillez consulter
:du canal se trouvent ici : http://www.nerdfest.org/lh_rules.html <nowiki>| </nowiki>Veuillez consulter
:http://kerneltrap.org/node/view/799 avant de poser une question
:http://kerneltrap.org/node/view/799 avant de poser une question
-
:sur la mise à jour en 2.6.x<nowiki> | aide mémoire : http://tinyurl.com/4s6mc -></nowiki>
+
:sur la mise à jour 2.6.x<nowiki> | aide mémoire : http://tinyurl.com/4s6mc -></nowiki>
:mise à jour 2.6.8.1 ou 2.4.27 <nowiki>| </nowiki>sinistre algorithme de hachage : http://tinyurl.com/6w8rf
:mise à jour 2.6.8.1 ou 2.4.27 <nowiki>| </nowiki>sinistre algorithme de hachage : http://tinyurl.com/6w8rf
:<nowiki>| </nowiki>reiser4 out
:<nowiki>| </nowiki>reiser4 out
-
Dans les listes de diffusion, l'« espace publicitaire » consiste en un pied de page (''footer'') ajouté à la fin de chaque message. La plupart des projets y font figurer les instructions pour s'inscrire/se désinscrire ainsi qu'éventuellement un lien vers la page d'accueil du projet ou vers la FAQ. Vous pensez peut-être que tous les abonnés de la liste savent où trouver ces informations, et c'est vraisemblablement le cas, mais bien des personnes autres que les abonnés voient les messages de la liste. Des liens peuvent pointer vers le courrier archivé depuis de multiples endroits ; de fait, certains messages deviennent si connus qu'ils peuvent avoir plus de lecteurs hors liste que dans la liste.
+
Dans les listes de diffusion, l'« espace publicitaire » c'est la note de bas de page (''footer'') ajoutée à la fin de chaque message. La plupart des projets y font figurer les instructions pour s'inscrire/se désinscrire ainsi qu'éventuellement un lien vers la page d'accueil du projet ou vers la FAQ. Vous pensez peut-être que tous les abonnés de la liste savent où trouver ces informations, et c'est vraisemblablement le cas, mais bien des personnes autres que les abonnés voient les messages de la liste. Des liens peuvent pointer vers le courrier archivé en de nombreux endroits ; de fait, certains messages deviennent si connus qu'ils peuvent avoir plus de lecteurs hors liste que dans la liste.
-
Le formatage peut apporter un réel plus. Par exemple, dans le projet Subversion nous avions un succès limité avec l'utilisation de la technique de filtrage de bogues décrite dans la section « Filtrer le système de suivi des bogues en amont » du Chapitre 3, Infrastructure technique. De nombreux rapports de bogues bidons étaient créés par des gens inexpérimentés et, chaque fois que cela se produisait, il fallait former le rapporteur exactement de la même manière que les 500 rapporteurs précédents. Un jour, alors qu'un de nos développeurs avait fini par perdre patience et s'en était pris à un pauvre utilisateur qui n'avait pas lu assez attentivement le manuel du traqueur de bogues un autre développeur décida qu'il était temps de mettre fin à ce schéma. Il proposa une refonte de la page d'accueil du traqueur de bogues pour faire ressortir en gros caractères rouge et gras sur fonds jaune, bien centrés en tête de page, le point le plus important, à savoir l'incitation à discuter le bogue sur la liste de diffusion et sur le canal IRC avant de remplir un rapport. Ce qui fut fait (vous pouvez voir le résultat sur http://subversion.tigris.org/project_issues.html). Il en résulta une baisse notable du nombre de rapports de bogues bidons. Nous en recevons encore bien sûr, nous en recevrons toujours, mais le taux a baissé considérablement et ce malgré l'augmentation du nombre d'utilisateurs. En conséquence, non seulement notre base de données contient moins de déchets, mais ceux qui travaillent à résoudre les bogues conservent leur bonne humeur et ont plus de chances de rester aimables au moment de répondre à l'un de ces rares rapports bidons. L'image du projet n'en est que meilleure et la santé mentale des volontaires est épargnée.
+
Le formatage peut apporter un réel plus. Par exemple, dans le projet Subversion nous avions un succès limité avec l'utilisation de la technique de filtrage de bogues décrite dans la section « Filtrer le système de suivi des bogues en amont » du [[POSSFR_Chap_3|Chapitre 3, Infrastructure technique]]. De nombreux rapports de bogues bidons étaient créés par des gens inexpérimentés et, chaque fois que cela se produisait, il fallait former le rapporteur exactement de la même manière que les 500 rapporteurs précédents. Un jour, alors qu'un de nos développeurs avait fini par perdre patience et s'en était pris à un pauvre utilisateur qui n'avait pas lu assez attentivement le manuel du traqueur de bogues un autre développeur décida que la situation avait assez durée. Il proposa une refonte de la page d'accueil du traqueur de bogues pour faire ressortir en gros caractères rouge et gras sur fond jaune, bien centrés en tête de page, le point le plus important, à savoir l'incitation à discuter du bogue sur la liste de diffusion et sur le canal IRC avant de remplir un rapport. Ce qui fut fait (vous pouvez voir le résultat sur http://subversion.tigris.org/project_issues.html). Il en résulta une baisse notable du nombre de rapports de bogues bidons. Nous en recevons encore bien sûr, nous en recevrons toujours, mais le taux a baissé considérablement et ce malgré l'augmentation du nombre d'utilisateurs. Ainsi, non seulement notre base de données contient moins de déchets, mais ceux qui travaillent à résoudre les bogues conservent leur bonne humeur et ont plus de chance de rester aimables au moment de répondre à l'un de ces rares rapports bidons. L'image du projet n'en est que meilleure et la santé mentale des volontaires est épargnée.
-
La leçon que nous en avons tirée est qu'il ne suffit pas simplement de mettre les règles par écrit. Il faut également les rendre visibles à ceux qui en ont le plus besoin et les présenter de telle sorte que leur rôle de support d'introduction au projet soit suffisamment clair pour ceux qui ne connaissaient pas le projet.
+
Conclusion : il ne suffit pas simplement de mettre les règles par écrit. Il faut également les rendre visibles à ceux qui en ont le plus besoin et les présenter de telle sorte que leur rôle de support d'introduction au projet soit suffisamment clair pour ceux qui ne connaissaient pas le projet.
-
Des pages Web statiques ne sont pas le seul espace pour promouvoir les us et coutumes du projet. Une certaine dose de surveillance interactive (dans le sens de « rappel amical » plutôt que de « mettre à l'amende ») est également nécessaire. Toute révision par les pairs, y compris les révisions de commit décrites dans la section intitulée « Effectuez une inspection visible du code » du Chapitre 2, Bien démarrer, devraient inclure le passage en revue de la conformité ou non conformité aux normes, notamment en ce qui concerne les conventions de communication.
+
Des pages Web statiques ne sont pas les seuls espaces pour promouvoir les us et coutumes du projet. Une certaine dose de veille interactive (dans le sens de « rappel amical » plutôt que de « mettre à l'amende ») est également nécessaire. Toute révision par les pairs, y compris les révisions de commit décrites dans la section intitulée « Effectuez une inspection visible du code » du [[POSSFR_Chap_2|Chapitre 2, Bien démarrer]], devraient commenter le respect des normes du projet, notamment des conventions de communication.
-
Voici un autre exemple tiré du projet Subversion : nous avons fixé par convention que « r12908 » signifait « révision 12908 dans le dépôt de gestion de version ». Le préfixe en bas de casse « r » est facile à taper et sa taille étant moitié moindre que celle des chiffres on obtient un bloc de texte facilement reconnaissable. Bien sûr, le fait de fixer cette convention n'implique pas que tout le monde va l'utiliser immédiatement et uniformément. Ainsi, quand arrive un message de commit avec un message du fichier journal comme celui-ci :
+
Voici un autre exemple tiré du projet Subversion : nous avons fixé par convention que « r12908 » signifait « révision 12908 dans le dépôt de gestion de version ». Le préfixe en bas de casse « r » est facile à taper et sa taille étant moitié moindre que celle des chiffres on obtient un bloc de texte facilement reconnaissable. Bien sûr, le fait de fixer cette convention n'implique pas que tout le monde va l'utiliser immédiatement et uniformément. Ainsi, quand arrive un message de commit avec un message du fichier journal tel que celui-ci :
  ------------------------------------------------------------------------
  ------------------------------------------------------------------------
Ligne 415 : Ligne 416 :
  ------------------------------------------------------------------------
  ------------------------------------------------------------------------
-
...la relecture de ce commit comprend également un petit mot du genre : "« Au fait, utilisez de préférence 'r12828' au lieu de 'révision 12828' pour parler des changements précédents. » Ce n'est pas juste de la pédanterie : c'est aussi important pour l'indexation automatique que pour la lisibilité humaine.
+
...la relecture de ce commit comprend également un petit mot du genre : « Au fait, utilisez de préférence 'r12828' au lieu de 'révision 12828' pour parler des changements précédents. » Ce n'est pas juste de la pédanterie : c'est aussi important pour l'indexation automatique que pour la lisibilité humaine.
-
En suivant le principe général selon lequel il devrait y avoir une méthode étalon de référence pour des unités communes et que ces méthodes de référence devraient être utilisées partout uniformément, le projet exporte de manière effective certaines normes. Ces normes permettent aux gens d'écrire des outils qui permettent de présenter les échanges du projet sous une forme plus exploitable. Une révision sous la forme « r12828 » peut être transformée en lien vivant dans le système de navigation du dépôt par exemple. Ceci serait plus difficile à faire si la révision avait été notée sous la forme « révision 12828 », d'une part parce que cette expression aurait pu être divisée par un retour à la ligne et d'autre part parce qu'elle est moins distincte (le mot révision, avec ou sans accent, apparaîtra souvent isolé des chiffres, tandis que la combinaison « r12828 » ne peut que signifier « numéro de révision »). Des problèmes similaires se posent pour les numéros d'émissions, les points de la FAQ (une piste : utilisez des URL avec des ancres nommées, comme indiqué dans « Ancres nommées et attributs ID »), etc.
+
En suivant le principe général selon lequel il devrait y avoir une méthode de référence pour des unités communes et que ces méthodes de référence devraient être utilisées partout uniformément, le projet exporte de manière effective certaines normes. Ces normes permettent aux gens d'écrire des outils qui rendet l'exploitation des échanges du projet plus aisée. Une révision sous la forme « r12828 » peut être transformée en lien vivant dans le système de navigation du dépôt par exemple. Ceci serait plus difficile à faire si la révision avait été notée sous la forme « révision 12828 », d'une part parce que cette expression aurait pu être divisée par un retour à la ligne et d'autre part parce qu'elle est moins distincte (le mot révision, avec ou sans accent, apparaîtra souvent isolé des chiffres, tandis que la combinaison « r12828 » ne peut que signifier « numéro de révision »). Des problèmes similaires se posent pour les numéros d'émissions, les points de la FAQ (une piste : utilisez des URL avec des ancres nommées, comme indiqué dans « Ancres nommées et attributs ID »), etc.
-
Même pour les unités où il n'y a pas d'étalon défini les gens devraient être encouragés à fournir les informations clés de manière uniformisée. Par exemple pour vous référer à un message d'une liste de diffusion ne mentionnez pas seulement l'émetteur et le sujet : citez également l'URL de l'archive et le Message-ID de l'en-tête. Ce dernier permet à ceux qui ont leur propre copie de la liste de diffusion (certaines personnes conservent une copie hors ligne, pour l'utiliser sur un portable lors d'un voyage par exemple) d'identifier univoquement le message même s'ils n'ont pas accès aux archives. L'émetteur et le sujet ne suffisent pas car la même personne peut avoir posté plusieurs fois le même jour dans le même fil.
+
Même pour les unités où il n'y a pas d'étalon défini les gens devraient être encouragés à fournir les informations clés de manière uniformisée. Par exemple pour vous référer à un message d'une liste de diffusion ne mentionnez pas seulement l'émetteur et le sujet, citez également l'URL de l'archive et le Message-ID de l'en-tête. Ce dernier permet à ceux qui ont leur propre copie de la liste de diffusion (certaines personnes conservent une copie hors ligne, pour l'utiliser sur un portable lors d'un voyage par exemple) d'identifier univoquement le message même s'ils n'ont pas accès aux archives. L'émetteur et le sujet ne suffisent pas car la même personne peut avoir posté plusieurs fois le même jour dans le même fil.
-
Plus un projet grandit plus cette uniformité devient importante. Uniformité signifie que, quel que soit l'endroit, les mêmes règles sont appliquées, ce qui incite les gens à suivre ces mêmes règles. Ceci, en retour, réduit le nombre de questions qu'ils ont à poser. La charge d'avoir un million de lecteurs n'est pas plus grande que celle d'en avoir un ; les problèmes d'échelle commencent à se poser seulement quand un certain pourcentage de ces lecteurs posent des questions. Quand le projet grandit il faut donc réduire ce pourcentage en augmentant la densité et l'accessibilité de l'information pour que chaque personne ait plus de chance de trouver ce dont elle a besoin sans avoir à le demander.
+
Plus un projet grandit plus cette uniformité devient importante. Grâce à l'uniformité, quelle que soit la situation, les mêmes règles sont appliquées, ce qui incite les gens à suivre ces mêmes règles. Ceci, en retour, réduit le nombre de questions qu'ils ont à poser. Avoir 1 lecteur ou 1 million de lecteur ne fait pas de différence ; les problèmes d'échelle commencent à apparaître seulement quand un certain pourcentage de ces lecteurs posent des questions. Quand le projet grandit il faut donc réduire ce pourcentage en augmentant la densité et l'accessibilité de l'information pour que chaque personne ait plus de chance de trouver ce dont elle a besoin sans avoir à le demander.
-
== Pas de discussions dans le système de suivi de bogues ==
+
== Pas de discussions dans le système de suivi de bogues ==
-
Dans tous les projets qui font un usage actif d'un système de suivi de bogues existe le danger que celui-ci devienne un forum de discussion en lui-même, malgré l'intérêt que présentent les listes de diffusion. Généralement cela commence innocemment : quelqu'un note un problème et, disons, propose une solution ou un correctif partiel. Quelqu'un d'autre le remarque, se rend compte que la solution proposée n'a pas que du bon et attache une autre note indiquant ces problèmes. La première personne répond en ajoutant une note sur la question... et ainsi de suite.
+
Dans tous les projets qui font un usage actif d'un système de suivi de bogues existe le danger que celui-ci devienne un forum de discussion en lui-même, malgré la présence des listes de diffusion. Généralement cela commence innocemment : quelqu'un note un problème et propose une solution ou un correctif partiel. Quelqu'un d'autre le remarque, se rend compte que la solution proposée n'a pas que du bon et attache une autre note indiquant ces problèmes. La première personne répond en ajoutant une note sur la question... et ainsi de suite.
Le problème est que, premièrement, le système de suivi de bogues est un endroit trop encombré pour y mener une discussion et, deuxièmement, les autres peuvent ne pas y prêter attention car ils s'attendent à ce que les discussions sur le développement aient lieu sur la liste « développement », c'est donc là qu'ils regarderont. Il est possible qu'ils ne soient même pas abonnés à la liste « résolution de problèmes » et, même s'ils le sont, ils ne suivent peut-être pas de près ce qu'il s'y passe.
Le problème est que, premièrement, le système de suivi de bogues est un endroit trop encombré pour y mener une discussion et, deuxièmement, les autres peuvent ne pas y prêter attention car ils s'attendent à ce que les discussions sur le développement aient lieu sur la liste « développement », c'est donc là qu'ils regarderont. Il est possible qu'ils ne soient même pas abonnés à la liste « résolution de problèmes » et, même s'ils le sont, ils ne suivent peut-être pas de près ce qu'il s'y passe.
Ligne 431 : Ligne 432 :
Mais à quel moment précis du processus quelque chose est allé de travers ? Est-ce quand la personne du début a ajouté sa solution à l'endroit où le problème était décrit : aurait-elle dû plutôt la poster sur la liste ? où est-ce quand la deuxième personne a répondu au même endroit plutôt que sur la liste ?
Mais à quel moment précis du processus quelque chose est allé de travers ? Est-ce quand la personne du début a ajouté sa solution à l'endroit où le problème était décrit : aurait-elle dû plutôt la poster sur la liste ? où est-ce quand la deuxième personne a répondu au même endroit plutôt que sur la liste ?
-
Il n'y a pas qu'une bonne réponse, mais il existe un principe général : si vous ajoutez des données sur un sujet faites-le sur le système de suivi, mais si vous démarrez une discussion faites-le sur la liste. Vous ne serez peut-être pas toujours en mesure de déterminer dans quelle catégorie ranger votre intervention, mais suivez votre jugement. Par exemple, au moment de joindre un correctif qui contient une solution qui peut prêter à controverse, vous devez anticiper le fait que les gens auront des questions à poser. Donc, même si vous auriez trouvé normal de joindre le correctif à la description du problème (en supposant que vous ne voulez ou ne pouvez pas valider le changement directement), vous devriez plutôt choisir de le poster sur la liste de diffusion. De toute façon, les échanges aboutiront à un point où l'une des parties dira que cela va plus loin que l'ajout pur et simple de données et qu'il faut une vraie discussion; dans l'exemple qui ouvre cette partie, ce serait à celui qui répond en deuxième, en comprenant qu'il y a des problèmes sur le correctif, de prévoir qu'il en découlera une vraie discussion et qu'elle doit avoir lieu sur le support approprié.
+
Plutôt qu'une unique bonne réponse, voici un principe général : si vous ajoutez des données à un sujet faites-le sur le système de suivi, mais si vous démarrez une discussion faites-le sur la liste. Vous ne serez peut-être pas toujours en mesure de déterminer dans quelle catégorie ranger votre intervention, mais suivez votre jugement. Par exemple, au moment de joindre un correctif qui contient une solution qui peut prêter à controverse, vous devez anticiper le fait que les gens auront des questions à poser. Donc, même si vous auriez trouvé normal de joindre le correctif à la description du problème (en supposant que vous ne voulez ou ne pouvez pas valider le changement directement), vous devriez plutôt choisir de le poster sur la liste de diffusion. De toute façon, les échanges aboutiront à un point où l'une des parties dira que cela va plus loin que l'ajout pur et simple de données et qu'il faut une vraie discussion; dans l'exemple qui ouvre cette partie, ce serait à celui qui répond en deuxième, en comprenant qu'il y a des problèmes sur le correctif, de prévoir qu'il en découlera une vraie discussion et qu'elle doit avoir lieu sur le support approprié.
-
Pour utiliser une analogie mathématique : si l'information semble rapidement convergente, mettez la directement dans le système de suivi de bogues ; si elle a l'air divergente, la liste de discussion ou le canal IRC semblent mieux appropriés.
+
Pour utiliser une analogie mathématique : si l'information vous semble pouvoir converger rapidement mettez la directement dans le système de suivi de bogues ; si elle a l'air divergente, la liste de discussion ou le canal IRC semblent mieux appropriés.
-
Ceci ne veut pas dire qu'il ne devrait jamais y avoir d'échanges dans le système de suivi. Demander des détails supplémentaires sur la façon de reproduire le bogue au rapporteur initial est un processus hautement convergent, par exemple. La réponse de la personne a peu de chances de soulever de nouvelles questions ; cela ne fait qu'étayer l'information référencée précédemment. Il n'y a pas lieu de perturber la liste avec ce processus. Essayez au maximum de régler cette question par une série de commentaires à même le système de suivi. De même, si vous êtes certain qu'un bogue a été rapporté à tort (c'est-à-dire qu'il ne s'agit pas d'un bogue), vous pouvez le dire directement sur le système de suivi. Même souligner un problème mineur à propos d'une solution proposée est acceptable, du moment que le problème en question ne compromet pas l'ensemble de la solution.
+
Ceci ne veut pas dire qu'il ne devrait jamais y avoir d'échanges dans le système de suivi. Demander des détails supplémentaires sur la façon de reproduire le bogue au rapporteur initial est un processus hautement convergent par exemple. La réponse de la personne a peu de chances de soulever de nouvelles questions ; cela ne fait qu'étayer l'information référencée précédemment. Il n'y a pas lieu de perturber la liste avec ce processus. Essayez au maximum de régler cette question par une série de commentaires à même le système de suivi. De même, si vous êtes certain qu'un bogue a été rapporté à tort (c'est-à-dire qu'il ne s'agit pas d'un bogue), vous pouvez le dire directement sur le système de suivi. Même souligner un problème mineur à propos d'une solution proposée est acceptable, du moment que le problème en question ne compromet pas l'ensemble de la solution.
D'un autre côté, si vous soulevez des questions philosophiques sur la portée d'un bogue ou sur le comportement correct du logiciel vous pouvez être sûr que d'autres développeurs voudront y participer. La discussion divergera vraisemblablement pendant un moment avant de converger de nouveau : menez-la donc sur la liste.
D'un autre côté, si vous soulevez des questions philosophiques sur la portée d'un bogue ou sur le comportement correct du logiciel vous pouvez être sûr que d'autres développeurs voudront y participer. La discussion divergera vraisemblablement pendant un moment avant de converger de nouveau : menez-la donc sur la liste.
Ligne 441 : Ligne 442 :
Donnez toujours des liens vers le système de suivi quand vous choisissez de poster sur la liste. Il est important que tous ceux qui suivent le bogue puissent accéder à la discussion même si l'endroit où il est rapporté n'est pas le lieu où se tient la discussion. La personne qui démarre le fil de discussion trouvera sans doute cela pénible, mais le milieu du logiciel libre est fondamentalement une culture de la responsabilité par l'écrit : il est bien plus important de faciliter le travail aux dizaines ou centaines de personnes qui liront le bogue qu'aux trois ou quatre qui écrivent dessus.
Donnez toujours des liens vers le système de suivi quand vous choisissez de poster sur la liste. Il est important que tous ceux qui suivent le bogue puissent accéder à la discussion même si l'endroit où il est rapporté n'est pas le lieu où se tient la discussion. La personne qui démarre le fil de discussion trouvera sans doute cela pénible, mais le milieu du logiciel libre est fondamentalement une culture de la responsabilité par l'écrit : il est bien plus important de faciliter le travail aux dizaines ou centaines de personnes qui liront le bogue qu'aux trois ou quatre qui écrivent dessus.
-
On peut aussi extraire des conclusions ou des résumés importants de la liste de discussion pour les coller dans le système de suivi si cela aide les lecteurs. Un usage courant consiste à commencer une discussion dans la liste en mettant un lien vers le rapport de bogue, puis, une fois la discussion finie, de coller le résumé dans le système de suivi (avec un lien vers le message qui contient le résumé, pour que ceux qui parcourent le suivi puissent voir facilement la conclusion à laquelle on est arrivé sans avoir à cliquer ailleurs. Notez que le problème courant des « deux originaux », problème de duplication des données, n'existe pas ici, car aussi bien les archives que les commentaires de bogue sont généralement des données statiques, non modifiables de toute façon.
+
On peut aussi extraire des conclusions ou des résumés importants de la liste de discussion pour les coller dans le système de suivi si cela aide les lecteurs. Un usage courant consiste à commencer une discussion dans la liste en mettant un lien vers le rapport de bogue, puis, une fois la discussion achevée, de coller le résumé dans le système de suivi (avec un lien vers le message qui contient le résumé, pour que ceux qui parcourent le suivi puissent voir facilement la conclusion à laquelle on est arrivé sans avoir à cliquer ailleurs. Notez que le problème courant des « deux originaux », problème de duplication des données, n'existe pas ici, car aussi bien les archives que les commentaires de bogue sont généralement des données statiques, non modifiables de toute façon.
== Les annonces ==
== Les annonces ==
-
Dans le monde des logiciels libres on passe facilement des discussions internes aux communiqués officiels. Cela est en partie dû au fait que l'on ne sait jamais exactement à quel publique on s'adresse : comme tous ou la plupart des messages sont accessibles publiquement le projet ne contrôle pas entièrement l'appréciation du public. Quelqu'un, disons un éditeur de slashdot.org, pourrait attirer l'attention de millions de lecteurs sur un message que personne ne s'attendait à voir sortir du projet. C'est un aléa de la vie avec lequel tous les projets Open Source doivent composer, mais dans la pratique le risque est d'habitude très faible. En général les annonces que le projet veut rendre publiques sont celles qui seront le plus mises en avant, à la condition que vous utilisiez les bons outils pour indiquer l'importance relative de votre communiqué au monde extérieur.
+
Dans le monde des logiciels libres la frontière entre discussions internes et communiqués officiels est ténue. C'est en partie dû au fait que l'on ne sait jamais exactement à quel publique on s'adresse : comme pratiquement tous les messages sont accessibles publiquement le projet ne contrôle pas entièrement l'appréciation du public. Quelqu'un, disons un éditeur de slashdot.org, pourrait attirer l'attention de millions de lecteurs sur un message que personne ne s'attendait à voir sortir du projet. C'est un aléa de la vie avec lequel tous les projets Open Source doivent composer, mais dans la pratique le risque est en général très faible. Habituellement les annonces que le projet veut rendre publiques sont celles qui seront le plus mises en avant, à condition que vous utilisiez les bons outils pour indiquer l'importance relative de votre communiqué au monde extérieur.
-
Pour les annonces majeures on peut distinguer quatre à cinq voies principales de distributions au travers desquelles les annonces devraient être faites autant simultanément que faire se peut :
+
Pour les annonces majeures on peut distinguer quatre à cinq canaux principaux de distribution au travers desquels les annonces devraient être faites aussi simultanément que faire se peut :
1. La page d'accueil de votre site Web est certainement la partie la plus visible du projet. Si vous devez faire une annonce particulièrement importante, affichez-y votre petit discours. Cela doit rester concis, un petit résumé qui renvoi vers le communiqué de presse (voir ci-dessous).
1. La page d'accueil de votre site Web est certainement la partie la plus visible du projet. Si vous devez faire une annonce particulièrement importante, affichez-y votre petit discours. Cela doit rester concis, un petit résumé qui renvoi vers le communiqué de presse (voir ci-dessous).
Ligne 453 : Ligne 454 :
2. Parallèlement, vous devriez avoir aussi une section « Nouvelles » ou « Communiqués de presse » sur votre site Web où vous pourrez afficher toutes les annonces en détail. Les communiqués de presse servent de vitrine vers laquelle les autres sites peuvent re-diriger leurs lecteurs. Assurez vous donc qu'ils soient structurés en fonction : soit sous la forme d'une page Web par communiqué, soit par un nouvel article distinct ou sous n'importe quelle forme tant que l'on peut y accéder grâce à un lien sans qu'il y ait confusion possible avec d'autres communiqués.
2. Parallèlement, vous devriez avoir aussi une section « Nouvelles » ou « Communiqués de presse » sur votre site Web où vous pourrez afficher toutes les annonces en détail. Les communiqués de presse servent de vitrine vers laquelle les autres sites peuvent re-diriger leurs lecteurs. Assurez vous donc qu'ils soient structurés en fonction : soit sous la forme d'une page Web par communiqué, soit par un nouvel article distinct ou sous n'importe quelle forme tant que l'on peut y accéder grâce à un lien sans qu'il y ait confusion possible avec d'autres communiqués.
-
3. Si vous avez créé un flux RSS pour votre projet, assurez vous qu'il relaie également l'annonce. Cela peut se faire automatiquement lorsque vous créez le communiqué de presse selon la configuration de votre site Web (Les flux RSS sont des outils pour distribuer des résumés de nouvelles contenant des meta-données aux « abonnés », c'est-à-dire aux personnes qui ont fait en sorte de recevoir ces résumés. Voir http://www.xml.com/pub/a/2002/12/18/dive-into-xml.html pour plus d'informations à propos des flux RSS).
+
3. Si vous avez créé un flux RSS pour votre projet, assurez vous qu'il relaie également l'annonce. Cela peut se faire automatiquement lorsque vous créez le communiqué de presse selon la configuration de votre site Web (les flux RSS sont des outils pour distribuer des résumés de nouvelles contenant des meta-données aux « abonnés », c'est-à-dire aux personnes qui ont fait en sorte de recevoir ces résumés. Voir http://www.xml.com/pub/a/2002/12/18/dive-into-xml.html pour plus d'informations à propos des flux RSS).
-
4. Si l'annonce que vous passez concerne une nouvelle version vous devez aussi modifier la page du projet sur http://freshmeat.net (voir la section nommée «  Annoncer » pour savoir comment créer cette page). Dès que vous modifier votre page sur Freshmeat la modification est annoncée sur la liste des changements du jour de Freshmeat. Cette liste est mise à jour sur Freshmeat mais aussi sur d'autres portails (slashdot.org compris) qui sont avidement surveillées par des hordes de gens. Freshmeat relaie également ces informations par son flux RSS. Ainsi, les gens qui ne sont pas abonnés à votre propre flux RSS pourront quand même recevoir l'annonce par celui de Freshmeat.  
+
4. Si l'annonce que vous passez concerne une nouvelle version vous devez aussi modifier la page du projet sur http://freshmeat.net (voir la section nommée «  Annoncer » pour savoir comment créer cette page). Dès que vous modifiez votre page sur Freshmeat la modification est annoncée sur la liste des changements du jour de Freshmeat. Cette liste est mise à jour sur Freshmeat mais aussi sur d'autres portails (slashdot.org compris) qui sont avidement surveillées par des hordes de gens. Freshmeat relaie également ces informations par son flux RSS. Ainsi, les gens qui ne sont pas abonnés à votre propre flux RSS pourront quand même recevoir l'annonce par celui de Freshmeat.  
-
5. Envoyer un e-mail à la liste de diffusion d'annonces de votre projet. Le nom de cette liste devrait d'ailleurs êtres « annonce », c'est-à-dire que l'adresse devrait être annonce@domaineduprojet.org parce que c'est devenu une règle standard maintenant et que la charte de la liste devrait annoncer clairement qu'elle engendrera l'envoi de peu de mails et qu'elle est réservée aux annonces du projet. La plupart des annonces concerneront les nouvelles versions du logiciel mais aussi à l'occasion d'autres évènements comme une collecte de fonds, la découverte d'une faille de sécurité (voir la section « Annoncer les failles de sécurité » plus tard dans ce chapitre) ou encore un bouleversement dans la vie du projet pourront y être postés. Parce qu'elle génère peut de trafic et qu'elle n'est employée que pour des choses importantes, la liste d'annonces possède en général le plus grand nombre d'abonnés parmi toutes les listes du projet (ce qui implique donc que vous ne devriez pas en abuser, tournez sept fois vos doigts au dessus du clavier avant d'y poster). Pour éviter que n'importe qui y fasse des annonces, ou pire encore, qu'elle serve à renvoyer des spams, la liste d'annonces doit toujours être modérée.
+
5. Envoyez un e-mail à la liste de diffusion d'annonces de votre projet. Le nom de cette liste devrait d'ailleurs êtres « annonce », c'est-à-dire que l'adresse devrait être annonce@domaineduprojet.org parce que c'est devenu une norme maintenant et la charte de la liste devrait annoncer clairement qu'elle engendrera l'envoi de peu de mails et qu'elle est réservée aux annonces du projet. La plupart des annonces concerneront les nouvelles versions du logiciel mais aussi à l'occasion d'autres évènements comme une collecte de fonds, la découverte d'une faille de sécurité (voir la section « Annoncer les failles de sécurité » plus tard dans ce chapitre) ou encore un bouleversement dans la vie du projet pourront y être postés. Parce qu'elle génère peut de trafic et qu'elle n'est employée que pour des choses importantes, la liste d'annonces possède en général le plus grand nombre d'abonnés parmi toutes les listes du projet (ce qui implique donc que vous ne devriez pas en abuser, tournez sept fois vos doigts au dessus du clavier avant d'y poster). Pour éviter que n'importe qui y fasse des annonces, ou pire encore, qu'elle serve à envoyer des spams, la liste d'annonces doit toujours être modérée.
Il faut que les annonces soient faites aussi simultanément que possible sur tous ces outils. Les gens pourraient trouver ça bizarre de voir l'annonce faite sur la liste de diffusion et de ne pas la retrouver sur la page d'accueil du projet ou dans la section « Communiqués de presse ». Si vous pouvez préparer les différentes modifications (e-mails, modifications de pages Web, etc.) et les envoyer d'un coup, les uns à la suite des autres, la période de « contradiction » pourra être largement réduite.
Il faut que les annonces soient faites aussi simultanément que possible sur tous ces outils. Les gens pourraient trouver ça bizarre de voir l'annonce faite sur la liste de diffusion et de ne pas la retrouver sur la page d'accueil du projet ou dans la section « Communiqués de presse ». Si vous pouvez préparer les différentes modifications (e-mails, modifications de pages Web, etc.) et les envoyer d'un coup, les uns à la suite des autres, la période de « contradiction » pourra être largement réduite.
Ligne 465 : Ligne 466 :
Vous verrez malgré tout cette date apparaître dans les discussions sur d'autres sites Internet, partout où des gens sont intéressés par votre projet. Les gens qui suivent votre liste de diffusion, qui ne font que la consulter sans jamais y participer, ne sont pas nécessairement muets ailleurs. Le bouche à oreille peut porter rapidement les nouvelles, vous devriez compter dessus et rédiger les annonces même mineures de manière à encourager la transmission exacte de l'information. En particulier, les messages que vous espérez voir cités devraient contenir une partie explicitement faite pour être citée, comme si vous écriviez un communiqué de presse officiel. Par exemple :
Vous verrez malgré tout cette date apparaître dans les discussions sur d'autres sites Internet, partout où des gens sont intéressés par votre projet. Les gens qui suivent votre liste de diffusion, qui ne font que la consulter sans jamais y participer, ne sont pas nécessairement muets ailleurs. Le bouche à oreille peut porter rapidement les nouvelles, vous devriez compter dessus et rédiger les annonces même mineures de manière à encourager la transmission exacte de l'information. En particulier, les messages que vous espérez voir cités devraient contenir une partie explicitement faite pour être citée, comme si vous écriviez un communiqué de presse officiel. Par exemple :
-
Quelque nouvelles sur l'avancement : nous pensons sortir la version 2.0 de Scanley vers la mi-août 2005. Nous vous invitons à consulter la page http://www.scanley.org/status.html régulièrement pour connaître les dernières nouvelles. La grosse nouveauté sera la recherche par expression habituelle.
+
:Quelque nouvelles sur l'avancement : nous pensons sortir la version 2.0 de Scanley vers la mi-août 2005. Nous vous invitons à consulter la page http://www.scanley.org/status.html régulièrement pour connaître les dernières nouvelles. La grosse nouveauté sera la recherche par expression habituelle.
-
    Parmi les autres nouvelles fonctionnalités vous retrouverez : ... Nous ajouterons également différentes corrections de bogues, à commencer par : ...
+
:Parmi les autres nouvelles fonctionnalités vous retrouverez : ... Nous ajouterons également différentes corrections de bogues, à commencer par : ...
Le premier paragraphe est succin et donne les deux informations principales (la date de sortie et la grande nouveauté) ainsi que l'URL à visiter pour plus d'informations. Si ce paragraphe est le seul à être repris vous aurez quand même réussi à passer l'information. Le reste du mail peut-être « oublié » sans amputer le message de son essence. Il y aura toujours des personnes qui mettront un lien vers le mail complet, mais il est aussi probable qu'ils n'en citeront qu'une partie. Puisque cette possibilité existe, autant leur simplifier la tâche et par la même occasion contrôler un peu mieux ce qui sera cité.
Le premier paragraphe est succin et donne les deux informations principales (la date de sortie et la grande nouveauté) ainsi que l'URL à visiter pour plus d'informations. Si ce paragraphe est le seul à être repris vous aurez quand même réussi à passer l'information. Le reste du mail peut-être « oublié » sans amputer le message de son essence. Il y aura toujours des personnes qui mettront un lien vers le mail complet, mais il est aussi probable qu'ils n'en citeront qu'une partie. Puisque cette possibilité existe, autant leur simplifier la tâche et par la même occasion contrôler un peu mieux ce qui sera cité.
Ligne 475 : Ligne 476 :
La gestion d'une faille de sécurité est différente de la gestion des autres rapports de bogue. Dans le logiciel libre, tout faire de manière ouverte et transparente relève presque du sacerdoce. Chaque étape d'une correction de bogue standard est visible aux yeux de tous ceux que cela intéresse : l'envoi du rapport initial, la discussion qui s'en suit et le correctif.
La gestion d'une faille de sécurité est différente de la gestion des autres rapports de bogue. Dans le logiciel libre, tout faire de manière ouverte et transparente relève presque du sacerdoce. Chaque étape d'une correction de bogue standard est visible aux yeux de tous ceux que cela intéresse : l'envoi du rapport initial, la discussion qui s'en suit et le correctif.
-
Les bogues de sécurité sont différents. Ils peuvent mettre en danger des données des utilisateurs voir même leur système entier. Parler de ce problème ouvertement reviendrait à lui faire de la publicité devant le monde entier, y compris ceux qui voudraient en faire un usage malveillant. Le simple fait d'envoyer un correctif annonce l'existence du bogue (des agresseurs potentiels surveillent les journaux de commit des projets publiques à la recherche de modifications qui indiquent des problèmes de sécurité). La plupart des projets Open Source se sont mis d'accord sur une série d'étapes à peu près standard pour gérer ce conflit entre ouverture et discrétion, elles sont basées sur ces quelques grandes lignes :
+
Les bogues de sécurité sont différents. Ils peuvent mettre en danger des données des utilisateurs voire même leur système entier. Parler de ce problème ouvertement alerterait tout le monde, y compris ceux qui voudraient en faire un usage malveillant. Le simple fait d'envoyer un correctif annonce l'existence du bogue (des agresseurs potentiels surveillent les journaux de commit des projets publiques à la recherche de modifications qui indiquent des problèmes de sécurité). La plupart des projets Open Source se sont mis d'accord sur une série d'étapes à peu près standard pour gérer ce conflit entre ouverture et discrétion, elles sont basées sur ces quelques grandes lignes :
   1. Ne pas parler du bogue en public tant qu'il n'y a pas de correctif disponible, fournir le correctif exactement au même moment où vous annoncez le bogue.
   1. Ne pas parler du bogue en public tant qu'il n'y a pas de correctif disponible, fournir le correctif exactement au même moment où vous annoncez le bogue.
Ligne 485 : Ligne 486 :
=== Réception du rapport ===
=== Réception du rapport ===
-
Il semble évident que pour commencer le projet doit pouvoir recevoir un rapport de bogue de sécurité de n'importe qui. Mais l'adresse normale pour rapporter les bogues n'est pas adaptée ici parce qu'elle peut être vue par tout le monde. Il vous faudra donc une adresse différente pour recevoir les rapports de bogue de sécurité. Les archives de cette liste de diffusion ne doivent pas être visibles publiquement et les abonnés doivent être triés, seuls les développeurs présents de longue date et surs peuvent être sur cette liste. S'il vous faut une définition plus concrète de « surs » voyez cela comme « toute personne qui possède l'accès de commit depuis deux ans au moins » ou quelque chose comme ça pour éviter le favoritisme. C'est le groupe qui devra gérer les failles de sécurité.
+
Pour commencer, le projet doit évidemment pouvoir recevoir un rapport de bogue de sécurité de n'importe qui. Mais l'adresse normale pour rapporter les bogues n'est pas adaptée ici parce qu'elle peut être vue par tout le monde. Il vous faudra donc une adresse différente pour recevoir les rapports de bogue de sécurité. Les archives de cette liste de diffusion ne doivent pas être visibles publiquement et les abonnés doivent être triés sur le volet, seuls les développeurs présents de longue date et surs peuvent être sur cette liste. S'il vous faut une définition plus concrète de « surs » voyez cela comme « toute personne qui possède l'accès de commit depuis deux ans au moins » ou quelque chose comme ça pour éviter le favoritisme. C'est le groupe qui devra gérer les failles de sécurité.
-
Idéalement cette liste de sécurité ne devrait pas être protégée du spam ou modérée ou alors vous risqueriez d'évincer un rapport important ou de le retarder parce qu'aucun modérateur n'était disponible ce week-end. Si par contre vous utilisez un logiciel pour vous prémunir du spam utilisez des réglages tolérants, il vaut mieux laisser passer quelques spams que de manquer un rapport. Pour que cette liste soit efficace vous devez évidemment rendre son adresse bien visible, mais comme elle ne sera pas modérée et qu'au mieux elle sera faiblement protégée contre le spam ne l'affichez jamais sans transformation, masquez la comme nous l'avons vu dans la section « Masquer les adresses dans les archives » dans le Chapitre 3, Infrastructure technique. Heureusement, le masquage de l'adresse ne la rend pas nécessairement illisible, voir http://subversion.tigris.org/security.html et jetez un oeil à son code source pour y trouver un exemple.
+
Idéalement cette liste de sécurité ne devrait pas être protégée du spam ou modérée ou alors vous risqueriez d'évincer un rapport important ou de le retarder parce qu'aucun modérateur n'était disponible ce week-end. Si par contre vous utilisez un logiciel pour vous prémunir du spam utilisez des réglages tolérants, il vaut mieux laisser passer quelques spams que de manquer un rapport. Pour que cette liste soit efficace vous devez évidemment rendre son adresse bien visible, mais comme elle ne sera pas modérée et qu'au mieux elle sera faiblement protégée contre le spam ne l'affichez jamais sans transformation, masquez la comme nous l'avons vu dans la section « Masquer les adresses dans les archives » dans le [[POSSFR_Chap_3|Chapitre 3, Infrastructure technique]]. Heureusement, le masquage de l'adresse ne la rend pas nécessairement illisible, voir http://subversion.tigris.org/security.html et jetez un œil à son code source pour y trouver un exemple.
=== Développer le correctif en secret ===
=== Développer le correctif en secret ===
-
Que doit donc faire la liste de sécurité quand elle reçoit un rapport ? La première chose à faire est d'évaluer la sévérité du problème et son urgence :
+
Que doit donc faire la liste de sécurité quand elle reçoit un rapport ? Elle doit en premier lieu évaluer la sévérité du problème et son urgence :
1. Quelle est la gravité de la vulnérabilité ? Est-ce qu'elle permet à un agresseur malintentionné de prendre le contrôle de l'ordinateur d'une personne utilisant le logiciel ? Ou ne fait-elle, par exemple, que divulguer des informations à propos de la taille de certains fichiers ?
1. Quelle est la gravité de la vulnérabilité ? Est-ce qu'elle permet à un agresseur malintentionné de prendre le contrôle de l'ordinateur d'une personne utilisant le logiciel ? Ou ne fait-elle, par exemple, que divulguer des informations à propos de la taille de certains fichiers ?
Ligne 497 : Ligne 498 :
2. Avec quelle facilité peut-on exploiter cette vulnérabilité ? Une attaque peut-elle être scriptée ou requiert-elle une connaissance détaillée, du raisonnement et de la chance ?
2. Avec quelle facilité peut-on exploiter cette vulnérabilité ? Une attaque peut-elle être scriptée ou requiert-elle une connaissance détaillée, du raisonnement et de la chance ?
   
   
-
3. Qui a rapporté le problème ? La réponse à cette question ne change pas la nature de la vulnérabilité évidemment, mais cela vous donne une idée du nombre de personnes qui pourraient être au courant. Si le rapport provient de l'un des développeurs du projet vous pouvez vous détendre un peu (mais seulement un peu), en effet, vous pouvez lui faire confiance pour ne pas l'avoir crié sur les toits. A l'opposé, si le rapport provient d'un mail de anonyme14@globalhackers.net vous devriez agir au plus vite. Cette personne vous a rendu service en vous informant du problème, mais vous n'avez aucune idée du nombre de personnes qu'elle a pu mettre au courant ou de combien de temps elle attendra avant d'exploiter la faille à grande échelle.
+
3. Qui a rapporté le problème ? La réponse à cette question ne change pas la nature de la vulnérabilité évidemment, mais cela vous donne une idée du nombre de personnes qui pourraient être au courant. Si le rapport provient de l'un des développeurs du projet vous pouvez vous détendre un peu (mais seulement un peu), en effet, vous pouvez lui faire confiance pour ne pas l'avoir ébruité. À l'opposé, si c'est un e-mail de anonyme14@globalhackers.net que vous recevez, vous devriez agir au plus vite. Cette personne vous a rendu service en vous informant du problème, mais vous n'avez aucune idée du nombre de personnes qu'elle a pu mettre au courant ou de combien de temps elle attendra avant d'exploiter la faille à grande échelle.
-
Comme vous l'avez remarqué, l'éventail d'urgence ne s'étend que de « urgent » et « extrêmement urgent ». Même si le rapport provient d'une source connue et inoffensive il peut très bien y avoir d'autres personnes sur le Net qui ont découvert le bogue depuis longtemps mais qui ne l'ont pas rapporté. Le seul cas de figure où il n'y a pas vraiment urgence est quand par sa nature le bogue ne pose pas de risque important de sécurité.
+
Comme vous l'avez remarqué, l'éventail d'urgence ne s'étend que de « urgent » à « extrêmement urgent ». Même si le rapport provient d'une source connue et inoffensive il peut très bien y avoir d'autres personnes sur le Net qui ont découvert le bogue depuis longtemps mais qui ne l'ont pas rapporté. Le seul cas de figure où il n'y a pas vraiment urgence est quand par sa nature le bogue ne pose pas de risque important de sécurité.
-
Et au fait, l'exemple de « anonyme14@globalhackers.net » n'est pas facétieux. Il est fort probable que vous receviez des rapports de bogues de personnes masquant leur identité et qui, par leurs mots ou leur comportement, n'établissent jamais clairement s'ils sont de votre côté ou contre vous. Cela n'a pas d'importance : s'ils vous ont rapporté la faille de sécurité ils se diront qu'ils vous ont fait une faveur et vous devriez répondre en conséquence. Remerciez les pour le rapport, donnez leur un délai dans lequel vous prévoyez de fournir un correctif public et gardez les dans la confidence. Parfois ils vous donneront une date, c'est une menace implicite de publier le bogue à une échéance donnée, que vous soyez prêt ou non. Ca peut ressembler à de l'intimidation, mais il faut plutôt y voir une action préventive, fruit de déceptions passées dues au manque de réactivité de fabricants de logiciels qui n'ont pas pris ces rapports de sécurité au sérieux. Quoiqu'il en soit vous ne pouvez pas vous permettre de simplement mettre cette personne de côté. Après tout, si le bogue est important, elle dispose des connaissances nécessaires pour vous causer de gros ennuis. Traiter ces rapporteurs correctement en espérant qu'ils en feront de même en retour.
+
Et au fait, l'exemple de « anonyme14@globalhackers.net » n'est pas facétieux. Il est fort probable que vous receviez des rapports de bogues de personnes masquant leur identité et qui, par leurs mots ou leur comportement, n'établissent jamais clairement s'ils sont de votre côté ou contre vous. Cela n'a pas d'importance : s'ils vous ont rapporté la faille de sécurité ils se diront qu'ils vous ont fait une faveur et vous devriez répondre en conséquence. Remerciez les pour le rapport, donnez leur un délai dans lequel vous prévoyez de fournir un correctif public et gardez les dans la confidence. Parfois ils vous donneront une date, c'est une menace implicite de publier le bogue à une échéance donnée, que vous soyez prêt ou non. Ça peut ressembler à de l'intimidation, mais il faut plutôt y voir une action préventive, fruit de déceptions passées dues au manque de réactivité de fabricants de logiciels qui n'ont pas pris ces rapports de sécurité au sérieux. Quoiqu'il en soit vous ne pouvez pas vous permettre d'ignorer cette personne. Après tout, si le bogue est important, elle dispose des connaissances nécessaires pour vous causer de gros ennuis. Traiter ces rapporteurs correctement en espérant qu'ils en feront de même en retour.
-
Un autre cas fréquent est le rapport de bogue rédigé par un professionnel en sécurité, quelqu'un qui gagne sa vie en inspectant les codes et qui garde toujours un &oelig;il sur les dernières vulnérabilités des logiciels. Ces personnes possèdent en général la double expérience d'avoir déjà reçu des rapports de bogues et d'en avoir envoyé aussi, sûrement plus que la plupart des développeurs de votre projet. Ils sont aussi coutumier des dates limites imposées avant lesquelles vous devez réparer le problème avant qu'il ne dévoile la faille au public. Dans certains cas vous pouvez négocier cette date, mais tout dépend du rapporteur. Le fait d'imposer une date limite s'est imposé petit à petit dans le monde des professionnels en sécurité comme le seul moyen sûr pour que les organisations répondent rapidement aux problèmes de sécurité. Ne voyez donc pas ces dates limites comme une pratique grossière, si cette manière de faire s'est imposée avec le temps c'est qu'il y a de bonnes raisons.
+
Un autre cas fréquent est le rapport de bogue rédigé par un professionnel en sécurité, quelqu'un qui gagne sa vie en inspectant les codes et qui garde toujours un œil sur les dernières vulnérabilités des logiciels. Ces personnes possèdent en général la double expérience d'avoir déjà reçu des rapports de bogues et d'en avoir envoyé aussi, sûrement plus que la plupart des développeurs de votre projet. Ils sont aussi coutumier des dates limites imposées avant lesquelles vous devez réparer le problème avant qu'il ne dévoile la faille au public. Dans certains cas vous pouvez négocier cette date, mais tout dépend du rapporteur. Le fait d'imposer une date limite s'est imposé petit à petit dans le monde des professionnels en sécurité comme le seul moyen sûr pour que les entreprises répondent rapidement aux problèmes de sécurité. Ne voyez donc pas ces dates limites comme une pratique grossière, si cette manière de faire s'est imposée avec le temps c'est qu'il y a de bonnes raisons.
Une fois la sévérité et l'urgence établis vous pouvez commencer à travailler sur le correctif. Il faut trouver le bon équilibre entre faire les choses avec élégance et faire les choses rapidement. C'est la raison pour laquelle il faut déterminer l'urgence de la situation avant de commencer. Il faut que la discussion concernant le correctif reste entre les membres de la liste de sécurité et le rapporteur initial (s'il veut être impliqué) et tout développeur dont les compétences seront nécessaires.
Une fois la sévérité et l'urgence établis vous pouvez commencer à travailler sur le correctif. Il faut trouver le bon équilibre entre faire les choses avec élégance et faire les choses rapidement. C'est la raison pour laquelle il faut déterminer l'urgence de la situation avant de commencer. Il faut que la discussion concernant le correctif reste entre les membres de la liste de sécurité et le rapporteur initial (s'il veut être impliqué) et tout développeur dont les compétences seront nécessaires.
-
N'enregistrez pas le correctif dans le dépôt. Il faut le garder à l'écart jusqu'à la date de publication. Si vous l'enregistriez, même avec un message de journal innocent, quelqu'un pourrait le remarquer et comprendre la modification. Vous n'êtes jamais sûr de qui surveille votre dépôt ni de ses motivations. Arrêter les e-mails de commit n'arrangerait rien, en premier lieu parce qu'un trou dans la suite des courriers serait suspicieux et de toute façon les données se retrouveraient dans le dépôt. Contentez vous de mener tout le développement hors du dépôt et conservez ce travail dans un endroit secret, pourquoi pas un dépôt privé, distinct, connu des seuls personnes déjà au courant du bogue (Si vous utilisez un logiciel de gestion de version décentralisé comme Arch ou SVK vous pouvez travailler sous gestion de version et simplement empêcher l'accès à ce dépôt aux personnes externes).
+
N'enregistrez pas le correctif dans le dépôt. Il faut le garder à l'écart jusqu'à la date de publication. Si vous l'enregistriez, même avec un message de journal innocent, quelqu'un pourrait le remarquer et comprendre la modification. Vous ne savez jamais qui surveille votre dépôt ou pour quelles raisons. Arrêter les e-mails de commit n'arrangerait rien, en premier lieu parce qu'un trou dans la suite des courriers serait suspicieux et de toute façon les données se retrouveraient dans le dépôt. Contentez vous de mener tout le développement hors du dépôt et conservez ce travail dans un endroit secret, pourquoi pas un dépôt privé, distinct, connu des seuls personnes déjà au courant du bogue (si vous utilisez un logiciel de gestion de version décentralisé comme Arch ou SVK vous pouvez travailler sous gestion de version et simplement empêcher l'accès à ce dépôt aux personnes externes).
=== Les numéros CAN/CVE ===
=== Les numéros CAN/CVE ===
Ligne 513 : Ligne 514 :
Vous avez déjà peut-être rencontré un numéro CAN ou CVE associé à un problème de sécurité. Il se présente en général sous cette forme : « CAN-2004-0397 » ou « CVE-2002-00923 ».
Vous avez déjà peut-être rencontré un numéro CAN ou CVE associé à un problème de sécurité. Il se présente en général sous cette forme : « CAN-2004-0397 » ou « CVE-2002-00923 ».
-
Ces deux types de numéros représentent la même chose : une entrée dans la liste des « Common Vulnerabilities and Exposures » ou « Vulnérabilités et Failles Classiques », cette liste est maintenue à l'adresse http://cve.mitre.org/. Son but est de fournir des noms standardisés pour tous les problèmes de sécurité connus afin que chacun ait un nom canonique unique que l'on peut employer pour le désigner et aussi de fournir un site de centralisation où l'on peut se rendre pour obtenir plus d'informations. La seule différence entre les numéros « CAN » et « CVE » est que le premier représente une demande d'inclusion (''candidate entry''), par encore approuvée pour l'ajout à la liste officielle par l'équipe rédactionnelle de CVE et que le dernier désigne une entrée approuvée. Ces deux types d'entrées sont de toute façon visible par le public et le numéro de l'entrée n'est pas modifié lorsqu'elle est approuvée, le préfixe « CAN » est simplement remplacé par « CVE ».
+
Ces deux types de numéros représentent la même chose : une entrée dans la liste des « Common Vulnerabilities and Exposures » ou « Vulnérabilités et Failles Courantes », cette liste est disponible à l'adresse http://cve.mitre.org/. Son but est de fournir des noms normalisés à tous les problèmes de sécurité connus afin que chacun ait un nom canonique unique que l'on peut employer pour le désigner et aussi de fournir un site de centralisation où l'on peut se rendre pour obtenir plus d'informations. La seule différence entre les numéros « CAN » et « CVE » est que le premier représente une demande d'inclusion (''candidate entry''), pas encore approuvée pour l'ajout à la liste officielle par l'équipe rédactionnelle de CVE et que le dernier désigne une entrée approuvée. Ces deux types d'entrées sont de toute façon visible par le public et le numéro de l'entrée n'est pas modifié lorsqu'elle est approuvée, le préfixe « CAN » est simplement remplacé par « CVE ».
Une entrée CAN/CVE ne renferme pas une description complète du bogue ou de comment s'en prémunir. On peut y trouver un bref résumé et une liste de liens vers des ressources externes (comme par exemple des archives de listes de diffusion) où peuvent se rendre les gens pour obtenir des informations plus détaillées. La vraie utilité de http://cve.mitre.org/ est de fournir un espace bien organisé dans lequel chaque vulnérabilité peut avoir un nom et où l'on peut trouver des liens vers des données plus complètes. Visitez la page http://cve.mitre.org/cgi-bin/cvename.cgi?name=2002-0092, vous y trouverez un exemple d'entrée. Attention, les références peuvent être très laconiques et les sources peuvent apparaître sous forme d'abréviations mystérieuses. Un glossaire des abréviations est cependant disponible : http://cve.mitre.org/cve/refs/refkey.html.
Une entrée CAN/CVE ne renferme pas une description complète du bogue ou de comment s'en prémunir. On peut y trouver un bref résumé et une liste de liens vers des ressources externes (comme par exemple des archives de listes de diffusion) où peuvent se rendre les gens pour obtenir des informations plus détaillées. La vraie utilité de http://cve.mitre.org/ est de fournir un espace bien organisé dans lequel chaque vulnérabilité peut avoir un nom et où l'on peut trouver des liens vers des données plus complètes. Visitez la page http://cve.mitre.org/cgi-bin/cvename.cgi?name=2002-0092, vous y trouverez un exemple d'entrée. Attention, les références peuvent être très laconiques et les sources peuvent apparaître sous forme d'abréviations mystérieuses. Un glossaire des abréviations est cependant disponible : http://cve.mitre.org/cve/refs/refkey.html.
-
Si votre vulnérabilité rempli les critères de CVE, vous pouvez postuler pour un numéro CAN. Le processus pour ce faire est délibérément fermé, vous devez connaître quelqu'un, ou quelqu'un qui connaît quelqu'un. Ce n'est pas aussi étrange que cela puisse paraître. Afin d'éviter que l'équipe rédactionnelle de CVE croule sous les demandes mal rédigées ils n'acceptent les soumissions que par des sources qu'ils connaissent et en qui ils ont confiance. Si vous souhaitez voir votre vulnérabilité listée vous devez donc d'abord trouver un intermédiaire entre votre projet et l'équipe rédactionnelle de CVE. Interrogez d'abord vos développeurs, il se peut très bien que l'un d'entre eux connaisse déjà quelqu'un qui serait passé par le processus CAN avant ou qu'il connaisse quelqu'un d'autre encore qui l'aurait déjà fait, etc. L'avantage de cette manière de procéder est que quelque part sur l'échelle de connaissances quelqu'un peut être suffisamment renseigné pour vous dire que a) votre demande ne répond pas aux critères de MITRE et que donc ce n'est pas la peine de la faire ou que b) cette vulnérabilité possède déjà un numéro CAN ou CVE. Ce dernier cas peut se produire si le bogue a déjà été publié sur une autre liste de sécurité, par exemple à l'adresse http://www.cert.org/ ou sur la liste de diffusion de BugTraq à l'adresse http://www.securityfocus.com/ (Si cela se produit sans que votre projet n'en entende parler alors vous devriez vous demander quels autres évènements vous avez loupés.)
+
Si votre vulnérabilité remplit les critères de CVE, vous pouvez postuler pour un numéro CAN. Le processus pour ce faire est délibérément fermé, vous devez connaître quelqu'un, ou quelqu'un qui connaît quelqu'un. Ce n'est pas aussi étrange que cela puisse paraître. Afin d'éviter que l'équipe rédactionnelle de CVE ne croule sous les demandes mal rédigées, ils n'acceptent les soumissions que par des sources de confiance. Si vous souhaitez voir votre vulnérabilité listée vous devez donc d'abord trouver un intermédiaire entre votre projet et l'équipe rédactionnelle de CVE. Interrogez d'abord vos développeurs, il se peut très bien que l'un d'entre eux connaisse déjà quelqu'un qui serait passé par le processus CAN avant ou qu'il connaisse quelqu'un d'autre encore qui l'aurait déjà fait, etc. L'avantage de cette manière de procéder est que quelque part sur l'échelle de connaissances quelqu'un peut être suffisamment renseigné pour vous dire que a) votre demande ne répond pas aux critères de MITRE et que donc ce n'est pas la peine de la faire ou que b) cette vulnérabilité possède déjà un numéro CAN ou CVE. Ce dernier cas peut se produire si le bogue a déjà été publié sur une autre liste de sécurité, par exemple à l'adresse http://www.cert.org/ ou sur la liste de diffusion de BugTraq à l'adresse http://www.securityfocus.com/ (si cela se produit sans que votre projet n'en entende parler alors vous devriez vous demander quels autres évènements vous avez loupés).
Si vous réussissez finalement à obtenir un numéro CAN/CVE il vaut mieux l'avoir tout au début de vos recherches concernant le bogue afin que toutes les communications ultérieures puissent se référer à ce numéro. Il y a un embargo sur les entrées CAN maintenu jusqu'à leur date de publication, l'entrée reste vide mais sert à réserver le numéro afin de ne pas le perdre, mais elle ne révélera aucune information à propos de la vulnérabilité jusqu'à la date à laquelle vous annoncerez le bogue et le correctif.
Si vous réussissez finalement à obtenir un numéro CAN/CVE il vaut mieux l'avoir tout au début de vos recherches concernant le bogue afin que toutes les communications ultérieures puissent se référer à ce numéro. Il y a un embargo sur les entrées CAN maintenu jusqu'à leur date de publication, l'entrée reste vide mais sert à réserver le numéro afin de ne pas le perdre, mais elle ne révélera aucune information à propos de la vulnérabilité jusqu'à la date à laquelle vous annoncerez le bogue et le correctif.
Ligne 531 : Ligne 532 :
Vous avez simplement besoin d'envoyer un mail à ces administrateurs avant la date de publication les informant de la vulnérabilité et des solutions. Vous ne devriez envoyer ces pré-notifications qu'aux personnes en qui vous avez confiance. Pour rentrer dans cette catégorie il y a deux conditions : le destinataire doit administrer un serveur important où un risque pourrait avoir des conséquences grave et le destinataire doit avoir la réputation de quelqu'un qui n'ira pas ébruiter le problème de sécurité avant la date de publication.
Vous avez simplement besoin d'envoyer un mail à ces administrateurs avant la date de publication les informant de la vulnérabilité et des solutions. Vous ne devriez envoyer ces pré-notifications qu'aux personnes en qui vous avez confiance. Pour rentrer dans cette catégorie il y a deux conditions : le destinataire doit administrer un serveur important où un risque pourrait avoir des conséquences grave et le destinataire doit avoir la réputation de quelqu'un qui n'ira pas ébruiter le problème de sécurité avant la date de publication.
-
Envoyez chaque mail de pré-notification individuellement (un par un) à chaque destinataire. Ne l'envoyez pas à une liste entière de destinataires en une fois parce qu'alors chacun verrait le nom des autres et ce serait comme les avertir que tous les autres destinataires ont peut-être une faille de sécurité sur leur serveur. Il ne faut pas non plus les envoyer en copie invisible (BCC pour Blind Carbon Copy) parce que les administrateurs protègent leurs boîtes de réception avec des filtres anti-spam qui bloquent ou abaissent la priorité des courriers reçus en BCC puisqu'énormément de spam est envoyé en BCC.
+
Envoyez chaque e-mail de pré-notification individuellement (un par un) à chaque destinataire. Ne l'envoyez pas à une liste entière de destinataires en une fois parce qu'alors chacun verrait le nom des autres et ce serait comme les avertir que tous les autres destinataires ont peut-être une faille de sécurité sur leur serveur. Il ne faut pas non plus les envoyer en copie invisible (BCC pour Blind Carbon Copy) parce que les administrateurs protègent leurs boîtes de réception avec des filtres anti-spam qui bloquent ou abaissent la priorité des courriers reçus en BCC puisqu'énormément de spam est envoyé en BCC.
Voici un exemple de mail de pré-notification :
Voici un exemple de mail de pré-notification :
Ligne 541 : Ligne 542 :
     Il est possible de faire exécuter des commandes au hasard au serveur
     Il est possible de faire exécuter des commandes au hasard au serveur
-
     si le serveur est mal configuré et que le client envoi une requête mal
+
     si le serveur est mal configuré et que le client envoie une requête mal
     conçue.
     conçue.
Ligne 562 : Ligne 563 :
[...insérer le correctif ici...]
[...insérer le correctif ici...]
-
Si vous avez un numéro CAN indiquez le dans la pré-notification (comme ci-dessus) même si l'information est toujours sous embargo est que la page MITRE est donc encore vide. En ajoutant le numéro CAN vous êtes sûr que le destinataire sait avec certitude que le bogue pour lequel vous lui envoyez la pré-notification est le même que celui dont il entendra parler un peu plus tard par voie publique. Ainsi il n'a pas à se demander s'il doit prendre d'autres mesures ou pas, ce qui est précisément le but des numéros CAN/CVE.
+
Si vous avez un numéro CAN indiquez le dans la pré-notification (comme ci-dessus) même si l'information est toujours sous embargo et que la page MITRE est donc encore vide. En ajoutant le numéro CAN vous êtes sûr que le destinataire sait avec certitude que le bogue pour lequel vous lui envoyez la pré-notification est le même que celui dont il entendra parler un peu plus tard par voie publique. Ainsi il n'a pas à se demander s'il doit prendre d'autres mesures ou pas, ce qui est précisément le but des numéros CAN/CVE.
=== Distribuez le correctif publiquement ===
=== Distribuez le correctif publiquement ===
-
La dernière chose qu'il vous reste à faire est de distribuer le correctif publiquement. Dans une annonce unique et complète vous devez décrire le problème, donner le numéro CAN/CVE s'il y en a un, décrire comment contourner le bogue et comment le régler définitivement. « Régler définitivement » implique souvent la mise à jour du logiciel même si parfois cela peut simplement vouloir dire appliquer un correctif, surtout si le logiciel est normalement utilisé sous forme de source. Si vous proposez une nouvelle version du logiciel, celle-ci ne doit différer de la précédente que par le correctif de sécurité. Ainsi les administrateurs plutôt conservateurs pourront faire la mise à jour sans se préoccuper d'autres conséquences. Ils n'ont pas à se soucier non plus des mises à jours futures puisqu'ils sauront que le correctif y sera également inclus (Les détails concernant les procédures de publication sont abordés dans la section nommée « Mises à jour de sécurité » dans le Chapitre 7, Création de paquets, sorties et développement quotidien).
+
La dernière chose qu'il vous reste à faire est de distribuer le correctif publiquement. Dans une annonce unique et complète vous devez décrire le problème, donner le numéro CAN/CVE s'il y en a un, décrire comment contourner le bogue et comment le régler définitivement. « Régler définitivement » implique souvent la mise à jour du logiciel même si parfois cela peut simplement vouloir dire appliquer un correctif, surtout si le logiciel est normalement utilisé sous forme de source. Si vous proposez une nouvelle version du logiciel, celle-ci ne doit différer de la précédente que par le correctif de sécurité. Les administrateurs plutôt conservateurs pourront ainsi faire la mise à jour sans se préoccuper d'autres conséquences. Ils n'ont pas à se soucier non plus des mises à jours futures puisqu'ils sauront que le correctif y sera également inclus (les détails concernant les procédures de publication sont abordés dans la section nommée « Mises à jour de sécurité » dans le [[POSSF_Chap_7|Chapitre 7, Création de paquets, sorties et développement quotidien]]).
-
Que le correctif public implique une nouvelle version ou pas, faites l'annonce avec plus ou moins la même priorité que vous le feriez pour une nouvelle version : envoyez un mail à la liste de diffusion d'annonces, écrivez un nouveau communiqué de presse, mettez à jour votre entrée sur Freshmeat, etc. Vous ne devriez jamais essayer de minimiser l'existence d'une faille de sécurité si vous vous souciez un tant soit peu de la réputation de votre projet mais gardez toujours à l'esprit qu'il faut adapter le ton et la visibilité d'une annonce de sécurité à la sévérité concrète du problème. Si le bogue de sécurité n'est qu'un risque mineur de révélation d'informations, pas une faille qui permettrait la prise de contrôle totale de l'ordinateur de l'utilisateur alors il ne devrait faire tant de bruit. Vous n'aurez peut-être même pas besoin de déranger la liste d'annonce pour ça. Après tout, si le projet cri au loup à chaque fois, les utilisateurs finiront par croire que le logiciel est moins sécurisé qu'il ne l'est vraiment et pourront également ne pas vous croire si vous avez un vrai problème à annoncer. Voir http://cve.mitre.org/about/terminology.html, cette page constitue une bonne introduction à la détermination de la sévérité d'un bogue.
+
Que le correctif public implique une nouvelle version ou pas, faites l'annonce avec plus ou moins la même priorité que vous le feriez pour une nouvelle version : envoyez un mail à la liste de diffusion d'annonces, écrivez un nouveau communiqué de presse, mettez à jour votre entrée sur Freshmeat, etc. Vous ne devriez jamais essayer de minimiser l'existence d'une faille de sécurité si vous vous souciez un tant soit peu de la réputation de votre projet mais gardez toujours à l'esprit qu'il faut adapter le ton et la visibilité d'une annonce de sécurité à la sévérité concrète du problème. Si le bogue de sécurité n'est qu'un risque mineur de révélation d'informations, pas une faille qui permettrait la prise de contrôle totale de l'ordinateur de l'utilisateur alors il ne devrait pas faire tant de bruit. Vous n'aurez peut-être même pas besoin de déranger la liste d'annonce pour ça. Après tout, si le projet cri au loup à chaque fois, les utilisateurs finiront par croire que le logiciel est moins sécurisé qu'il ne l'est vraiment et pourront également ne pas vous croire si vous avez un vrai problème à annoncer. Voir http://cve.mitre.org/about/terminology.html, cette page constitue une bonne introduction à la détermination de la sévérité d'un bogue.
De manière générale, si vous n'êtes pas certain des suites à donner à un problème de sécurité, trouvez quelqu'un d'expérience avec qui vous pourrez en discuter. Évaluer et gérer les vulnérabilités ne s'apprend pas du jour au lendemain et il est courant de faire des erreurs les premières fois.
De manière générale, si vous n'êtes pas certain des suites à donner à un problème de sécurité, trouvez quelqu'un d'expérience avec qui vous pourrez en discuter. Évaluer et gérer les vulnérabilités ne s'apprend pas du jour au lendemain et il est courant de faire des erreurs les premières fois.

Version du 14 avril 2009 à 19:29

Sommaire

Chapitre 6 : Communication

La capacité à écrire avec clarté est peut-être la qualité la plus importante que l'on peut avoir dans un environnement Open Source. Sur le long terme, elle compte plus que les compétences en programmation. Un programmeur génial ayant de piètres capacités en terme de communication ne peut s'occuper que d'une chose à la fois et il n'est même pas certain d'obtenir l'attention désirée. Mais un piètre programmeur doué en communication peut coordonner et convaincre plusieurs personnes de faire plusieurs choses différentes, tout en ayant un impact significatif sur la direction et l'intensité du projet.

Savoir bien communiquer et savoir produire du bon code sont deux choses différentes. Un bon programmeur saura bien décrire les questions techniques, mais décrire les questions techniques ne représente qu'une infime partie du travail de communication que requiert le projet. Savoir s'identifier à son auditoire, voir ses propres messages et commentaires comme les autres les voient et amener les autres à percevoir ses propres messages avec la même objectivité est bien plus important. Se rendre compte qu'un support ou qu'un processus de communication ne fonctionne plus correctement parce qu'il n'est plus adapté au nombre grandissant d'utilisateurs par exemple et prendre le temps d'y remédier est tout aussi important.

Tout ceci est évident d'un point de vue théorique, ce qui complique les choses en pratique c'est que les environnements de développement de logiciel libre offrent une variété déconcertante de publics et de mécanismes de communication. Faut-il exprimer telle remarque par un message dans la liste de discussion, sous la forme d'une note dans le traqueur de bogues ou d'un commentaire dans le code ? Pour répondre à une question dans un forum public, quel degré de connaissance faut-il supposer de la part du lecteur étant donné que « le lecteur » n'est pas seulement celui qui a posé la question au départ mais tous ceux qui pourront lire la réponse ? Comment les développeurs peuvent-ils rester en contact de manière constructive avec les utilisateurs sans être submergés de demandes sur les fonctionnalités, de rapports de bogue infondés et de discussions généralistes ? Comment déterminer le moment où un support a atteint la limite de ses capacités et que faire pour y remédier ? Les solutions à ces problèmes sont souvent ponctuelles, car toute solution particulière est à l'occasion rendue obsolète quand le projet grandit ou que sa structure évolue. Elles sont souvent ad hoc, car ce sont des réponses improvisées à des situations dynamiques. Tous les participants doivent être attentifs aux communications qui s'enlisent, quand et comment. Et ils doivent être impliqués dans les solutions. Aider les gens dans ce sens est une part importante de la gestion d'un projet Open Source. Dans les sections suivantes nous verrons comment gérer votre propre communication et comment faire du maintien des mécanismes de communication une priorité pour chacun des membres du projet [18].

Vous êtes ce que vous écrivez

C'est un fait : les gens sur Internet ne vous connaissent qu'au travers vos écrits ou de ce que les autres écrivent sur vous. Vous pouvez être brillant, subtil et charismatique en personne mais si vos courriels sont décousus et mal structurés les gens supposeront que vous êtes réellement ainsi. Ou alors vous êtes réellement décousu et mal structuré en chair et en os, mais personne n'aura à le savoir du moment que vos messages sont clairs et informatifs.

Rédiger vos messages avec soin sera toujours payant. Jim Blandy, hacker de logiciel libre de longue date, raconte l'histoire suivante :

En 1993, je travaillais pour la Free Software Foundation et nous étions en train de faire des bêta tests pour la version 19 de GNU Emacs. Nous sortions une version bêta par semaine à peu près pour que les gens l'essaient et nous envoient des rapports de bogue. Il y avait ce gars qu'aucun de nous n'avait rencontré personnellement mais qui avait fait du gros boulot : ses rapports de bogue étaient toujours clairs et nous menaient droit au problème et quand il proposait une correction c'était presque toujours correct. Il était vraiment bon.

Or, avant d'utiliser le code écrit par quelqu'un d'autre, la FSF fait signer un papier stipulant que l'auteur cède ses droits sur ce bout de code à la FSF. Se contenter d'injecter le code de parfaits inconnus mène de manière certaine à un désastre juridique.

Donc, j'envoyais les formulaires à ce gars en disant : « Voici quelques papiers dont nous avons besoin, voici ce qu'ils veulent dire, signez celui-ci, faites signer cet autre à votre employeur, après quoi nous pourrons intégrer vos corrections. Merci beaucoup. »

Il me renvoya un message qui disait : « Je n'ai pas d'employeur. »

Je répondis : « Pas de problème, faites le signer par votre université et renvoyez le nous. »

Après un certains temps, il m'écrivit ceci : « En fait... j'ai treize ans et j'habite chez mes parents. »

Ce jeune, parce qu'il n'écrivait pas comme un gamin de treize ans, personne ne se doutait de son âge réel. Ce qui suit présente quelques moyens pour que vos écrits aussi fassent bonne impression.

Structure et format

Ne tombez pas dans la facilité en utilisant le langage SMS. Faites des phrases complètes, utilisez des majuscules en début de phrase et aérez le texte en revenant à la ligne pour les nouveaux paragraphes. C'est particulièrement important pour les e-mails ou tout autre texte long que vous aurez à écrire. Sur IRC ou d'autres forums éphémères on peut se passer des majuscules, on peut utiliser des abréviations pour les expressions courantes, etc. Évitez simplement de garder ces habitudes sur les forums persistants plus formels. Les e-mails, la documentation, les rapports de bogue ou tout autre texte n'ayant pas une durée de vie limitée doivent être rédigés en respectant les règles d'orthographe et de grammaire et doivent avoir une structure narrative cohérente. Ce n'est pas pour le plaisir de suivre des règles arbitraires, ces règles justement ne sont pas arbitraires : elles ont évolué jusqu'à leur forme présente parce qu'elles rendent le texte plus lisible et vous devriez vous y tenir précisément pour cette raison. La lisibilité est importante non seulement parce que cela veut dire que plus de gens comprendront ce que vous écrivez mais aussi parce que cela montre que vous êtes le type de personne qui prend le temps de communiquer clairement : quelqu'un digne d'intérêt. Pour les e-mails en particulier, des développeurs Open Source expérimentés ont mis au point certaines conventions :

Envoyez vos mails sous forme de texte uniquement, pas d'HTML, pas de texte enrichi ou d'autres formats que pourraient ne pas comprendre certains logiciels de messagerie. Formatez les lignes pour qu'elles fassent environ 72 colonnes de large. Ne dépassez pas 80 colonnes, taille qui s'est imposée comme la largeur standard des terminaux (certaines personnes peuvent utiliser des terminaux plus larges, mais personne n'utilise de terminal moins large). En écrivant vos e-mails en moins de 80 colonnes vous laissez de l'espace pour l'insertion de quelques niveaux de caractères de citation qui seront ajoutés dans les réponses des autres participants sans perdre la mise en forme de votre texte.

Utilisez de vrais retours à la ligne. Certaines messageries utilisent une sorte de fausse mise en page qui fait que quand vous composez votre e-mail les retours à la ligne s'affichent mais sans être vraiment là. Quand vous envoyez votre e-mail, ces retours à la ligne que vous pensiez avoir insérés peuvent manquer et la mise en page sera étrange chez certaines personnes. Si votre messagerie utilise de faux retours à la ligne regardez s'il n'y a pas une option que vous pouvez cocher pour qu'elle montre les vrais retours à la ligne lorsque vous écrivez.

Lorsque vous ajoutez les résultats d'une commande, des fragments de code ou tout autre texte préformaté, marquez un décalage prononcé pour qu'ainsi même les plus myopes puissent distinguer la frontière entre votre prose et le texte cité (je ne prévoyais pas d'ajouter ce conseil lorsque j'ai commencé ce livre, mais j'ai récemment observé sur plusieurs listes de diffusion des gens mélanger du texte provenant de différentes sources sans marquer de distinction claire entre le texte et le code. Le résultat est très frustrant. Les messages sont moins clairs et ça donne une mauvaise impression de ces personnes).

Lorsque vous citez l' e-mail de quelqu'un d'autre, insérez vos réponses là où elles sont attendues, en plusieurs endroits si besoin, et retirez les parties de l'e-mail original qui vous sont inutiles. Vous pouvez répondre directement (c'est-à-dire donner votre réponse directement au-dessus du texte cité) si vous rédigez un commentaire rapide qui s'applique au message entier. Autrement, vous devriez citer les parties pertinentes du texte original suivies de vos réponses.

Réfléchissez bien à la ligne « Sujet » lorsque vous écrivez un nouvel e-mail. C'est la ligne la plus importante de votre courrier car elle permet à chaque participant du projet de décider s'il doit le lire ou non. Les logiciels de messagerie modernes organisent les messages liés en un fil de discussion qui peut être défini non seulement par un sujet commun mais aussi par d'autres en-têtes (qui ne sont pas toujours visibles). Par conséquent, si un fil commence à dévier vers un autre sujet vous pouvez, et devez, modifier le sujet en fonction lorsque vous répondez. L'intégrité du fil de discussion sera préservée grâce aux autres en-têtes mais le nouveau sujet permettra aux personnes observant le fil de loin de savoir que le sujet a dérivé. De même, si vous voulez vraiment aborder un nouveau sujet commencez avec un nouveau courrier, ne vous contentez pas de répondre à un e-mail précédent en modifiant simplement le sujet. Si vous faites cela votre e-mail sera toujours groupé dans le même fil que celui auquel vous répondiez et induira les gens en erreur. Encore une fois, ce n'est pas qu'un problème de perte de temps, votre crédibilité de personne maîtrisant les outils de communication s'en retrouvera affectée.

Contenu

Des e-mails bien écrits attirent les lecteurs, mais c'est le contenu qui garde leur attention. Il n'y a évidemment aucune formule magique à ce niveau là, mais respecter quelques principes sera déjà un bon début. Facilitez la vie de vos lecteurs. Dans tous les projets Open Source actifs des tonnes d'informations sont générées et vous ne pouvez pas attendre de vos lecteurs qu'ils soient familiers avec tout ce qui se passe, en effet, ils ne sauront pas forcément comment bien se familiariser avec toutes ces informations. Vos messages devraient, autant que faire se peut, fournir un accès direct aux informations pour le lecteur. Si vous devez prendre deux minutes de plus pour aller chercher l'URL d'un fil de discussion particulier dans les archives des listes de diffusion afin d'éviter aux lecteurs d'avoir à le faire, ça en vaut la peine. S'il vous faut 5 à 10 minutes pour résumer les conclusions d'une discussion complexe, afin de donner à vos lecteurs le contexte pour comprendre votre message, faites le. Voyez les choses de la manière suivante : plus un projet à de succès plus le ratio lecteur/rédacteur augmente. Si chacun de vos messages est vu par n personnes, plus n augmente plus la rentabilité de ces quelques efforts supplémentaires de votre part pour faire gagner du temps à ces n personnes augmente. De plus, en voyant que vous vous imposez cette rigueur, les gens essaieront d'en faire de même dans leurs propres messages. Et idéalement c'est l'efficacité du projet qui en bénéficiera finalement : le projet préfèrera toujours la situation où une personne fait l'effort pour tout le monde que l'inverse.

Ne vous lancez pas dans des hyperboles. L'exagération dans les messages en ligne est une course à l'armement classique. Par exemple, une personne rapportant un bogue pourrait craindre que les développeurs n'y prêtent pas suffisamment attention et il le décrira alors comme un problème sévère qui l'empêche lui (et tous ses amis/collègues/cousins) d'utiliser le logiciel de manière productive alors que ce n'est en fait qu'un désagrément bénin. Mais l'exagération ne relève pas uniquement des utilisateurs, les programmeurs font souvent la même chose au cours de débats techniques, en particulier quand le désaccord repose plus sur une question de goût que d'exactitude :

« Faire ainsi rendrait le code totalement illisible. La maintenance deviendrait un cauchemar comparé à la proposition de A.Nonyme... » Le même argument devient plus convaincant lorsqu'il est formulé sur un ton plus neutre : « Ca fonctionne, mais c'est loin d'être la panacée en terme de lisibilité et de dépannage je pense. La proposition de A.Nonyme nous épargne ces problèmes car... »

Vous ne parviendrez pas à éradiquer complètement les hyperboles, mais ça ne sera en général pas nécessaire. Comparée à d'autres formes de mauvaise communication, l'hyperbole n'est pas si gênante, elle retombe en général sur son auteur. Les destinataires peuvent compenser, c'est juste que l'expéditeur perd un peu plus de crédibilité à chaque fois. Et donc, pour le bien de votre propre influence au sein du projet, faites preuve de modération. Ainsi, quand vous voulez vraiment être pris au sérieux sur un problème grave les gens vous écouteront.

Relisez deux fois. Pour tout message plus long qu'un paragraphe de taille moyenne vous devez vous relire avant de l'envoyer après que vous vous soyez déjà dit que c'était bon une première fois. Ce conseil doit sembler familier à quiconque a pris des cours de composition, mais c'est particulièrement important pour les discussions en ligne. Parce que l'écriture d'un message en ligne peut être très discontinue (pendant l'écriture d'un message vous aurez peut-être à lire d'autres courriers, à visiter certaines pages Web, à lancer une commande pour voir le message de deboguage, etc.) il est très facile de perdre le fil de ce que l'on disait. Les messages composés dans ces conditions et non relus avant d'être envoyés se repèrent facilement, au grand damne de leur auteur (ou du moins, on peut l'espérer). Prenez le temps de relire ce que vous envoyez. Plus vos messages sont cohérents plus ils seront lus.

Ton

Après avoir écrit des milliers de messages vous observez sûrement une simplification de votre style. Cela semble être la norme dans la plupart des forums techniques et intrinsèquement il n'y a rien de mal à cela. Un degré de simplification qui ne serait pas acceptable pour des interactions sociales habituelles est simplement la norme pour les hackers des logiciels libres. Voilà une réponse tirée d'une liste de diffusion à propos d'un logiciel libre de gestion de contenu, je cite la réponse complète :

Est-ce que tu pourrais développer un peu plus les problèmes que tu as rencontrés, etc. ? Et aussi : Quel version de Slash utilises-tu ? Je n'ai pas réussi à le savoir grâce à ton premier message. Comment as-tu construit exactement la source de apache/mod_perl ? As-tu essayé le correctif Apache 2.0 qui a été posté sur slashcode.com ? Shane

Alors ça c'est succinct ! Pas de bonjour, pas d'au revoir autre que sa signature et le message en lui-même n'est qu'une série de questions aussi brèves que possible. Sa seule phrase déclarative n'est qu'une critique implicite de mon message. Et pourtant j'étais content de voir la réponse de Shane et je n'ai pris sa brièveté que comme la marque d'une personne très occupée. Le simple fait qu'il me pose des questions plutôt que d'ignorer mon message signifiait qu'il voulait bien accorder un peu de temps à mon problème.

Par contre, tous les lecteurs ne réagiront pas forcément bien face à ce style, cela dépend de la personne et du contexte. Par exemple, si quelqu'un vient juste d'envoyer un message pour reconnaître qu'il a fait une erreur (par exemple qu'il a écrit un bogue) et que vous savez par des expériences passées que cette personne manque de confiance en elle vous devriez inclure dans votre réponse que vous comprenez ce qu'elle ressent. Le gros de votre réponse peut être concis, l'analyse de la situation par un œil expert, et aussi succinct que vous voulez. Mais à la fin, concluez par quelque chose indiquant que votre brièveté n'est pas à prendre pour de la froideur. Par exemple, si vous venez juste de donner des tas de conseils pour aider la personne à réparer le bogue, terminez par « Bonne chance <votre nom> » pour indiquer que vous êtes de tout cœur avec elle et que vous n'êtes pas fâché. Un petit smiley bien placé ou tout autre emoticone suffit souvent à rassurer un interlocuteur, pensez-y.

Il peut paraître étrange de se concentrer autant sur le bien être des participants que sur le contenu de leur message, mais pour dire les choses comme elles sont : le bien être affecte la productivité. Les sentiments sont importants pour d'autres raisons encore, mais même d'un point de vue strictement pratique on peut voir que les gens mécontents écrivent de moins bons logiciels et avec un rendement plus faible. Mais de part leur nature même, les communications électroniques dévoilent peu les vrais sentiments d'une personne. Il faudra vous appuyer sur vos déductions en vous basant sur a) comment une personne lambda se sentirait dans cette situation et b) ce que vous savez de cette personne par vos interactions passées. Certains préfèrent adopter une attitude plus détachée et se basent sur ce qui est dit ouvertement, l'idée étant que si un participant ne dit pas d'emblée que quelque chose le dérange alors personne ne devrait faire comme si c'était le cas. Je n'adhère pas à cette approche et ce pour plusieurs raisons. La première étant que les gens ne se comportent pas ainsi dans la vraie vie, pourquoi devraient-ils le faire en ligne ? Et la deuxième étant que, puisque les interactions se font sur des forums publics les gens ont encore plus tendance à masquer leurs émotions. Pour être plus précis ils expriment facilement leurs émotions pour les autres, comme la gratitude ou l'énervement, mais pas leurs sentiments intérieurs comme l'insécurité ou la fierté. Et pourtant la plupart des gens travaillent mieux quand ils savent que d'autres sont au courant de leur état d'esprit. En faisant attention aux petits détails vous vous tromperez rarement et vous arriverez à motiver les gens pour qu'ils restent plus impliqués qu'ils ne pourraient l'être autrement.

Je ne veux pas dire par là que votre rôle est celui d'un thérapeute de groupe à toujours aider les gens à être en harmonie avec leurs émotions. Mais en faisant attention au comportement des gens sur le long terme vous commencerez à bien les connaître même si vous ne les avez jamais vraiment rencontrés. Et en faisant attention à votre propre ton vous pourrez obtenir une influence surprenante sur le moral des participants, au profit du projet au final.

Reconnaître la vulgarité

L'une des caractéristiques de la culture Open Source est sa notion particulière de ce qui est vulgaire et de ce qui ne l'est pas. Ce qui suit n'est pas particulier au développement de logiciels libres, pas même aux logiciels en général, ce sont des conventions qui seraient familières à n'importe qui travaillant dans les mathématiques, les sciences dures ou les disciplines d'ingénierie. Le logiciel libre, avec ses frontières perméables et le flux constant de nouveaux venus est un environnement où ces conventions s'appliqueront également à des gens qui n'y sont pas familiers. Commençons par voir ce qui n'est pas offensant :

Les critiques techniques, même adressées directement et sans prendre de gants ne sont pas offensantes. Cela peut même être une sorte de flatterie, en effet, la critique implique que la personne visée mérite qu'on la prenne au sérieux et mérite qu'on prenne de son temps. Quand il aurait été plus facile de simplement ignorer le message, prendre le temps de faire la critique devient un compliment (à moins que la critique se résume à une attaque ad hominem ou tout autre forme de vulgarité évidente bien sûr).

Les questions brutes posées directement, comme les questions que me posait Shane dans l'exemple précédent, ne sont pas offensantes non plus. Des questions qui, dans un autre contexte, pourraient sembler froides, rhétoriques ou même railleuses sont souvent posées sérieusement et n'ont pas d'autre but que d'obtenir les informations aussi rapidement que possible. La célèbre question du support technique « Votre ordinateur est-il bien branché ? » en est un exemple classique. La personne du support technique a vraiment besoin de savoir si votre ordinateur est bien branché et après quelques jours à faire ce travail il en a déjà marre d'introduire sa question par de polies courbettes (« Je vous prie de m'excuser, je voudrais juste vous poser quelques questions pour éliminer quelques possibilités. Certaines vous paraîtront très simples, mais s'il vous plaît, faisons le ensemble... »). Arrivé à un certain point il laissera tomber la forme pour arriver directement au but : est-il branché ou pas ? Des questions équivalentes sont posées sans cesse sur les listes de diffusion des logiciels libres. Le but n'est pas de blesser le destinataire mais de rapidement éliminer les explications les plus évidentes (et peut-être les plus courantes). Ceux qui comprennent ceci et réagissent en conséquence marquent des points, ils font preuve d'ouverture d'esprit sans incitation. Mais ceux qui ne réagissent pas bien ne devraient pas être réprimandés pour autant. C'est juste un choc des cultures, ce n'est pas la faute de quelqu'un en particulier. Expliquez amicalement que vos questions (ou critiques) n'ont pas de sens caché, elles sont simplement posées pour obtenir (ou transmettre) des informations aussi efficacement que possible, rien de plus.

Mais alors, qu'est-ce qui est vulgaire ? Si on suit le principe selon lequel une critique technique est une forme de flatterie, ne pas apporter de critique constructive peut être une forme d'insulte. Je ne parle pas simplement d'ignorer le travail de quelqu'un, que ce soit une proposition, une modification ou le rapport d'un nouveau problème, etc. À moins que vous ayez promis explicitement une réaction détaillée, ce n'est pas grave si vous ne réagissez pas du tout. Les gens penseront simplement que vous n'avez pas eu le temps de dire quoique ce soit. Mais si vous réagissez par contre, ne lésinez pas : prenez le temps de vraiment analyser les choses, fournissez des exemples concrets quand il le faut, creusez un peu les archives pour trouver d'anciens messages ayant un lien, etc. Et si vous n'avez pas le temps de consentir tous ces efforts, mais que vous devez quand même écrire une réponse brève, dites le ouvertement (« Je pense que le problème a déjà été rapporté, mais malheureusement je n'ai pas le temps de faire la recherche, désolé. »). Il est primordial de reconnaître l'existence de la norme culturelle, soit en la respectant, soit en reconnaissant ouvertement que quelqu'un ne s'y est pas tenu. Dans les deux cas la norme est renforcée. Mais ne pas respecter la norme sans expliquer pourquoi revient à dire que le sujet (et ceux qui y participent) n'est pas digne de votre temps. Il vaut mieux montrer que vos temps est précieux en étant bref que fainéant.

Il y a bien d'autres formes de vulgarité évidemment, mais la plupart ne sont pas particulières au développement de logiciels libres et un peu de bon sens devrait suffire à les éviter. Reportez vous également à la partie intitulée « Tuez la vulgarité dans l'œuf » dans le Chapitre 2, Bien démarrer, si vous ne l'avez pas déjà fait.

Visage

Une région entière du cerveau humain est entièrement dédiée à la reconnaissance des visages. Elle est officieusement connue sous le nom de « zone fusocellulaire des visages » et ses aptitudes sont principalement innées, pas acquises. Il s'avère que la reconnaissance des individus est devenue si cruciale que nous avons développé du matériel spécialisé pour ça.

La collaboration en ligne est par conséquent une expérience psychologiquement étrange car elle demande une coopération étroite entre des êtres humains qui n'ont quasiment jamais l'opportunité d'identifier les autres par les méthodes les plus intuitives et naturelles : la reconnaissance faciale en premier lieu, mais aussi le son de la voix, la posture, etc. Pour compenser ceci essayez d'utiliser toujours le même pseudonyme. Il devrait être la première partie de votre adresse mail (la partie avant le signe @), votre nom d'utilisateur IRC, votre nom de committer, votre nom pour le suivi de problèmes et ainsi de suite. Ce nom est votre « visage » virtuel : un moyen d'identification court qui remplace au moins en partie votre visage, même si, malheureusement, il ne fait pas appel aux mêmes parties du cerveau.

Le pseudonyme devrait dériver logiquement de votre vrai nom (le mien par exemple est « kfogel »). Dans certains cas il sera accompagné par votre nom complet de toute façon, par exemple dans les en-têtes des mails :

De : "Karl Fogel" <kfogel@undomaine.com>

En fait il y a deux choses importantes ici. Comme nous l'avons dit précédemment, le pseudonyme rappelle votre vrai nom de manière intuitive, mais il faut aussi que votre vrai nom soit un vrai nom. Ce n'est pas un nom inventé comme : De : "Wonder Hacker" <wonderhacker@undomaineaupif.com>

Un dessin très connu de Paul Steiner paru dans le numéro du 5 juillet 1993 de The New Yorker montre un chien devant un ordinateur qui regarde un autre chien et lui dit d'un air conspirateur : « Sur Internet, personne ne sait que tu es un chien. » C'est probablement ce genre de pensées qui sont à l'origine de beaucoup de pseudonymes glorifiants ou pseudo-cool que les gens se donnent, comme si se donner le nom de « Wonder Hacker » amènera vraiment les gens à penser que vous êtes un hacker merveilleux. Mais ça n'efface pas la réalité : même si personne ne sait que vous êtes un chien, vous êtes quand même un chien. Une identité fantaisiste sur Internet n'impressionne pas les lecteurs. Au contraire, cela peut les amener à penser que vous vous souciez plus de l'image que du fond ou encore que vous êtes peu sûr de vous. Utilisez votre vrai nom pour toutes les interactions, ou, si pour certaines raisons vous voulez préserver votre anonymat, trouvez vous un nom qui ressemble à un nom normal et utilisez le en permanence.

En plus de montrer toujours le même « visage en ligne », il y a quelques trucs que vous pouvez faire pour le rendre plus plaisant. Si vous avez un titre officiel (par exemple « docteur », « professeur », « directeur ») n'en faites pas étalage, ne le mentionnez même pas, sauf si cela a une certaine importance dans la conversation. Le monde des hackers en général, et la culture des logiciels libres en particulier, a tendance à voir les titres comme une mise à l'écart et un signe de manque d'assurance. Vous pouvez mettre votre titre dans la signature automatique des mails que vous envoyez mais ne vous en servez jamais pour appuyer votre position dans une discussion, vous pouvez être sûr que cela se retournera contre vous. Vous voulez que les gens vous respectent en tant que personne, pas seulement pour votre titre.

En parlant de signature automatique : il faut qu'elle soit brève et efficace ou mieux : inexistante. Évitez les avertissements légaux insérés à la fin de chaque mail, en particulier lorsqu'ils expriment des idées incompatibles avec votre participation dans un projet de logiciel libre. Par exemple, le classique du genre qui suit apparaît à la fin de chaque message qu'un participant envoie à la liste de diffusion publique sur laquelle je suis :

IMPORTANT NOTICE
If you have received this e-mail in error or wish to read our e-mail disclaimer statement and monitoring policy, please refer to the :statement below or contact the sender.
This communication is from Deloitte & Touche LLP. Deloitte & Touche LLP is a limited liability partnership registered in England and :Wales with registered number OC303675. A list of members' names is available for inspection at Stonecutter Court, 1 Stonecutter :Street, London EC4A 4TR, United Kingdom, the firm's principal place of business and registered office. Deloitte & Touche LLP is :authorised and regulated by the Financial Services Authority.
This communication and any attachments contain information which is confidential and may also be privileged. It is for the exclusive :use of the intended recipient(s). If you are not the intended recipient(s) please note that any form of disclosure, distribution, :copying or use of this communication or the information in it or in any attachments is strictly prohibited and may be unlawful. If :you have received this communication in error, please return it with the title "received in error" to IT.SECURITY.UK@deloitte.co.uk :then delete the e-mail and destroy any copies of it.
E-mail communications cannot be guaranteed to be secure or error free, as information could be intercepted, corrupted, amended, :lost, destroyed, arrive late or incomplete, or contain viruses. We do not accept liability for any such matters or their :consequences. Anyone who communicates with us by e-mail is taken to accept the risks in doing so.
When addressed to our clients, any opinions or advice contained in this e-mail and any attachments are subject to the terms and :conditions expressed in the governing Deloitte & Touche LLP client engagement letter.
Opinions, conclusions and other information in this e-mail and any attachments which do not relate to the official business of the :firm are neither given nor endorsed by it.

Pour une personne qui vient poser quelques questions de temps en temps, cet avertissement énorme semble un peu étrange mais ne causera pas de problème à long terme. Par contre, si cette personne participe activement au projet, ce pavé légal aura un effet plus insidieux. Il véhicule au moins deux signaux destructeurs : cette personne ne maîtrise pas complètement ses outils, il est enfermé dans une messagerie d'entreprise qui colle un message gênant à la fin de chaque message, il n'a pas trouvé le moyen de contourner ça et il n'a peu ou pas de soutien de son entreprise pour ses activités dans le logiciel libre. C'est vrai que l'entreprise ne l'empêche pas purement et simplement de participer aux listes de diffusion publiques, mais elle rend ses messages vraiment pas accueillant, comme si le risque de laisser échapper des informations confidentielles prenait le pas sur toutes les autres priorités.

Si vous travaillez pour une société qui impose que ce type de signature soit jointe à tous les courriers sortants vous devriez envisager l'utilisation d'un compte de messagerie gratuite comme par exemple gmail.google.com, www.hotmail.com ou www.yahoo.com et utiliser cette adresse pour le projet.

Éviter les pièges courants

Ne pas poster sans raison

Quand vous participer à un projet en ligne vous serez tenté de répondre à tout, c'est l'un des pièges classiques. Ne le faites pas. Tout d'abord, il risque d'y avoir plus de fils de discussions que vous ne pouvez en suivre, en tout cas une fois que le projet se sera développé. Deuxièmement, même dans les fils que vous avez décidé de suivre, la majeure partie de ce qu'écrivent les gens n'appelle pas de réponse. Dans les forums de développement plus particulièrement, trois types de messages prédominent :

  1. Des messages proposant quelque chose de pertinent
  2. Des messages pour exprimer son soutien ou son opposition à ce que quelqu'un d'autre a dit
  3. Des messages récapitulatifs

Aucun de ceux-là n'appelle concrètement de réponse, notamment si vous êtes pratiquement certain, compte tenu de la teneur du fil jusque-là, que quelqu'un d'autre va probablement dire ce que vous auriez dit (ne craignez pas que les autres utilisent cette même tactique, soyez en sûr, il y a presque toujours quelqu'un qui aura envie de se jeter dans la mêlée). Une réponse doit être motivée par un objectif précis. Demandez-vous d'abord : est-ce que je sais où je veux en venir ? Puis : est-ce que ceci a des chances de se réaliser sans que je m'exprime ?

Il y a deux bonnes raisons pour intervenir dans un fil de discussion : 1) quand on voit une faille dans une proposition et qu'on suppose être le seul à la voir et 2) quand on voit que les autres ont du mal à communiquer et qu'on pense pouvoir éclaircir la situation en postant un message. On peut aussi poster un message simplement pour remercier quelqu'un ou pour dire « Moi aussi ! », car le lecteur peut comprendre immédiatement que ce genre de messages n'entraîne aucune réponse ni aucune action, en conséquence de quoi l'effort mental requis par le message se termine proprement quand le lecteur atteint la dernière ligne du message. Mais même dans ce cas là, réfléchissez à deux fois avant de dire quelque chose ; il vaut mieux qu'on pense que vous pourriez poster plus et non que vous pourriez poster moins (pour plus de réflexions sur le comportement à adopter sur une liste très active, voir la seconde partie de l'Annexe C, Pourquoi je devrais me soucier de la couleur de l'abri à vélo ?).

Fils de discussion productifs contre fils improductifs

Dans une liste de discussion animée il y a deux impératifs. Le premier, évidemment, consiste à distinguer ce qui mérite votre attention de ce que vous pouvez ignorer. L'autre consiste à agir de manière à ne pas créer du bruit : vous voulez non seulement que vos propres messages soient pertinents, mais aussi qu'ils incitent les autres à en poster d'aussi pertinents ou alors à s'abstenir.

Pour voir comment y parvenir examinons le contexte dans lequel ceci se produit. Quelles sont les marques distinctives d'un fil improductif ?

  • Quand les arguments qui ont déjà été avancés sont répétés à nouveau, comme si leur auteur pensait que personne ne les a entendus la première fois
  • Quand les niveaux d'hyperbole et d'engagement augmentent au fur et à mesure que l'enjeu diminue
  • Quand la majorité des commentaires émane de ceux qui ne font rien ou presque, tandis que ceux qui en font le plus gardent le silence
  • Quand plusieurs idées sont en discussion sans qu'il y ait de propositions claires (bien sûr, toutes les idées intéressantes commencent par une vision imprécise ; ce qui compte, c'est la direction qu'elles prennent à partir de là. Est-ce que le fil a tendance à rendre la vision plus concrète ou est-ce qu'il s'emberlificote dans des sous-visions, des visions parallèles et des disputes ontologiques ?).

Le fait qu'un fil ne soit pas productif à son début ne le condamne pas nécessairement. Il peut s'agir d'un sujet important, auquel cas le fait que le fil piétine est d'autant plus troublant.

Redonner de l'intérêt à un fil de discussion utile sans faire de rentre-dedans est tout un art. Reprocher simplement aux gens leur perte de temps, ou leur demander de ne poster que des messages constructifs ne mène pas à grand chose. Vous pouvez, bien sûr, penser cela par devers vous, mais l'exprimer à haute voix serait insultant. En revanche, vous devez suggérer des pistes pour progresser ; donner une direction, une voie à suivre qui mène au résultat escompté, sans pour autant avoir l'air d'imposer une conduite. Voici par exemple ce qu'il ne faut pas faire :

Cette discussion ne mène nulle part. Pouvez-vous laisser tomber ce sujet jusqu'à ce que quelqu'un ait fait un correctif pour mettre en œuvre une de ces propositions ? Pas la peine de répéter toujours les mêmes choses. Le code parle plus que des mots les gars.

Voici qui est mieux :

 Plusieurs propositions ont été esquissées dans ce fil, mais aucune n'est suffisamment précise pour qu'on puisse voter pour ou contre. De plus, nous n'avançons aucune idée nouvelle mais répétons ce qui a déjà été dit. Donc la meilleure chose à ce point serait que les messages à venir contiennent soit une spécification complète pour le comportement proposé, soit un correctif. Comme ça nous aurons au moins une action précise à entreprendre (i.e. nous mettre d'accord sur les spécifications ou appliquer le correctif et le tester).

Comparez les deux approches. La deuxième ne trace pas une ligne de démarcation entre vous et les autres, elle n'accuse personne de mener la discussion dans une impasse. Elle parle de « nous », ce qui est important, que vous ayez ou non participé auparavant à la discussion, car cela rappelle à chacun que même pour ceux qui sont restés silencieux jusqu'ici l'issue de la discussion compte. Elle expose pourquoi le fil ne va nulle part mais le fait sans dénigrer ou porter de jugement quelconque, elle ne fait que constater des faits de manière neutre. Et surtout elle offre une ligne d'action positive, de sorte que les gens au lieu d'avoir l'impression que la discussion a été stoppée (frein contre lequel ils ne peuvent que s'insurger) auront l'impression qu'on leur offre un moyen d'amener la discussion dans une autre direction plus constructive. C'est là un critère que les gens accepteront spontanément.

On ne voudra pas toujours porter une discussion à un plus haut degré de productivité, parfois il est souhaitable qu'elle cesse. Le but de votre message est alors d'aboutir à l'un ou à l'autre. Si vous pouvez voir d'après ce qui s'est dit dans le fil que personne n'est prêt à s'engager dans la voie que vous proposez alors votre message clôt effectivement le fil sans en avoir l'air. Évidemment il n'y a aucun moyen infaillible pour clore un fil, et même s'il y en avait un, vous n'y auriez pas recours. Mais demander aux participants de faire des progrès ostensibles ou d'arrêter de poster est tout à fait légitime si vous le faites avec diplomatie. Gardez-vous d'étouffer des discussions prématurément toutefois. Une certaine dose de causette spéculative peut être productive selon le sujet et demander à ce qu'elle aboutisse trop rapidement fera tourner court le processus créatif et on vous taxera d'impatience.

Ne vous attendez pas à faire cesser un fil instantanément. Il y aura certainement quelques messages de plus après le vôtre, soit parce que les messages se sont croisés, soit parce que les gens veulent avoir le dernier mot. Il n'y a aucune raison de s'inquiéter et il n'est pas nécessaire de poster un nouveau message. Laissez le fil s'éteindre, ou pas suivant le cas. Vous ne pouvez pas avoir le contrôle absolu ; d'un autre côté, statistiquement, vous pouvez espérer que vos rappels portent leurs fruits après les avoir réitérés sur plusieurs fils.

Plus le sujet est facile, plus long sera le débat

La probabilité de dévoiement n'est nulle pour aucun fil, mais les sujets techniques simples sont un terreau très fertile pour l'égarement. Après tout, les sujets techniquement complexes ne seront bien compris que par une faible proportion de participants. Ceux qui le peuvent sont certainement les développeurs les plus expérimentés qui ont déjà pris part à ce genre de discussions des milliers de fois auparavant et qui savent comment aboutir à un consensus viable pour tous.

Le consensus est donc plus difficile à atteindre sur des questions techniques faciles à comprendre et sur lesquelles on peut se faire aisément une opinion ainsi que sur les sujets « légers » tels que l'organisation, la publicité, le financement, etc. Les gens peuvent participer à ces débats indéfiniment car il n'y a pas besoin de qualifications spécifiques pour le faire, ni de moyens clairs de savoir (même après coup) si la décision était bonne ou mauvaise ou encore simplement parce qu'avoir les autres participants à l'usure est une tactique qui réussit parfois.

Le principe selon lequel la somme de discussion est inversement proportionnelle à la complexité du sujet a été énoncé il y a un moment déjà et est connu officieusement sous le nom de l'effet Bikeshed (abri à vélos). Voici l'explication qu'en donne Poul-Henning Kamp dans un désormais célèbre message aux développeurs BSD :

C'est une longue histoire, ou plutôt une vieille histoire, mais très brève en réalité. C. Northcote Parkinson a écrit un livre dans les années 60 intitulé "La Loi de Parkinson" qui contient des opinions intéressantes sur la dynamique du management.

[...]

Dans cet exemple précis concernant l'abri à vélos l'autre élément important est une centrale nucléaire, pour vous donner une idée de l'âge de l'ouvrage.

Parkinson montre comment vous pouvez obtenir du bureau exécutif l'accord pour construire une centrale nucléaire qui coûte plusieurs millions, voire un milliard de dollars, mais si vous voulez construire un abri à vélos, vous voilà embarqué dans des discussions sans fin.

Parkinson explique que c'est parce que la centrale nucléaire est tellement vaste, tellement chère et tellement complexe que les gens ne peuvent pas l'appréhender et, plutôt que de s'y essayer, ils préfèrent supposer que quelqu'un d'autre a pris la peine de vérifier tous les détails avant d'aller plus loin. Richard P. Feynmann donne dans son livre quelques exemples intéressants et très pertinents concernant Los Alamos.

De l'autre côté, nous avons l'abri à vélos. N'importe qui peut en construire un en un week-end, tout en ayant le temps d'aller regarder le match à la télé. Aussi bien préparée et raisonnable que soit votre proposition, quelqu'un saisira cette opportunité pour montrer qu'il fait son boulot, qu'il veille au grain, qu'il est dans la place.

Au Danemark on appelle ça laisser son empreinte. C'est une question d'amour propre et de prestige qui consiste à désigner quelque chose du doigt en disant : "Voilà ! C'est moi qui l'ai fait." C'est une caractéristique très présente chez les politiciens, mais également chez toute personne à qui on en donne l'occasion. Il n'y a qu'à voir les traces de pas dans le ciment frais.

(Son message complet vaut vraiment la peine d'être lu. Voir Appendice C, « Que m'importe la couleur de l'abri à vélos ? »)

Toute personne qui a été membre d'un groupe de décision reconnaîtra ce dont parle Kamp. Cependant, il est généralement impossible de convaincre tout le monde d'éviter de peindre l'abri à vélos. La meilleure chose que vous puissiez faire est de signaler le phénomène quand il se produit et convaincre les développeurs expérimentés, ceux dont les messages ont le plus de poids, de déposer leurs pinceaux avant les autres pour qu'eux au moins ne renforcent pas le bruit. Les manifestations pour-la-peinture-de-l'abri-à-vélo ne disparaîtront jamais complètement mais on peut les rendre plus brèves et moins fréquentes en instillant la prise de conscience du phénomène dans la culture du projet.


Éviter les trolls

Un troll est une dispute portant souvent, mais pas toujours, sur une question plutôt insignifiante qui ne peut être résolue par la discussion car elle éveille des passions qui poussent les gens à continuer à argumenter jusqu'à faire prévaloir leur point de vue. Les trolls ne sont pas tout à fait semblables aux réunions-pour-la-peinture-de-l'abri-à-vélos. Les gens qui peignent les abris à vélos sont prompts à donner leur avis (car ils le peuvent), mais ne vont pas forcément le défendre avec véhémence et peuvent même à l'occasion émettre d'autres opinions incompatibles pour montrer qu'ils prennent en compte tous les aspects de la question. Dans un sujet à troll, en revanche, prendre en compte les autres points de vue est un signe de faiblesse. Dans un sujet à troll, tout le monde sait qu'il y a Une Réponse Juste, les participants ne sont simplement pas d'accord sur laquelle.

Une fois que le troll est lâché il ne pourra pas être remis en cage sans que certains ne se sentent lésés. C'est inutile de déclarer en plein milieu d'un troll qu'il s'agit d'un troll. Tout le monde le sait déjà. Malheureusement une caractéristique des trolls est la divergence d'opinion sur le règlement du conflit, la discussion peut-elle aboutir ? De l'extérieur, il apparaît clairement qu'aucun des camps n'est en mesure de faire changer l'autre d'avis. De l'intérieur, la partie adverse est obtuse et n'a pas les idées claires, mais on peut en avoir raison à force d'intimidation. Attention : je ne dis pas qu'il n'y a pas de cause juste dans un troll. Parfois il y en a une, dans les trolls auxquelles j'ai participé c'était toujours la mienne évidemment. Mais peu importe, car il n'y a pas d'algorithme qui permette de démontrer de manière convaincante qu'un camp a raison et l'autre tort.

Souvent, pour achever un troll, quelqu'un dira : « Nous avons déjà perdu trop de temps et d'énergie à discuter ! Vous voulez pas juste laisser tomber ? », mais ce n'est pas la bonne manière de faire. Il y a deux problèmes ici. D'abord, le temps et l'énergie perdus ne pourront plus être rattrapés, la question maintenant est de savoir l'effort qu'il reste à faire. Si certains pensent que poursuivre un peu la discussion amènera à la résolution du conflit, alors cela vaut encore la peine (de leur point de vue) de poursuivre.

L'autre problème quand on demande aux gens de laisser tomber c'est que cela équivaut souvent à permettre à l'une des parties, celle du statu quo, de se déclarer vainqueur par forfait. Et dans certains cas, le statu quo n'est pas acceptable : tout le monde est d'accord, il faut prendre des décisions et agir dans un sens ou dans l'autre. Il vaut mieux poursuivre l'argumentation plutôt que d'abandonner le sujet. Mais comme le dilemme s'applique à tous de la même manière il est aussi possible que la discussion continue éternellement.

Alors, comment gérer les trolls ?

Voici un début de réponse : faites en sorte qu'ils ne soient pas libérés. Ce n'est pas aussi irréalisable qu'il n'y parait.

Vous pouvez anticiper certains trolls classiques : ils surgissent quand il est question de langages de programmation, de licences (voir la section intitulée « La GPL et la compatibilité de licence » du Chapitre 9, Licences, droits d'auteurs et brevets), de déguisement des adresses e-mail (voir la section « Le grand débat du Répondre à » du Chapitre 3, Infrastructure technique) et encore de quelques autres sujets. Chaque projet a également un ou deux trolls qui lui sont propres, avec lesquelles les développeurs ayant de l'ancienneté se familiariseront rapidement. Les techniques pour stopper les trolls ou pour en limiter les dégâts sont à peu près les mêmes partout. Même si vous êtes certain que votre camp a raison, essayez de trouver un moyen de montrer votre ouverture et votre sympathie quand l'autre camp marque des points. Souvent dans les sujets à troll chaque camp a construit des murs si haut et a tellement claironné que l'opinion adverse est pure folie que le fait de céder ou de changer d'avis devient psychologiquement insoutenable : cela reviendrait à reconnaître non seulement que l'on a tort, mais que l'on a eu tort tout en étant sûr de soi. En montrant précisément que vous comprenez les arguments de la partie adverse et que vous les trouvez sensés, même s'ils ne vous convainquent pas entièrement, vous rendrez cet aveu acceptable par l'autre camp. Faites un geste qui en appelle un autre en retour et la situation s'améliorera. Même si vos chances d'obtenir le résultat technique souhaité n'en sont pas meilleures pour autant, vous aurez au moins évité des dommages collatéraux portant atteinte au moral du projet.

Lorsqu'un troll ne peut être évité déterminez rapidement combien vous êtes prêt à sacrifier et soyez disposé à céder publiquement. Ce faisant, vous pouvez dire que vous reculez car la guerre ne vaut pas le coup, mais faites le sans amertume et n'en profitez pas pour tirer une dernière salve sur les arguments du camp opposé. Le renoncement n'est efficace que s'il est fait de bonne grâce.

Les trolls sur les langages de programmation sont un peu spéciaux car bien qu'ils impliquent souvent un haut degré de technicité, nombreux sont ceux qui se sentent qualifiés pour y prendre part et les enjeux sont importants puisque de l'issue des débats dépendra le langage de l'essentiel du code du projet. Il vaut mieux choisir tôt le langage, en suivant l'avis des développeurs influents de départ et le défendre pour la bonne et simple raison que c'est celui avec lequel vous êtes tous plus à l'aise et non pas qu'il est meilleur qu'un autre qui aurait pu être utilisé à la place. Ne laissez jamais la conversation dégénérer en une comparaison académique entre langages de programmation (ceci semble se produire plus généralement quand quelqu'un évoque Perl, pour je ne sais quelle raison) ; c'est une impasse dans laquelle vous devez refuser de vous laisser entraîner.

Pour plus de références historiques aux trolls, voir http://catb.org/~esr/jargon/html/H/holy-wars.html ainsi que l'article de Danny Cohen qui a rendu ce terme populaire, http://www.ietf.org/rfc/ien/ien137.txt.

L'effet « minorité bruyante »

Sur les listes de discussion il est très facile pour une petite minorité de donner l'impression qu'il y a de grandes divergences en noyant la liste sous une avalanche de longs messages. C'est un peu une technique de pirate, une minorité de blocage, si ce n'est que l'illusion d'un désaccord diffus est encore plus puissante, car elle est disséminée à travers un nombre arbitraire de messages discrets et que la plupart des gens ne se donneront pas la peine de suivre à la trace qui a dit quoi et quand. Ils auront juste l'impression instinctive que le sujet est controversé et attendront que le soufflé retombe.

La meilleure façon de contrer cet effet est de montrer très clairement, preuves à l'appui, à quel point le groupe en désaccord est petit comparé à tous ceux qui sont d'accord. Pour rendre la disproportion plus évidente vous pourrez sonder en privé ceux qui ont gardé le silence mais que vous supposez en accord avec la majorité. Ne dites rien qui puisse faire croire que les dissidents essayaient de gonfler la portée de leur impact. Ce n'était pas nécessairement leur but et même si c'était le cas il n'y a aucun avantage stratégique à le faire remarquer. Il vous suffit de mettre en avant les chiffres réels pour que les gens réalisent que leur perception de la situation ne correspond pas à la réalité.

Ce conseil ne s'applique pas qu'aux problèmes où les camps sont bien marqués. Il s'applique à toutes les discussions faisant couler beaucoup d'encre virtuelle mais dont le sujet n'est pas nécessairement un vrai problème aux yeux des gens. Après un certain temps, si vous convenez que le sujet ne mérite pas d'action et que vous voyez qu'il n'avance pas (même s'il a généré beaucoup d' e-mails), vous pouvez simplement faire observer publiquement qu'il n'y a pas de progrès. Si l'effet « Minorité bruyante » s'était mis en place, votre message ressemblera à une bouffée d'air frais. La perception générale de la discussion ne sera plus aussi nette : « Heu, c'est vrai qu'on dirait que c'est important parce qu'il y a beaucoup de messages, mais je n'ai pas l'impression qu'on progresse. » En expliquant que la forme de la discussion l'a fait paraître plus animée qu'elle ne l'est vraiment vous lui donnez rétrospectivement une nouvelle forme à travers laquelle les participants peuvent se refaire une opinion de ce qui résulte de la discussion.

Les personnes difficiles

Il n'est pas plus facile de traiter avec les gens difficiles sur les forums électroniques que dans la vraie vie. Par « difficiles » je ne veux pas dire « grossiers ». Les gens grossiers sont embêtants, mais pas nécessairement difficiles. Nous avons déjà abordé dans cet ouvrage comment s'en occuper : faites leur remarquer leur grossièreté une première fois, à partir de quoi ignorez-les ou traitez-les comme n'importe quelle autre personne. S'ils continuent à être grossiers, ils se rendront si impopulaires qu'ils n'auront plus d'influence sur les autres au sein du projet ; le problème qu'ils posent se résout ainsi de lui-même. Les cas réellement difficiles sont ceux qui n'étant pas ouvertement grossiers manipulent les autres ou abusent des processus du projet de telle sorte qu'ils monopolisent le temps et l'énergie des autres sans rien apporter de positif au projet. Ce genre de personnes cherchent souvent les points d'achoppement des procédures mises en place et s'en servent comme levier pour obtenir plus d'influence qu'ils n'en auraient autrement. C'est bien plus insidieux que de la simple grossièreté, car ni le comportement ni les dommages qu'ils causent ne sont visibles pour un observateur occasionnel. Un exemple classique est celui du bloqueur, quelqu'un (qui a l'air on ne peut plus raisonnable bien sûr) ne cesse de répéter à qui veut bien l'entendre que la réflexion n'est pas encore mure pour qu'on prenne une décision et qui propose toujours plus de solutions ou de nouvelles approches sur de vielles solutions alors qu'au fond il sent que le consensus ou le vote est en train de prendre forme et qu'il n'aime pas la direction qu'il prend. Un autre exemple est celui du débat qui n'aboutit pas à un consensus, mais dans lequel le groupe essaie au moins de clarifier les points de désaccord et de produire un compte-rendu auquel chacun pourra se référer par la suite. L'obstructionniste, qui sait que le compte-rendu peut avoir une issue qui lui déplaît, essaiera de reporter le compte-rendu en compliquant sans cesse la question de ce qui devrait y figurer, soit en s'opposant aux suggestions raisonnables soit en introduisant de nouveaux points inattendus.

Gérer les personnes difficiles

Pour contrer ce genre de comportements il est utile de comprendre la mentalité de ceux qui y recourent. De manière générale ils ne le font pas consciemment. Personne ne se réveille le matin en se disant : « Tiens, aujourd'hui je vais manipuler cyniquement les procédures pour faire mon obstructionniste agaçant. » En revanche, de telles actions sont souvent précédées d'un sentiment semi-paranoïaque de mise à l'écart des échanges et des décisions du groupe. La personne a l'impression qu'on ne la prend pas au sérieux ou, dans les cas plus graves, qu'il y a une conspiration contre elle : que les autres membres du projet ont décidé de créer un club fermé dont elle est exclue. Ce qui justifie, à ses yeux, de prendre le règlement à la lettre et de s'engager dans une manipulation formelle des procédures du projet, afin que les autres la prennent au sérieux. Dans les cas extrêmes, la personne peut même croire qu'elle se bat seule contre tous pour sauver le projet lui-même.

Tout le monde ne remarquera pas ces attaques de l'intérieur au même moment, c'est dans leur nature même et certains ne les verront que si on leur en fournit des preuves solides. Par conséquent, neutraliser ces attaques peut demander pas mal d'efforts. Il ne suffit pas de vous convaincre de ce qui est en train de se produire ; il vous faudra aligner des preuves suffisantes et les présenter de manière réfléchie pour convaincre les autres.

Ces combats demandent beaucoup d'efforts, votre meilleure solution sera peut-être de tolérer momentanément ces comportements. C'est un peu comme une maladie parasitaire bénigne : si elle n'affaiblit pas trop le projet on peut la tolérer, les médicaments pourraient avoir des effets secondaires négatifs. Cependant, si la tolérer cause trop de dommages il est alors temps d'agir. Commencez à rassembler des notes sur les faits que vous observez. Assurez-vous d'y inclure des références à des archives publiques, c'est là une des raisons pour lesquelles le projet garde des traces, vous pouvez donc les utiliser. Lorsque vous avez bien documenté l'affaire, entamez une phase d'échanges privés avec d'autres participants. Ne leur dites pas ce que vous avez observé : recueillez d'abord leurs propres impressions. C'est sans doute votre dernière chance pour avoir un retour non filtré sur leur perception de la situation ; une fois que vous commencerez à en parler ouvertement les avis seront polarisés et personne ne se souviendra de son avis initial sur la question.

Si les discussions privées montrent que vous n'êtes pas seul il est temps de faire quelque chose. C'est là qu'il faut être vraiment prudent, car il est très facile pour ce genre de personnes d'essayer de faire croire qu'on leur tombe dessus injustement. Quoi que vous fassiez, ne les accusez jamais de détourner les procédures du projet de manière malintentionnée, d'être paranoïaques, ni de tout autre chose que vous soupçonnez être vraies. Votre stratégie doit être de vous montrer à la fois plus raisonnable et plus concerné par le bien-être global du projet, avec l'objectif de soit réformer le comportement de cette personne, soit de lui faire quitter le projet. Selon les autres développeurs et vos relations avec eux, il peut être avantageux de réunir d'abord des alliés en privé... ou pas : cela pourrait créer des réticences en coulisse si les gens pensent que vous vous lancez dans une campagne de rumeurs abusives. Souvenez-vous que, bien que l'autre personne soit celle qui agit de manière destructrice, c'est vous qui paraîtrez destructeur si vous faites des accusations publiques sans pouvoir les étayer. Soyez certain d'avoir de nombreux exemples pour démontrer ce que vous avancez et dites-le aussi gentiment que possible tout en étant direct. Vous ne persuaderez peut-être pas la personne en question, mais ce n'est pas très important du moment que vous arrivez à convaincre les autres.

Étude de cas

Je ne me souviens que d'une seule fois, au cours des dix années que j'ai passées dans le logiciel libre, où les choses sont arrivées à un point où nous avons dû demander à quelqu'un de cesser de poster des messages. Comme c'est souvent le cas, il n'était pas grossier et voulait vraiment être utile. Mais il ne savait pas quand il fallait poster et quand il ne le fallait pas. Nos listes étaient ouvertes au public et il postait si souvent pour poser des questions sur tellement de sujets qu'il devenait une nuisance pour la communauté. Nous avions déjà essayé de lui demander gentiment de chercher un peu plus les réponses avant de poster, sans résultat.

La stratégie qui finit par payer est un exemple parfait de l'utilisation de données neutres, quantitatives pour monter un dossier solide. Un de nos développeurs alla fouiller dans les archives, puis envoya le message suivant en privé à quelques développeurs. Le contrevenant (le troisième nom dans la liste ci-dessous, apparaissant ici comme « A. Nonyme ») avait très peu de relation avec le projet, il n'avait contribué ni au code ni à la documentation. Et pourtant, parmi les participants, il était troisième en nombre de messages envoyés sur les listes :


De : "Brian W. Fitzpatrick" <fitz@collab.net> A : [... liste des destinataires omise pour conserver l'anonymat ...] Sujet: The Subversion Energy Sink Date: Wed, 12 Nov 2003 23:37:47 -0600

Dans les 25 derniers jours, les 6 personnes ayant posté le plus dans la liste svn [dev|users] sont :

   294 kfogel@collab.net 
   236 "C. Michael Pilato" <cmpilato@collab.net> 
   220 "A. Nonyme" <anonyme@problematic-poster.com> 
   176 Branko Čibej <brane@xbc.nu> 
   130 Philip Martin <philip@codematters.co.uk> 
   126 Ben Collins-Sussman <sussman@collab.net> 

Je dirais que 5 de ces personnes contribuent à atteindre Subversion 1.0 dans un avenir proche.

J'ajouterai que l'une de ces personnes prend du temps et de l'énergie aux 5 autres, sans parler de la liste dans son ensemble, ralentissant ainsi (fût-ce involontairement) le développement de Subversion. Je n'ai pas fait une analyse fil par fil, mais un vgrepp sur mon spool d'e-mail Subversion me dit que pour chaque e-mail de cette personne, au moins deux des cinq autres personnes de la liste ci-dessus prennent le temps de lui répondre.

Je pense qu'une intervention musclée est nécessaire, quitte à effrayer la personne mentionnée plus haut. La délicatesse et la gentillesse se sont avérées sans effet.

dev@subversion est une liste destinée à faciliter le développement d'un logiciel de gestion de version, ce n'est pas une séance de thérapie de groupe.

-Fitz, qui cherche à ne pas se noyer dans trois jours d'e-mails svn qu'il a laissés s'accumuler.


Bien qu'il n'en eût pas l'air au début, le comportement de A. Nonyme était un cas classique d'abus des procédures. Il ne faisait rien de flagrant comme retarder un vote, mais il tirait profit de la politique d'auto-modération de la liste de diffusion. C'était à chaque membre de juger quand et sur quoi poster. Donc, nous n'avions pas de procédure de recours pour faire face à une personne qui soit n'avait pas, soit n'exerçait pas, cette capacité de discernement. On ne pouvait pas dire que ce gars violait des règles mais pourtant tout le monde savait que ses messages fréquents devenaient un problème sérieux. La stratégie de Fitz s'est avérée, rétrospectivement, excellente. Il a réuni des preuves accablantes, mais les a diffusées discrètement, les communiquant d'abord aux quelques personnes dont le soutien s'avérait décisif pour une action drastique. Ils étaient d'accord sur le fait que des mesures étaient nécessaires et finalement nous avons appelé A. Nonyme au téléphone, nous lui avons décrit le problème directement et lui avons demandé de cesser de poster. Il n'en a jamais vraiment compris les raisons ; s'il avait été en mesure de les comprendre il aurait probablement fait preuve de discernement dès les début. Mais il accepta de ne plus poster et la liste devint utilisable à nouveau. Une des raisons pour lesquelles cette stratégie a fonctionné, peut-être, était la menace implicite que nous pourrions mettre en place un filtrage de ses messages 'via' le logiciel de modération couramment utilisé pour prévenir le spam (voir la section « Se prémunir du Spam » dans le Chapitre 3, Infrastructure technique). Mais si nous avions cette option en réserve, c'est parce que Fitz avait d'abord réuni le soutien nécessaire de personnages clés.

Gérer la croissance

Le prix du succès est lourd dans le monde de l'Open Source. Au fur et à mesure que votre logiciel devient populaire le nombre de personnes cherchant des renseignements augmente de manière très importante tandis que le nombre de personnes capables de fournir ces renseignements croît bien plus lentement. De plus, même si la proportion entre les deux était à peu près équilibrée, il resterait encore un problème fondamental : la gestion de la communication. Prenons les listes de diffusion par exemple. La plupart des projets disposent d'une liste pour les questions générales des utilisateurs, cette liste s'appelle parfois « utilisateurs », « discussion », « aide » ou quelque chose comme ça. Quel qu'en soit le nom, le but de cette liste est toujours le même : fournir un lieu où les gens trouvent des réponses à leurs questions, tandis que d'autres observent et (normalement) s'imprègnent des connaissances en observant ces échanges.

Il n'y a pas d'explosion quand les forums atteignent leur point culminant. Il y a seulement une suite d' évènements ponctuels néfastes : les gens se désabonnent des listes ou ils désertent le canal IRC ou ils cessent d'une manière ou d'une autre de se donner la peine de poser des questions car ils comprennent qu'ils ne seront pas entendus au milieu de tout ce bruit. Comme de plus en plus de personnes font ce choix bien compréhensible l'activité du forum semblera se maintenir à un niveau gérable. Mais elle reste gérable justement parce que les gens rationnels (ou du moins expérimentés) ont commencé à chercher l'information ailleurs, tandis que les gens inexpérimentés restent et continuent à poster. En d'autres termes, quand on continue à utiliser des modèles de communication non modulables alors que le projet grandit la qualité moyenne des questions et des réponses tend à baisser, ce qui donne l'impression que les nouveaux utilisateurs sont plus bêtes qu'ils ne l'étaient dans le temps alors qu'en fait ce n'est probablement pas le cas. C'est juste que la rentabilité de ces forums à grande audience est plus bas, donc naturellement ceux qui en ont l'expérience chercheront ailleurs leurs réponsesen priorité. Ajuster les mécanismes de communication pour faire face à la croissance du projet implique deux stratégies liées :

  1. Identifier les parties spécifiques d'un forum qui ne subissent pas une croissance débridée, contrairement au reste du forum, et les détacher dans un nouveau forum plus spécialisé (i.e. ne laissez pas le mauvais tirer le bon vers le bas.)
  2. S'assurer que plusieurs sources d'information automatisées sont à la disposition des utilisateurs, qu'elles sont bien organisées, mises à jour et faciles à trouver.

La stratégie n°1 est généralement assez facile à mettre en œuvre. La plupart des projets démarre avec un forum principal : une liste de discussion générale dans laquelle les propositions de fonctionnalités, les questions relatives à la conception et les problèmes liés au code sont abordées en vrac. Tous les gens impliqués dans le projet y sont inscrits. Au bout d'un certain temps, il devient évident que la liste a évolué en plusieurs sous-listes orientées chacune sur un sujet. Par exemple, certains fils concernent clairement le développement et la conception ; d'autres sont des questions d'utilisateurs sur le fonctionnement « Comment faire X ? » ; une troisième lignée porte peut-être sur le traitement des rapports de bogue et les demandes d'améliorations, etc. Un individu donné peut bien sûr prendre part à plusieurs types de fils différents, mais il faut voir que ces catégories ne se recoupent pas trop. Ils pourraient être répartis dans des listes séparées sans causer un cloisonnement nuisible car les fils traversent rarement la frontière des sujets.

Procéder à cette division est un processus en deux étapes. On crée d'abord la nouvelle liste (ou canal IRC, ou autre), puis on passe le temps nécessaire à gentiment harceler les gens et leur rappeler l'utilisation appropriée des nouveaux forums. Cette dernière étape peut durer des semaines, mais un jour les gens s'y feront. Vous devez simplement vous astreindre à prévenir systématiquement l'expéditeur quand son message est posté au mauvais endroit, et le faire de manière visible, pour que les autres soient encouragés à vous relayer dans l'aiguillage. Il est utile également d'avoir une page Web avec un index de toutes les listes disponibles ; vos réponses peuvent simplement renvoyer à cette page et, en prime, le destinataire aura appris à se reporter au guide d'utilisation avant de poster.

La stratégie n° 2 est un processus à long terme, qui dure tant que dure le projet et implique plusieurs participants. Bien sûr, il est question ici de documentation à jour (voir la section « Documentation » du Chapitre 2, Bien démarrer) et d'orientation des gens. Mais c'est bien plus que cela. La section qui suit examine cette stratégie en détail.

Utilisation visible des archives

Traditionnellement, toutes les communications échangées dans un projet Open Source (exceptées parfois les conversations IRC) sont archivées. Les archives sont publiques et consultables et elles ont une stabilité référentielle : c'est-à-dire qu'une fois qu'une information a été enregistrée à une adresse donnée, elle y reste pour toujours.

Utilisez ces archives autant que possible et aussi visiblement que possible. Même si vous connaissez par cœur la réponse à une question, si vous pensez qu'il y a dans les archives une référence qui contient la réponse, prenez le temps d'aller la chercher et de la montrer. Chaque fois que vous faites ceci publiquement et de manière visible, quelqu'un apprend pour la première fois que les archives sont là et qu'elles contiennent des réponses aux questions. De même, en vous référant aux archives plutôt que de ré-écrire la réponse vous renforcez la règle sociale qui lutte contre la duplication de l'information. Pourquoi avoir la même réponse à deux endroits différents ? Les gens retrouveront plus facilement une réponse qu'ils ont déjà dénichée si celle-ci n'est pas répliquée x fois. Des références faciles à localiser contribuent également à la qualité des résultats des recherches en général car elles renforcent la classification des ressources ciblées par les moteurs de recherche Internet.

Il existe pourtant des cas où dupliquer l'information peut avoir un sens. Imaginez par exemple qu'il y a déjà une réponse dans les archives, pas de vous, qui dit :

Il s'avère que vos index de Scanley ont été embrouillés. Pour les désembrouiller, suivez les étapes suivantes :

  1. Eteignez le serveur Scanley.
  2. Lancez le programme « désembrouillage » livré avec Scanley.
  3. Redémarrez le serveur.

Puis, des mois plus tard, vous verrez un autre message expliquant que les index de quelqu'un ont été embrouillés. Vous cherchez dans les archives et trouvez l'ancienne réponse ci-dessus, mais vous vous rendez compte qu'il y manque quelques étapes (soit par erreur, soit parce que le logiciel a changé depuis la rédaction du message). Il vaut alors mieux poster de nouvelles instructions, plus complètes, et de rendre explicitement obsolète le message précédent en le mentionnant :

Il s'avère que vos index de Scanley ont été embrouillés. Nous avons vu ce problème en juillet dernier et A. Nonyme avait posté une solution à l'adresse http://blablabla/bla. Vous trouverez ci-dessous des indications plus complètes pour désembrouiler vos index, basées sur celles de A. Nonyme mais un peu plus développées :

  1. Eteignez le serveur Scanley
  2. Devenez l'utilisateur habituellement connecté au serveur Scanley
  3. Sous ce nom d'utilisateur, lancez le programme « désembrouillage » dans les index
  4. Lancez Scanley à la main pour voir si les index fonctionnent
  5. Redémarrez le serveur

(Dans un monde idéal il serait possible d'attacher une note à l'ancien message précisant que des informations plus récentes ont été apportées et d'y inclure un lien vers le nouvel article. Cependant, je ne connais aucun logiciel d'archivage qui propose une fonction « rendu obsolète par », peut-être parce qu'il serait difficile à mettre en oeuvre de façon à ce que l'intégrité des archives soit préservée en tant que trace verbatim. C'est là une autre raison qui justifie la création de pages Web dédiées consignant les réponses aux questions courantes.)

Les archives sont le plus souvent utilisées pour chercher des réponses aux questions techniques, mais leur importance pour le projet va au-delà. Si les règles formelles d'utilisation du projet constituent la loi ordinaire, les archives représentent le droit coutumier : des archives de toutes les décisions prises et des discussions qui y ont mené. Dans toute discussion récurrente il est plus ou moins obligatoire de nos jours de commencer par une recherche dans les archives. Ceci permet de commencer la discussion par une résumé de l'état actuel des choses, d'anticiper des objections, de parer aux réticences et probablement de trouver des idées auxquelles vous n'auriez pas pensé. Les autres participants aussi estimeront que vous êtes censé avoir fait une recherche dans les archives. Même si les discussions précédentes n'ont mené nulle part vous devriez mettre un lien qui y renvoi au moment de remettre la question sur le tapis pour que les gens constatent par eux-mêmes que : a) elles n'ont mené nulle part et b) vous avez fait votre boulot. Ils seront alors en mesure de dire quelque chose qui n'a pas été dit auparavant.

Traitez toutes les ressources comme des archives

Tous les conseils précédents ne s'appliquent pas qu'aux archives des listes de diffusion. Certaines informations doivent être enregistrées à des adresses stables, faciles à trouver. Ceci devrait être un principe en vigueur pour toute information concernant le projet. Prenons la FAQ du projet comme cas d'étude.

Comment les gens utilisent-ils une FAQ ?

  1. Ils veulent pouvoir y chercher des mots et des phrases
  2. Ils veulent pouvoir la parcourir, aller à la pêche aux informations sans chercher nécessairement de réponses à des questions particulières
  3. Ils s'attendent à ce que le contenu de la FAQ soit accessible aux moteurs de recherche tel que Google, de manière à ce que les recherches pointent vers les rubriques de la FAQ
  4. Ils veulent pouvoir indiquer à d'autres personnes des articles spécifiques de la FAQ
  5. Ils veulent pouvoir ajouter de nouveaux éléments à la FAQ. Notez néanmoins que ceci est bien moins courant que la recherche de réponses : on lit plus souvent une FAQ qu'on y écrit

Le point 1 implique que la FAQ soit disponible sous forme de texte. Les point 2 et 3 impliquent que la FAQ doit être disponible au format HTML et le point 2 indique de plus que le HTML doit être adapté à la lecture (c'est-à-dire en tenant compte de l'apparence) et proposer une table des matières. Le point 4 signifie que chaque entrée de la FAQ doit faire l'objet d'une ancre à son nom, une étiquette qui permet d'atteindre un endroit particulier de la page. Le point 5 suppose que les fichiers sources de la FAQ doivent être accessibles de manière commode (voir la section « Tout versionner » du Chapitre 3, Infrastructure technique), dans un format facile à éditer.

Ancres nommées (named anchors) et attributs ID

Il existe deux solutions pour qu'un navigateur se place à un endroit précis d'une page Web : les ancres nommées et les attributs ID.

Une ancre nommée n'est qu'une ancre html normale (<a>...</a>), à laquelle on attribue un « nom » :

<a name="monetiquette">...</a>

Des versions plus récentes de HTML supportent un attribut id générique qui peut être attaché à n'importe quel élément HTML et pas seulement à <a>. Par exemple :

<p id="monetiquette">...</p>

Ancres nommées et attributs id sont utilisés de la même façon. On fait suivre l'URL d'un dièse et de l'étiquette pour que le navigateur aille directement à cet endroit de la page :

http://monprojet.exemple.com/faq.html#monetiquette

Théoriquement tous les navigateurs supportent les ancres nommées ; les plus récents supportent les attributs id. Par prudence, je recommande soit de n'utiliser que des ancres nommées, soit des ancres nommées et des attributs id ensemble (avec la même étiquette pour les deux, évidemment). Les ancres nommées ne sont pas auto-fermantes : même s'il n'y a pas de texte à l'intérieur de l'élément, il faut l'écrire en deux parties :

<a name="monetiquette"></a>

...bien que normalement il devrait y avoir un texte, comme un titre de section.

Que vous utilisiez une ancre nommée, un attribut id ou les deux, rappelez-vous que les visiteurs qui parcourent la page sans utiliser d'étiquette ne voient pas la différence. Mais cette personne peut vouloir connaître l'étiquette d'une section en particulier, pour pouvoir envoyer l'URL de la réponse de la FAQ à un ami par exemple. Pour l'y aider, ajoutez un titre aux éléments auxquels vous avez ajouté un « nom » et/ou un « id », par exemple :

<a name="monetiquette" title="#monetiquette">...</a>

En plaçant le pointeur de la souris sur le texte qui se trouve à l'intérieur de l'attribut « title », la plupart des navigateurs ouvriront une petit fenêtre où s'affiche le titre. J'ajoute généralement le dièse pour rappeler à l'utilisateur que c'est le symbole qu'il devra ajouter à la fin de l'URL pour aller directement à cet endroit la prochaine fois.

Ce n'est qu'un exemple de mise en page de la FAQ qui permet d'en faire un ressource présentable. Les mêmes propriétés, accès direct lors de la recherche, accessibilité aux principaux moteurs de recherche Internet, navigabilité, stabilité du référentiel et, le cas échéant, capacité d'édition s'appliquent également à d'autres pages Web, à l'arborescence du code source, au système de suivi de bogues, etc. Il se trouve que la plupart des logiciels d'archivage des listes de diffusion ont reconnu depuis longtemps l'importance de ces propriétés, c'est pourquoi les listes ont tendance à inclure ces fonctions de manière native alors que d'autres formats exigent un effort supplémentaire de la part de celui qui est chargé de leur maintenance (le Chapitre 8, Gérer les volontaires examine comment distribuer la charge de cette maintenance entre plusieurs volontaires).

Codifier la tradition

Quand l'histoire d'un projet s'étoffe et gagne en complexité, la quantité de données que chaque nouvel arrivant doit assimiler augmente. Ceux qui participent au projet depuis longtemps ont pu apprendre, voire forger, les conventions du projet en cours de route. Très souvent, ils n'auront pas clairement conscience du corpus de traditions qui s'est accumulé et seront surpris des nombreux impairs que les nouveaux sont susceptibles de commettre. Bien sûr, le problème n'est pas que les nouveaux venus sont moins bon qu'avant ; c'est que l'effort d'acclimatation qu'ils doivent consentir est plus important que pour les nouveaux venus d'avant.

Les traditions qu'un projet accumule portent aussi bien sur la communication et la préservation de l'information que sur la qualité du code ou d'autres détails techniques. Nous avons déjà examiné ces deux cas de figure dans les sections « Documentation développeur » du Chapitre 2 et « Tout mettre par écrit » du Chapitre 4, respectivement, où des exemples ont été fournis. Ici nous allons plus particulièrement nous concentrer sur la mise à jour de ces informations avec l'évolution du projet et plus particulièrement celles relatives à la gestion des communications, c'est en effet le domaine qui évolue le plus quand le projet gagne en taille et en complexité.

Premièrement, cherchez ce qui est le plus déroutant pour les gens. Si les mêmes situations se répètent sans cesse, particulièrement avec les nouveaux participants, il y a des chances que le guide ne soit pas documenté. Deuxièmement, ne vous lassez pas de répéter cent fois les mêmes choses et n'ayez pas l'air las en les répétant. Vous, ainsi que les autres vétérans du projet, aurez à vous répéter souvent ; c'est un effet secondaire inévitable de l'arrivée de nouveaux participants.

Chaque page Web, chaque message de la liste, chaque canal IRC doivent être considérés comme des espaces publicitaires : non pas pour passer des annonces commerciales, mais pour faire la réclame des ressources propres au projet. Ce que vous mettrez dans chaque espace dépend de la population susceptible de le lire. Un canal IRC consacré aux questions des utilisateurs, par exemple, amènera des gens qui n'ont jamais été en relation avec le projet auparavant, typiquement quelqu'un qui vient d'installer le logiciel et qui aimerait une réponse immédiate à sa question (après tout, si ça pouvait attendre, il l'aurait postée sur la liste de diffusion, ce qui lui prendrait probablement moins de temps dans l'ensemble, bien que le délai pour la réponse soit plus long). Les gens n'investissent généralement pas le canal IRC sur la durée : ils surgissent, posent leur question et s'en vont.

C'est pourquoi le sujet du canal doit viser les gens qui cherchent des réponses techniques immédiates, plutôt que, disons, des gens qui pourraient s'investir dans le projet à long terme et pour qui le manuel des usages de la communauté serait plus approprié. Voici comment un canal réellement actif gère la question (à comparer avec l'exemple précédent dans la section « IRC et les chats en temps réel » du Chapitre 3, Infrastructure Technique) :


Vous êtes actuellement sur #linuxhelp
Le sujet de #linuxhelp est SVP lisez
http://www.catb.org/~esr/faqs/smart-questions.html et
http://www.tldp.org/docs.html#howto AVANT de poser une question | Les règles
du canal se trouvent ici : http://www.nerdfest.org/lh_rules.html | Veuillez consulter
http://kerneltrap.org/node/view/799 avant de poser une question
sur la mise à jour 2.6.x | aide mémoire : http://tinyurl.com/4s6mc ->
mise à jour 2.6.8.1 ou 2.4.27 | sinistre algorithme de hachage : http://tinyurl.com/6w8rf
| reiser4 out


Dans les listes de diffusion, l'« espace publicitaire » c'est la note de bas de page (footer) ajoutée à la fin de chaque message. La plupart des projets y font figurer les instructions pour s'inscrire/se désinscrire ainsi qu'éventuellement un lien vers la page d'accueil du projet ou vers la FAQ. Vous pensez peut-être que tous les abonnés de la liste savent où trouver ces informations, et c'est vraisemblablement le cas, mais bien des personnes autres que les abonnés voient les messages de la liste. Des liens peuvent pointer vers le courrier archivé en de nombreux endroits ; de fait, certains messages deviennent si connus qu'ils peuvent avoir plus de lecteurs hors liste que dans la liste.

Le formatage peut apporter un réel plus. Par exemple, dans le projet Subversion nous avions un succès limité avec l'utilisation de la technique de filtrage de bogues décrite dans la section « Filtrer le système de suivi des bogues en amont » du Chapitre 3, Infrastructure technique. De nombreux rapports de bogues bidons étaient créés par des gens inexpérimentés et, chaque fois que cela se produisait, il fallait former le rapporteur exactement de la même manière que les 500 rapporteurs précédents. Un jour, alors qu'un de nos développeurs avait fini par perdre patience et s'en était pris à un pauvre utilisateur qui n'avait pas lu assez attentivement le manuel du traqueur de bogues un autre développeur décida que la situation avait assez durée. Il proposa une refonte de la page d'accueil du traqueur de bogues pour faire ressortir en gros caractères rouge et gras sur fond jaune, bien centrés en tête de page, le point le plus important, à savoir l'incitation à discuter du bogue sur la liste de diffusion et sur le canal IRC avant de remplir un rapport. Ce qui fut fait (vous pouvez voir le résultat sur http://subversion.tigris.org/project_issues.html). Il en résulta une baisse notable du nombre de rapports de bogues bidons. Nous en recevons encore bien sûr, nous en recevrons toujours, mais le taux a baissé considérablement et ce malgré l'augmentation du nombre d'utilisateurs. Ainsi, non seulement notre base de données contient moins de déchets, mais ceux qui travaillent à résoudre les bogues conservent leur bonne humeur et ont plus de chance de rester aimables au moment de répondre à l'un de ces rares rapports bidons. L'image du projet n'en est que meilleure et la santé mentale des volontaires est épargnée.

Conclusion : il ne suffit pas simplement de mettre les règles par écrit. Il faut également les rendre visibles à ceux qui en ont le plus besoin et les présenter de telle sorte que leur rôle de support d'introduction au projet soit suffisamment clair pour ceux qui ne connaissaient pas le projet.

Des pages Web statiques ne sont pas les seuls espaces pour promouvoir les us et coutumes du projet. Une certaine dose de veille interactive (dans le sens de « rappel amical » plutôt que de « mettre à l'amende ») est également nécessaire. Toute révision par les pairs, y compris les révisions de commit décrites dans la section intitulée « Effectuez une inspection visible du code » du Chapitre 2, Bien démarrer, devraient commenter le respect des normes du projet, notamment des conventions de communication.

Voici un autre exemple tiré du projet Subversion : nous avons fixé par convention que « r12908 » signifait « révision 12908 dans le dépôt de gestion de version ». Le préfixe en bas de casse « r » est facile à taper et sa taille étant moitié moindre que celle des chiffres on obtient un bloc de texte facilement reconnaissable. Bien sûr, le fait de fixer cette convention n'implique pas que tout le monde va l'utiliser immédiatement et uniformément. Ainsi, quand arrive un message de commit avec un message du fichier journal tel que celui-ci :

------------------------------------------------------------------------
r12908 | qsimon | 2005-02-02 14:15:06 -0600 (Wed, 02 Feb 2005) | 4 lines
Correctif de A. Nonyme <anonyme@gmail.com>
* trunk/contrib/client-side/psvn/psvn.el:
Corrigé quelques typos sur la révision 12828. 
------------------------------------------------------------------------

...la relecture de ce commit comprend également un petit mot du genre : « Au fait, utilisez de préférence 'r12828' au lieu de 'révision 12828' pour parler des changements précédents. » Ce n'est pas juste de la pédanterie : c'est aussi important pour l'indexation automatique que pour la lisibilité humaine.

En suivant le principe général selon lequel il devrait y avoir une méthode de référence pour des unités communes et que ces méthodes de référence devraient être utilisées partout uniformément, le projet exporte de manière effective certaines normes. Ces normes permettent aux gens d'écrire des outils qui rendet l'exploitation des échanges du projet plus aisée. Une révision sous la forme « r12828 » peut être transformée en lien vivant dans le système de navigation du dépôt par exemple. Ceci serait plus difficile à faire si la révision avait été notée sous la forme « révision 12828 », d'une part parce que cette expression aurait pu être divisée par un retour à la ligne et d'autre part parce qu'elle est moins distincte (le mot révision, avec ou sans accent, apparaîtra souvent isolé des chiffres, tandis que la combinaison « r12828 » ne peut que signifier « numéro de révision »). Des problèmes similaires se posent pour les numéros d'émissions, les points de la FAQ (une piste : utilisez des URL avec des ancres nommées, comme indiqué dans « Ancres nommées et attributs ID »), etc.

Même pour les unités où il n'y a pas d'étalon défini les gens devraient être encouragés à fournir les informations clés de manière uniformisée. Par exemple pour vous référer à un message d'une liste de diffusion ne mentionnez pas seulement l'émetteur et le sujet, citez également l'URL de l'archive et le Message-ID de l'en-tête. Ce dernier permet à ceux qui ont leur propre copie de la liste de diffusion (certaines personnes conservent une copie hors ligne, pour l'utiliser sur un portable lors d'un voyage par exemple) d'identifier univoquement le message même s'ils n'ont pas accès aux archives. L'émetteur et le sujet ne suffisent pas car la même personne peut avoir posté plusieurs fois le même jour dans le même fil.

Plus un projet grandit plus cette uniformité devient importante. Grâce à l'uniformité, quelle que soit la situation, les mêmes règles sont appliquées, ce qui incite les gens à suivre ces mêmes règles. Ceci, en retour, réduit le nombre de questions qu'ils ont à poser. Avoir 1 lecteur ou 1 million de lecteur ne fait pas de différence ; les problèmes d'échelle commencent à apparaître seulement quand un certain pourcentage de ces lecteurs posent des questions. Quand le projet grandit il faut donc réduire ce pourcentage en augmentant la densité et l'accessibilité de l'information pour que chaque personne ait plus de chance de trouver ce dont elle a besoin sans avoir à le demander.

== Pas de discussions dans le système de suivi de bogues ==

Dans tous les projets qui font un usage actif d'un système de suivi de bogues existe le danger que celui-ci devienne un forum de discussion en lui-même, malgré la présence des listes de diffusion. Généralement cela commence innocemment : quelqu'un note un problème et propose une solution ou un correctif partiel. Quelqu'un d'autre le remarque, se rend compte que la solution proposée n'a pas que du bon et attache une autre note indiquant ces problèmes. La première personne répond en ajoutant une note sur la question... et ainsi de suite.

Le problème est que, premièrement, le système de suivi de bogues est un endroit trop encombré pour y mener une discussion et, deuxièmement, les autres peuvent ne pas y prêter attention car ils s'attendent à ce que les discussions sur le développement aient lieu sur la liste « développement », c'est donc là qu'ils regarderont. Il est possible qu'ils ne soient même pas abonnés à la liste « résolution de problèmes » et, même s'ils le sont, ils ne suivent peut-être pas de près ce qu'il s'y passe.

Mais à quel moment précis du processus quelque chose est allé de travers ? Est-ce quand la personne du début a ajouté sa solution à l'endroit où le problème était décrit : aurait-elle dû plutôt la poster sur la liste ? où est-ce quand la deuxième personne a répondu au même endroit plutôt que sur la liste ?

Plutôt qu'une unique bonne réponse, voici un principe général : si vous ajoutez des données à un sujet faites-le sur le système de suivi, mais si vous démarrez une discussion faites-le sur la liste. Vous ne serez peut-être pas toujours en mesure de déterminer dans quelle catégorie ranger votre intervention, mais suivez votre jugement. Par exemple, au moment de joindre un correctif qui contient une solution qui peut prêter à controverse, vous devez anticiper le fait que les gens auront des questions à poser. Donc, même si vous auriez trouvé normal de joindre le correctif à la description du problème (en supposant que vous ne voulez ou ne pouvez pas valider le changement directement), vous devriez plutôt choisir de le poster sur la liste de diffusion. De toute façon, les échanges aboutiront à un point où l'une des parties dira que cela va plus loin que l'ajout pur et simple de données et qu'il faut une vraie discussion; dans l'exemple qui ouvre cette partie, ce serait à celui qui répond en deuxième, en comprenant qu'il y a des problèmes sur le correctif, de prévoir qu'il en découlera une vraie discussion et qu'elle doit avoir lieu sur le support approprié.

Pour utiliser une analogie mathématique : si l'information vous semble pouvoir converger rapidement mettez la directement dans le système de suivi de bogues ; si elle a l'air divergente, la liste de discussion ou le canal IRC semblent mieux appropriés.

Ceci ne veut pas dire qu'il ne devrait jamais y avoir d'échanges dans le système de suivi. Demander des détails supplémentaires sur la façon de reproduire le bogue au rapporteur initial est un processus hautement convergent par exemple. La réponse de la personne a peu de chances de soulever de nouvelles questions ; cela ne fait qu'étayer l'information référencée précédemment. Il n'y a pas lieu de perturber la liste avec ce processus. Essayez au maximum de régler cette question par une série de commentaires à même le système de suivi. De même, si vous êtes certain qu'un bogue a été rapporté à tort (c'est-à-dire qu'il ne s'agit pas d'un bogue), vous pouvez le dire directement sur le système de suivi. Même souligner un problème mineur à propos d'une solution proposée est acceptable, du moment que le problème en question ne compromet pas l'ensemble de la solution.

D'un autre côté, si vous soulevez des questions philosophiques sur la portée d'un bogue ou sur le comportement correct du logiciel vous pouvez être sûr que d'autres développeurs voudront y participer. La discussion divergera vraisemblablement pendant un moment avant de converger de nouveau : menez-la donc sur la liste.

Donnez toujours des liens vers le système de suivi quand vous choisissez de poster sur la liste. Il est important que tous ceux qui suivent le bogue puissent accéder à la discussion même si l'endroit où il est rapporté n'est pas le lieu où se tient la discussion. La personne qui démarre le fil de discussion trouvera sans doute cela pénible, mais le milieu du logiciel libre est fondamentalement une culture de la responsabilité par l'écrit : il est bien plus important de faciliter le travail aux dizaines ou centaines de personnes qui liront le bogue qu'aux trois ou quatre qui écrivent dessus.

On peut aussi extraire des conclusions ou des résumés importants de la liste de discussion pour les coller dans le système de suivi si cela aide les lecteurs. Un usage courant consiste à commencer une discussion dans la liste en mettant un lien vers le rapport de bogue, puis, une fois la discussion achevée, de coller le résumé dans le système de suivi (avec un lien vers le message qui contient le résumé, pour que ceux qui parcourent le suivi puissent voir facilement la conclusion à laquelle on est arrivé sans avoir à cliquer ailleurs. Notez que le problème courant des « deux originaux », problème de duplication des données, n'existe pas ici, car aussi bien les archives que les commentaires de bogue sont généralement des données statiques, non modifiables de toute façon.

Les annonces

Dans le monde des logiciels libres la frontière entre discussions internes et communiqués officiels est ténue. C'est en partie dû au fait que l'on ne sait jamais exactement à quel publique on s'adresse : comme pratiquement tous les messages sont accessibles publiquement le projet ne contrôle pas entièrement l'appréciation du public. Quelqu'un, disons un éditeur de slashdot.org, pourrait attirer l'attention de millions de lecteurs sur un message que personne ne s'attendait à voir sortir du projet. C'est un aléa de la vie avec lequel tous les projets Open Source doivent composer, mais dans la pratique le risque est en général très faible. Habituellement les annonces que le projet veut rendre publiques sont celles qui seront le plus mises en avant, à condition que vous utilisiez les bons outils pour indiquer l'importance relative de votre communiqué au monde extérieur.

Pour les annonces majeures on peut distinguer quatre à cinq canaux principaux de distribution au travers desquels les annonces devraient être faites aussi simultanément que faire se peut :

1. La page d'accueil de votre site Web est certainement la partie la plus visible du projet. Si vous devez faire une annonce particulièrement importante, affichez-y votre petit discours. Cela doit rester concis, un petit résumé qui renvoi vers le communiqué de presse (voir ci-dessous).

2. Parallèlement, vous devriez avoir aussi une section « Nouvelles » ou « Communiqués de presse » sur votre site Web où vous pourrez afficher toutes les annonces en détail. Les communiqués de presse servent de vitrine vers laquelle les autres sites peuvent re-diriger leurs lecteurs. Assurez vous donc qu'ils soient structurés en fonction : soit sous la forme d'une page Web par communiqué, soit par un nouvel article distinct ou sous n'importe quelle forme tant que l'on peut y accéder grâce à un lien sans qu'il y ait confusion possible avec d'autres communiqués.

3. Si vous avez créé un flux RSS pour votre projet, assurez vous qu'il relaie également l'annonce. Cela peut se faire automatiquement lorsque vous créez le communiqué de presse selon la configuration de votre site Web (les flux RSS sont des outils pour distribuer des résumés de nouvelles contenant des meta-données aux « abonnés », c'est-à-dire aux personnes qui ont fait en sorte de recevoir ces résumés. Voir http://www.xml.com/pub/a/2002/12/18/dive-into-xml.html pour plus d'informations à propos des flux RSS).

4. Si l'annonce que vous passez concerne une nouvelle version vous devez aussi modifier la page du projet sur http://freshmeat.net (voir la section nommée «  Annoncer » pour savoir comment créer cette page). Dès que vous modifiez votre page sur Freshmeat la modification est annoncée sur la liste des changements du jour de Freshmeat. Cette liste est mise à jour sur Freshmeat mais aussi sur d'autres portails (slashdot.org compris) qui sont avidement surveillées par des hordes de gens. Freshmeat relaie également ces informations par son flux RSS. Ainsi, les gens qui ne sont pas abonnés à votre propre flux RSS pourront quand même recevoir l'annonce par celui de Freshmeat.

5. Envoyez un e-mail à la liste de diffusion d'annonces de votre projet. Le nom de cette liste devrait d'ailleurs êtres « annonce », c'est-à-dire que l'adresse devrait être annonce@domaineduprojet.org parce que c'est devenu une norme maintenant et la charte de la liste devrait annoncer clairement qu'elle engendrera l'envoi de peu de mails et qu'elle est réservée aux annonces du projet. La plupart des annonces concerneront les nouvelles versions du logiciel mais aussi à l'occasion d'autres évènements comme une collecte de fonds, la découverte d'une faille de sécurité (voir la section « Annoncer les failles de sécurité » plus tard dans ce chapitre) ou encore un bouleversement dans la vie du projet pourront y être postés. Parce qu'elle génère peut de trafic et qu'elle n'est employée que pour des choses importantes, la liste d'annonces possède en général le plus grand nombre d'abonnés parmi toutes les listes du projet (ce qui implique donc que vous ne devriez pas en abuser, tournez sept fois vos doigts au dessus du clavier avant d'y poster). Pour éviter que n'importe qui y fasse des annonces, ou pire encore, qu'elle serve à envoyer des spams, la liste d'annonces doit toujours être modérée.

Il faut que les annonces soient faites aussi simultanément que possible sur tous ces outils. Les gens pourraient trouver ça bizarre de voir l'annonce faite sur la liste de diffusion et de ne pas la retrouver sur la page d'accueil du projet ou dans la section « Communiqués de presse ». Si vous pouvez préparer les différentes modifications (e-mails, modifications de pages Web, etc.) et les envoyer d'un coup, les uns à la suite des autres, la période de « contradiction » pourra être largement réduite.

Pour un évènement de moindre importance vous pouvez réduire le nombre de canaux employés, voir même n'en utiliser aucun. L'évènement sera quand même remarqué par le monde extérieur à hauteur de son importance. Par exemple, alors que la sortie d'une nouvelle version d'un logiciel est un évènement important, le simple fait d'annoncer la date de la future version, même si cela reste une nouvelle importante, est loin d'être aussi important que la sortie en elle-même. Quand une date est arrêtée pour la prochaine version vous pouvez très bien vous contenter d'envoyer un mail sur les listes de diffusions générales (pas la liste d'annonces) et mettre à jour les prévisions du projet ou la page d'avancement.

Vous verrez malgré tout cette date apparaître dans les discussions sur d'autres sites Internet, partout où des gens sont intéressés par votre projet. Les gens qui suivent votre liste de diffusion, qui ne font que la consulter sans jamais y participer, ne sont pas nécessairement muets ailleurs. Le bouche à oreille peut porter rapidement les nouvelles, vous devriez compter dessus et rédiger les annonces même mineures de manière à encourager la transmission exacte de l'information. En particulier, les messages que vous espérez voir cités devraient contenir une partie explicitement faite pour être citée, comme si vous écriviez un communiqué de presse officiel. Par exemple :

Quelque nouvelles sur l'avancement : nous pensons sortir la version 2.0 de Scanley vers la mi-août 2005. Nous vous invitons à consulter la page http://www.scanley.org/status.html régulièrement pour connaître les dernières nouvelles. La grosse nouveauté sera la recherche par expression habituelle.
Parmi les autres nouvelles fonctionnalités vous retrouverez : ... Nous ajouterons également différentes corrections de bogues, à commencer par : ...

Le premier paragraphe est succin et donne les deux informations principales (la date de sortie et la grande nouveauté) ainsi que l'URL à visiter pour plus d'informations. Si ce paragraphe est le seul à être repris vous aurez quand même réussi à passer l'information. Le reste du mail peut-être « oublié » sans amputer le message de son essence. Il y aura toujours des personnes qui mettront un lien vers le mail complet, mais il est aussi probable qu'ils n'en citeront qu'une partie. Puisque cette possibilité existe, autant leur simplifier la tâche et par la même occasion contrôler un peu mieux ce qui sera cité.

Annoncer les failles de sécurité

La gestion d'une faille de sécurité est différente de la gestion des autres rapports de bogue. Dans le logiciel libre, tout faire de manière ouverte et transparente relève presque du sacerdoce. Chaque étape d'une correction de bogue standard est visible aux yeux de tous ceux que cela intéresse : l'envoi du rapport initial, la discussion qui s'en suit et le correctif.

Les bogues de sécurité sont différents. Ils peuvent mettre en danger des données des utilisateurs voire même leur système entier. Parler de ce problème ouvertement alerterait tout le monde, y compris ceux qui voudraient en faire un usage malveillant. Le simple fait d'envoyer un correctif annonce l'existence du bogue (des agresseurs potentiels surveillent les journaux de commit des projets publiques à la recherche de modifications qui indiquent des problèmes de sécurité). La plupart des projets Open Source se sont mis d'accord sur une série d'étapes à peu près standard pour gérer ce conflit entre ouverture et discrétion, elles sont basées sur ces quelques grandes lignes :

  1. Ne pas parler du bogue en public tant qu'il n'y a pas de correctif disponible, fournir le correctif exactement au même moment où vous annoncez le bogue.
  2. Concocter un correctif aussi rapidement que possible, surtout si c'est quelqu'un d'étranger au projet qui a rapporté le bogue, parce qu'alors vous savez qu'au moins une personne en dehors du projet est capable d'exploiter la vulnérabilité.

Dans la pratique, ces principes ont donné naissance à une série de mesures plus ou moins standardisées qui sont décrites dans les parties suivantes.

Réception du rapport

Pour commencer, le projet doit évidemment pouvoir recevoir un rapport de bogue de sécurité de n'importe qui. Mais l'adresse normale pour rapporter les bogues n'est pas adaptée ici parce qu'elle peut être vue par tout le monde. Il vous faudra donc une adresse différente pour recevoir les rapports de bogue de sécurité. Les archives de cette liste de diffusion ne doivent pas être visibles publiquement et les abonnés doivent être triés sur le volet, seuls les développeurs présents de longue date et surs peuvent être sur cette liste. S'il vous faut une définition plus concrète de « surs » voyez cela comme « toute personne qui possède l'accès de commit depuis deux ans au moins » ou quelque chose comme ça pour éviter le favoritisme. C'est le groupe qui devra gérer les failles de sécurité.

Idéalement cette liste de sécurité ne devrait pas être protégée du spam ou modérée ou alors vous risqueriez d'évincer un rapport important ou de le retarder parce qu'aucun modérateur n'était disponible ce week-end. Si par contre vous utilisez un logiciel pour vous prémunir du spam utilisez des réglages tolérants, il vaut mieux laisser passer quelques spams que de manquer un rapport. Pour que cette liste soit efficace vous devez évidemment rendre son adresse bien visible, mais comme elle ne sera pas modérée et qu'au mieux elle sera faiblement protégée contre le spam ne l'affichez jamais sans transformation, masquez la comme nous l'avons vu dans la section « Masquer les adresses dans les archives » dans le Chapitre 3, Infrastructure technique. Heureusement, le masquage de l'adresse ne la rend pas nécessairement illisible, voir http://subversion.tigris.org/security.html et jetez un œil à son code source pour y trouver un exemple.

Développer le correctif en secret

Que doit donc faire la liste de sécurité quand elle reçoit un rapport ? Elle doit en premier lieu évaluer la sévérité du problème et son urgence :

1. Quelle est la gravité de la vulnérabilité ? Est-ce qu'elle permet à un agresseur malintentionné de prendre le contrôle de l'ordinateur d'une personne utilisant le logiciel ? Ou ne fait-elle, par exemple, que divulguer des informations à propos de la taille de certains fichiers ?

2. Avec quelle facilité peut-on exploiter cette vulnérabilité ? Une attaque peut-elle être scriptée ou requiert-elle une connaissance détaillée, du raisonnement et de la chance ?

3. Qui a rapporté le problème ? La réponse à cette question ne change pas la nature de la vulnérabilité évidemment, mais cela vous donne une idée du nombre de personnes qui pourraient être au courant. Si le rapport provient de l'un des développeurs du projet vous pouvez vous détendre un peu (mais seulement un peu), en effet, vous pouvez lui faire confiance pour ne pas l'avoir ébruité. À l'opposé, si c'est un e-mail de anonyme14@globalhackers.net que vous recevez, vous devriez agir au plus vite. Cette personne vous a rendu service en vous informant du problème, mais vous n'avez aucune idée du nombre de personnes qu'elle a pu mettre au courant ou de combien de temps elle attendra avant d'exploiter la faille à grande échelle.

Comme vous l'avez remarqué, l'éventail d'urgence ne s'étend que de « urgent » à « extrêmement urgent ». Même si le rapport provient d'une source connue et inoffensive il peut très bien y avoir d'autres personnes sur le Net qui ont découvert le bogue depuis longtemps mais qui ne l'ont pas rapporté. Le seul cas de figure où il n'y a pas vraiment urgence est quand par sa nature le bogue ne pose pas de risque important de sécurité.

Et au fait, l'exemple de « anonyme14@globalhackers.net » n'est pas facétieux. Il est fort probable que vous receviez des rapports de bogues de personnes masquant leur identité et qui, par leurs mots ou leur comportement, n'établissent jamais clairement s'ils sont de votre côté ou contre vous. Cela n'a pas d'importance : s'ils vous ont rapporté la faille de sécurité ils se diront qu'ils vous ont fait une faveur et vous devriez répondre en conséquence. Remerciez les pour le rapport, donnez leur un délai dans lequel vous prévoyez de fournir un correctif public et gardez les dans la confidence. Parfois ils vous donneront une date, c'est une menace implicite de publier le bogue à une échéance donnée, que vous soyez prêt ou non. Ça peut ressembler à de l'intimidation, mais il faut plutôt y voir une action préventive, fruit de déceptions passées dues au manque de réactivité de fabricants de logiciels qui n'ont pas pris ces rapports de sécurité au sérieux. Quoiqu'il en soit vous ne pouvez pas vous permettre d'ignorer cette personne. Après tout, si le bogue est important, elle dispose des connaissances nécessaires pour vous causer de gros ennuis. Traiter ces rapporteurs correctement en espérant qu'ils en feront de même en retour.

Un autre cas fréquent est le rapport de bogue rédigé par un professionnel en sécurité, quelqu'un qui gagne sa vie en inspectant les codes et qui garde toujours un œil sur les dernières vulnérabilités des logiciels. Ces personnes possèdent en général la double expérience d'avoir déjà reçu des rapports de bogues et d'en avoir envoyé aussi, sûrement plus que la plupart des développeurs de votre projet. Ils sont aussi coutumier des dates limites imposées avant lesquelles vous devez réparer le problème avant qu'il ne dévoile la faille au public. Dans certains cas vous pouvez négocier cette date, mais tout dépend du rapporteur. Le fait d'imposer une date limite s'est imposé petit à petit dans le monde des professionnels en sécurité comme le seul moyen sûr pour que les entreprises répondent rapidement aux problèmes de sécurité. Ne voyez donc pas ces dates limites comme une pratique grossière, si cette manière de faire s'est imposée avec le temps c'est qu'il y a de bonnes raisons.

Une fois la sévérité et l'urgence établis vous pouvez commencer à travailler sur le correctif. Il faut trouver le bon équilibre entre faire les choses avec élégance et faire les choses rapidement. C'est la raison pour laquelle il faut déterminer l'urgence de la situation avant de commencer. Il faut que la discussion concernant le correctif reste entre les membres de la liste de sécurité et le rapporteur initial (s'il veut être impliqué) et tout développeur dont les compétences seront nécessaires.

N'enregistrez pas le correctif dans le dépôt. Il faut le garder à l'écart jusqu'à la date de publication. Si vous l'enregistriez, même avec un message de journal innocent, quelqu'un pourrait le remarquer et comprendre la modification. Vous ne savez jamais qui surveille votre dépôt ou pour quelles raisons. Arrêter les e-mails de commit n'arrangerait rien, en premier lieu parce qu'un trou dans la suite des courriers serait suspicieux et de toute façon les données se retrouveraient dans le dépôt. Contentez vous de mener tout le développement hors du dépôt et conservez ce travail dans un endroit secret, pourquoi pas un dépôt privé, distinct, connu des seuls personnes déjà au courant du bogue (si vous utilisez un logiciel de gestion de version décentralisé comme Arch ou SVK vous pouvez travailler sous gestion de version et simplement empêcher l'accès à ce dépôt aux personnes externes).

Les numéros CAN/CVE

Vous avez déjà peut-être rencontré un numéro CAN ou CVE associé à un problème de sécurité. Il se présente en général sous cette forme : « CAN-2004-0397 » ou « CVE-2002-00923 ».

Ces deux types de numéros représentent la même chose : une entrée dans la liste des « Common Vulnerabilities and Exposures » ou « Vulnérabilités et Failles Courantes », cette liste est disponible à l'adresse http://cve.mitre.org/. Son but est de fournir des noms normalisés à tous les problèmes de sécurité connus afin que chacun ait un nom canonique unique que l'on peut employer pour le désigner et aussi de fournir un site de centralisation où l'on peut se rendre pour obtenir plus d'informations. La seule différence entre les numéros « CAN » et « CVE » est que le premier représente une demande d'inclusion (candidate entry), pas encore approuvée pour l'ajout à la liste officielle par l'équipe rédactionnelle de CVE et que le dernier désigne une entrée approuvée. Ces deux types d'entrées sont de toute façon visible par le public et le numéro de l'entrée n'est pas modifié lorsqu'elle est approuvée, le préfixe « CAN » est simplement remplacé par « CVE ».

Une entrée CAN/CVE ne renferme pas une description complète du bogue ou de comment s'en prémunir. On peut y trouver un bref résumé et une liste de liens vers des ressources externes (comme par exemple des archives de listes de diffusion) où peuvent se rendre les gens pour obtenir des informations plus détaillées. La vraie utilité de http://cve.mitre.org/ est de fournir un espace bien organisé dans lequel chaque vulnérabilité peut avoir un nom et où l'on peut trouver des liens vers des données plus complètes. Visitez la page http://cve.mitre.org/cgi-bin/cvename.cgi?name=2002-0092, vous y trouverez un exemple d'entrée. Attention, les références peuvent être très laconiques et les sources peuvent apparaître sous forme d'abréviations mystérieuses. Un glossaire des abréviations est cependant disponible : http://cve.mitre.org/cve/refs/refkey.html.

Si votre vulnérabilité remplit les critères de CVE, vous pouvez postuler pour un numéro CAN. Le processus pour ce faire est délibérément fermé, vous devez connaître quelqu'un, ou quelqu'un qui connaît quelqu'un. Ce n'est pas aussi étrange que cela puisse paraître. Afin d'éviter que l'équipe rédactionnelle de CVE ne croule sous les demandes mal rédigées, ils n'acceptent les soumissions que par des sources de confiance. Si vous souhaitez voir votre vulnérabilité listée vous devez donc d'abord trouver un intermédiaire entre votre projet et l'équipe rédactionnelle de CVE. Interrogez d'abord vos développeurs, il se peut très bien que l'un d'entre eux connaisse déjà quelqu'un qui serait passé par le processus CAN avant ou qu'il connaisse quelqu'un d'autre encore qui l'aurait déjà fait, etc. L'avantage de cette manière de procéder est que quelque part sur l'échelle de connaissances quelqu'un peut être suffisamment renseigné pour vous dire que a) votre demande ne répond pas aux critères de MITRE et que donc ce n'est pas la peine de la faire ou que b) cette vulnérabilité possède déjà un numéro CAN ou CVE. Ce dernier cas peut se produire si le bogue a déjà été publié sur une autre liste de sécurité, par exemple à l'adresse http://www.cert.org/ ou sur la liste de diffusion de BugTraq à l'adresse http://www.securityfocus.com/ (si cela se produit sans que votre projet n'en entende parler alors vous devriez vous demander quels autres évènements vous avez loupés).

Si vous réussissez finalement à obtenir un numéro CAN/CVE il vaut mieux l'avoir tout au début de vos recherches concernant le bogue afin que toutes les communications ultérieures puissent se référer à ce numéro. Il y a un embargo sur les entrées CAN maintenu jusqu'à leur date de publication, l'entrée reste vide mais sert à réserver le numéro afin de ne pas le perdre, mais elle ne révélera aucune information à propos de la vulnérabilité jusqu'à la date à laquelle vous annoncerez le bogue et le correctif.

Vous trouverez plus d'informations à propos du processus CAN/CVE à l'adresse http://cve.mitre.org/about/candidates.html ainsi qu'une explication particulièrement claire de l'utilisation de la numérotation CAN/CVE par un projet Open Source à l'adresse http://www.debian.org/security/cve-compatibility.

Pré-notification

Une fois que votre équipe de sécurité (c'est-à-dire les développeurs de la liste de diffusion de sécurité plus les personnes à qui on a fait appelle pour leurs compétences) a préparé un correctif vous devez décider de la manière de le distribuer.

Si vous ajoutez simplement ce correctif à votre dépôt, ou si vous mettez le monde au courant d'une quelconque manière, vous faites peser la menace d'une attaque sur vos utilisateurs qui seront alors obligés de mettre à jour le logiciel. Il est donc par conséquent parfois de bon ton de pré-notifier certains utilisateurs importants. C'est particulièrement vrai pour les logiciels client/serveur qui peuvent être utilisés par des serveurs bien connus qui pourraient devenir des cibles privilégiées des agresseurs. Les administrateurs de ces serveurs vous seraient reconnaissants d'avoir un délai d'un jour ou deux pour faire la mise à jour afin d'être déjà protégés lorsque la faille est rendue publique.

Vous avez simplement besoin d'envoyer un mail à ces administrateurs avant la date de publication les informant de la vulnérabilité et des solutions. Vous ne devriez envoyer ces pré-notifications qu'aux personnes en qui vous avez confiance. Pour rentrer dans cette catégorie il y a deux conditions : le destinataire doit administrer un serveur important où un risque pourrait avoir des conséquences grave et le destinataire doit avoir la réputation de quelqu'un qui n'ira pas ébruiter le problème de sécurité avant la date de publication.

Envoyez chaque e-mail de pré-notification individuellement (un par un) à chaque destinataire. Ne l'envoyez pas à une liste entière de destinataires en une fois parce qu'alors chacun verrait le nom des autres et ce serait comme les avertir que tous les autres destinataires ont peut-être une faille de sécurité sur leur serveur. Il ne faut pas non plus les envoyer en copie invisible (BCC pour Blind Carbon Copy) parce que les administrateurs protègent leurs boîtes de réception avec des filtres anti-spam qui bloquent ou abaissent la priorité des courriers reçus en BCC puisqu'énormément de spam est envoyé en BCC.

Voici un exemple de mail de pré-notification : Référence :

   CAN-2004-1771 : Scanley stack overflow in queries

Vulnérabilité :

   Il est possible de faire exécuter des commandes au hasard au serveur
   si le serveur est mal configuré et que le client envoie une requête mal
   conçue.

Contournements :

  Désactiver l'option 'natural-language-processing' dans scanley.conf
  ferme la faille.

Correctif :

  Le correctif qui suit s'applique à Scanley 3.0, 3.1 et 3.2
  Une nouvelle version publique (Scanley 3.2.1) sera publiée le
  19 mai ou juste avant afin d'être disponible au moment où
  la vulnérabilité sera divulguée. Vous pouvez appliquer le
  correctif maintenant ou simplement attendre la sortie publique.
  La seule différence entre les version 3.2 et 3.2.1 sera ce
  correctif

[...insérer le correctif ici...]

Si vous avez un numéro CAN indiquez le dans la pré-notification (comme ci-dessus) même si l'information est toujours sous embargo et que la page MITRE est donc encore vide. En ajoutant le numéro CAN vous êtes sûr que le destinataire sait avec certitude que le bogue pour lequel vous lui envoyez la pré-notification est le même que celui dont il entendra parler un peu plus tard par voie publique. Ainsi il n'a pas à se demander s'il doit prendre d'autres mesures ou pas, ce qui est précisément le but des numéros CAN/CVE.

Distribuez le correctif publiquement

La dernière chose qu'il vous reste à faire est de distribuer le correctif publiquement. Dans une annonce unique et complète vous devez décrire le problème, donner le numéro CAN/CVE s'il y en a un, décrire comment contourner le bogue et comment le régler définitivement. « Régler définitivement » implique souvent la mise à jour du logiciel même si parfois cela peut simplement vouloir dire appliquer un correctif, surtout si le logiciel est normalement utilisé sous forme de source. Si vous proposez une nouvelle version du logiciel, celle-ci ne doit différer de la précédente que par le correctif de sécurité. Les administrateurs plutôt conservateurs pourront ainsi faire la mise à jour sans se préoccuper d'autres conséquences. Ils n'ont pas à se soucier non plus des mises à jours futures puisqu'ils sauront que le correctif y sera également inclus (les détails concernant les procédures de publication sont abordés dans la section nommée « Mises à jour de sécurité » dans le Chapitre 7, Création de paquets, sorties et développement quotidien).

Que le correctif public implique une nouvelle version ou pas, faites l'annonce avec plus ou moins la même priorité que vous le feriez pour une nouvelle version : envoyez un mail à la liste de diffusion d'annonces, écrivez un nouveau communiqué de presse, mettez à jour votre entrée sur Freshmeat, etc. Vous ne devriez jamais essayer de minimiser l'existence d'une faille de sécurité si vous vous souciez un tant soit peu de la réputation de votre projet mais gardez toujours à l'esprit qu'il faut adapter le ton et la visibilité d'une annonce de sécurité à la sévérité concrète du problème. Si le bogue de sécurité n'est qu'un risque mineur de révélation d'informations, pas une faille qui permettrait la prise de contrôle totale de l'ordinateur de l'utilisateur alors il ne devrait pas faire tant de bruit. Vous n'aurez peut-être même pas besoin de déranger la liste d'annonce pour ça. Après tout, si le projet cri au loup à chaque fois, les utilisateurs finiront par croire que le logiciel est moins sécurisé qu'il ne l'est vraiment et pourront également ne pas vous croire si vous avez un vrai problème à annoncer. Voir http://cve.mitre.org/about/terminology.html, cette page constitue une bonne introduction à la détermination de la sévérité d'un bogue.

De manière générale, si vous n'êtes pas certain des suites à donner à un problème de sécurité, trouvez quelqu'un d'expérience avec qui vous pourrez en discuter. Évaluer et gérer les vulnérabilités ne s'apprend pas du jour au lendemain et il est courant de faire des erreurs les premières fois.

[18] Quelques recherches académiques intéressantes sont parues sur le sujet, je vous renvoie par exemple à Group Awareness in Distributed Software Development par Gutwin, Penner et Schneider (cet ouvrage était disponible en ligne mais il semble qu'il ne le soit plus, temporairement en tout cas, utilisez un moteur de recherche pour le trouver).




Chapitre 5 : L'argent
Page d'accueil du projet
Chapitre 7 : Paquets, sorties et développement quotidien
Outils personnels