POSSFR Chap 6

De Framalang Wiki.

(L'effet « minorité bruyante »)
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 ===
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.
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.
=== 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 :
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.
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 ===  
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 :
#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 :
#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 ===
:#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 ===
...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>
=== 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]]) :
: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 :
  ------------------------------------------------------------------------
  ------------------------------------------------------------------------
  ------------------------------------------------------------------------
  ------------------------------------------------------------------------
-
...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.
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.
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).
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.
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é.
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.
=== 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 ?
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 ===
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.
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 :
     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.
[...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

Outils personnels