POSS Chap 6 Part 2
Un article de Framalang Wiki.
Sommaire |
[modifier] Avoiding Common Pitfalls
[modifier] Don't Post Without a Purpose
A common pitfall in online project participation is to think that you have to respond to everything. You don't. First of all, there will usually be more threads going on than you can keep track of, at least after the project is past its first few months. Second, even in the threads that you have decided to engage in, much of what people say will not require a response. Development forums in particular tend to be dominated by three kinds of messages:
- Messages proposing something non-trivial
- Messages expressing support or opposition to something someone else has said
- Summing-up messages
None of these inherently requires a response, particularly if you can be fairly sure, based on watching the thread so far, that someone else is likely to say what you would have said anyway. (If you're worried that you'll be caught in a wait-wait loop because all the others are using this tactic too, don't be; there's almost always someone out there who'll feel like jumping into the fray.) A response should be motivated by a definite purpose. Ask yourself first: do you know what you want to accomplish? And second: will it not get accomplished unless you say something?
Two good reasons to add your voice to a thread are a) when you see a flaw in a proposal and suspect that you're the only one who sees it, and b) when you see that miscommunication is happening between others, and know that you can fix it with a clarifying post. It's also generally fine to post just to thank someone for doing something, or to say "Me too!", because a reader can tell right away that such posts do not require any response or further action, and therefore the mental effort demanded by the post ends cleanly when the reader reaches the last line of the mail. But even then, think twice before saying something; it's always better to leave people wishing you'd post more than wishing you'd post less. (See the second half of Appendix C, Why Should I Care What Color the Bikeshed Is? for more thoughts about how to behave on a busy mailing list.)
Éviter les pièges courants
Ne postez pas sans raison
Un des pièges dans la participation des projets en ligne consiste à penser qu'on doit répondre à tout. Ne le faites pas. Tout d'abord, il risque d'y avoir plus de fils de discussions que vous ne pouvez en suivre, en tout cas une fois que le projets aura dépassé ses tous premiers mois. Deuxièmement, même dans les fils que vous avez décidé de suivre, la majeure partie de ce qu'écrivent les gens ne nécessite pas de réponse. Dans les forums de développement plus particulièrement, trois types de messages prédominent :
- Des messages proposant quelque chose de pertinent
- Des messages pour exprimer son soutien ou son opposition à ce que quelqu'un d'autre a dit
- Des messages récapitulatifs
Aucun de ceux-là n'appelle intrinsèquement de réponse, notamment si vous êtes pratiquement certain, compte tenu de la teneur du fil jusque-là, que quelqu'un d'autre va probablement dire ce que vous auriez dit (Si vous craignez d'être pris dans une boucle du « toi d'abord » parce que les autres utilisent cette même tactique, détrompez-vous : il y a presque toujours quelqu'un qui aura envie de se jeter dans la mêlée). Une réponse doit être motivée par un objectif précis. Demandez-vous d'abord : est-ce que je sais où je veux en venir ? Puis : est-ce que ceci a des chances de se réaliser sans que je m'exprime ?
Deux bonnes raisons pour se méler à un fil de discussion sont : 1) quand on voit une faille dans une proposition et qu'on soupçonne être le seul à la voir et 2) quand on voit que les autres ont du mal à communiquer et qu'on pense pouvoir éclaircir la situation en postant un message. On peut aussi poster un message simplement pour remercier quelqu'un ou pour dire « Moi aussi ! », car le lecteur peut comprendre immédiatement que ce genre de messages n'entraîne aucune réponse ni aucune action, en conséquence de quoi l'effort mental requis par le message se termine proprement quand le lecteur atteint la dernière ligne du message. Mais même dans ce cas là, réfléchissez à deux fois avant de dire quelque chose ; il vaut mieux qu'on pense que vous pourriez poster plus et non que vous pourriez poster moins (Pour plus de réflexions sur le comportement à adopter sur une liste très active, voir la seconde partie de l'Annexe C, Pourquoi je devrais me soucier de la couleur de l'abri à vélo ?).
[modifier] Productive vs Unproductive Threads
On a busy mailing list, you have two imperatives. One, obviously, is to figure out what you need to pay attention to and what you can ignore. The other is to behave in a way that avoids causing noise: not only do you want your own posts to have a high signal/noise ratio, you also want them to be the sorts of messages that stimulate other people to either post with a similarly high signal/noise ratio, or not post at all.
To see how to do that, let's consider the context in which it is done. What are some of the hallmarks of an unproductive thread?
- Arguments that have been made already start being repeated, as though the poster thinks no one heard them the first time.
- Increasing levels of hyperbole and involvement as the stakes get smaller and smaller.
- A majority of comments coming from people who do little or nothing, while the people who tend to get things done are silent.
- Many ideas discussed without clear proposals ever being made. (Of course, any interesting idea starts out as an imprecise vision; the important question is what direction it goes from there. Does the thread seem to be turning the vision into something more concrete, or is it spinning off into sub-visions, side-visions, and ontological disputes?)
Just because a thread is not productive at first doesn't mean it's a waste of time. It might be about an important topic, in which case the fact that it's not making any headway is all the more troublesome.
Guiding a thread toward usefulness without being pushy is an art. It won't work to simply admonish people to stop wasting their time, or to ask them not to post unless they have something constructive to say. You may, of course, think these things privately, but if you say them out loud then you will be offensive. Instead, you have to suggest conditions for further progress—give people a route, a path to follow that leads to the results you want, yet without sounding like you're dictating conduct. The distinction is largely one of tone. For example, this is bad:
This discussion is going nowhere. Can we please drop this topic until someone has a patch to implement one of these proposals? There's no reason to keep going around and around saying the same things. Code speaks louder than words, folks.
Whereas this is good:
Several proposals have been floated in this thread, but none have had all the details fleshed out, at least not enough for an up-or-down vote. Yet we're also not saying anything new now; we're just reiterating what has been said before. So the best thing at this point would probably be for further posts to contain either a complete specification for the proposed behavior, or a patch. Then at least we'd have a definite action to take (i.e., get consensus on the specification, or apply and test the patch).
Contrast the second approach with the first. The second way does not draw a line between you and the others, or accuse them of taking the discussion into a spiral. It talks about "we", which is important whether or not you actually participated in the thread before now, because it reminds everyone that even those who have been silent thus far still have a stake in the thread's outcome. It describes why the thread is going nowhere, but does so without pejoratives or judgements—it just dispassionately states some facts. Most importantly, it offers a positive course of action, so that instead of people feeling like discussion is being closed off (a restriction against which they can only be tempted to rebel), they will feel as if they're being offered a way to take the conversation to a more constructive level. This is a standard people will naturally want to meet.
You won't always want a thread to make it to the next level of constructiveness—sometimes you'll want it to just go away. The purpose of your post, then, is to make it do one or the other. If you can tell from the way the thread has gone so far that no one is actually going to take the steps you suggested, then your post effectively shuts down the thread without seeming to do so. Of course, there isn't any foolproof way to shut down a thread, and even if there were, you wouldn't want to use it. But asking participants to either make visible progress or stop posting is perfectly defensible, if done diplomatically. Be wary of quashing threads prematurely, however. Some amount of speculative chatter can be productive, depending on the topic, and asking for it to be resolved too quickly will stifle the creative process, as well as make you look impatient.
Don't expect any thread to stop on a dime. There will probably still be a few posts after yours, either because mails got crossed in the pipe, or because people want to have the last word. This is nothing to worry about, and you don't need to post again. Just let the thread peter out, or not peter out, as the case may be. You can't have complete control; on the other hand, you can expect to have a statistically significant effect across many threads.
Fils de discussion productifs contre fils improductifs
Dans une liste de discussion animée il y a deux impératifs. Le premier, évidemment, consiste à distinguer ce qui mérite votre attention de ce que vous pouvez ignorer. L'autre consiste à agir de manière à ne pas créer du bruit : vous voulez non seulement que vos propres messages aient un degré de pertinence élevé, mais aussi qu'ils soient tels qu'ils incitent les autres à en poster d'aussi pertinents ou alors à s'abstenir.
Pour voir comment y parvenir examinons le contexte dans lequel ceci se produit. Quelles sont les marques distinctives d'un fil improductif ?
- Quand les arguments qui ont déjà été avancés sont répétés à nouveau, comme si l'expéditeur pensait que personne ne les a entendus la première fois
- Quand les niveaux d'hyperbole et d'engagement augmentent au fur et à mesure que l'enjeu diminue
- Quand la majorité des commentaires vient de ceux qui ne font rien ou presque, tandis que ceux qui en font le plus gardent le silence
- Quand plusieurs idées sont en discussion sans qu'il y ait de propositions claires (Bien sûr, toutes les idées intéressantes commencent par une vision imprécise ; ce qui compte, c'est la direction qu'elles prennent à partir de là. Est-ce que le fil a tendance à rendre la vision plus concrète ou est-ce qu'il s'emberlificote dans des sous-visions, des visions parallèles et des disputes ontologiques ?).
Le fait qu'un fil ne soit pas productif à son début ne le condamne pas nécessairement. Il peut s'agir d'un sujet important, auquel cas le fait que le fil piétine est d'autant plus troublant.
Redonner de l'intérêt à un fil de discussion utile sans faire de rentre-dedans est tout un art. Reprocher simplement aux gens leur perte de temps, ou leur demander de ne poster que des messages constructifs ne mène pas à grand chose. Vous pouvez, bien sûr, penser cela par devers vous, mais l'exprimer à haute voix serait insultant. En revanche, vous devez suggérer les conditions pour progresser ; donner une direction, une voie à suivre qui mène au résultat escompté, sans pour autant avoir l'air d'imposer une conduite. Voici par exemple ce qu'il ne faut pas faire :
Cette discussion ne mène nulle part. Pouvez-vous laisser tomber ce sujet jusqu'à ce que quelqu'un ait fait un correctif pour mettre en œuvre une de ces propositions ? Pas la peine de répéter toujours les mêmes choses. Le code parle plus que des mots les gars.
Voici qui est mieux :
Plusieurs propositions ont été esquissées dans ce fil, mais aucune n'était suffisamment précise pour qu'on puisse voter pour ou contre. De plus, nous n'avançons aucune idée nouvelle mais répétons ce qui a déjà été dit. Donc la meilleure chose à ce point serait que les messages à venir contiennent soit une spécification complète pour le comportement proposé, soit un correctif. Comme ça nous aurons au moins une action précise à entreprendre (i. e., nous mettre d'accord sur les spécifications ou appliquer le correctif et le tester).
Comparez les deux approches. La deuxième ne trace pas une ligne de démarcation entre vous et les autres, ne les accuse pas de mener la discussion dans une impasse. Elle parle de « nous », ce qui est important, que vous ayez ou non participé auparavant à la discussion, car cela rappelle à chacun que même pour ceux qui sont restés silencieux jusqu'ici l'issue de la discussion compte. Elle expose pourquoi le fil ne va nulle part mais le fait sans dénigrer ou porter de jugement quelconque, elle ne fait que constater des faits de manière neutre. Et, plus important, elle offre une ligne d'action positive, de sorte que les gens, au lieu d'avoir l'impression que la discussion a été arrêtée (frein contre lequel ils ne peuvent que s'insurger), auront l'impression qu'on leur offre un moyen d'amener la discussion dans une autre direction plus constructive. C'est là un critère que les gens accepteront spontanément.
On ne voudra pas toujours porter une discussion à un plus haut degré de productivité, parfois il est souhaitable qu'elle cesse. Le but de votre message est alors d'aboutir à l'un ou à l'autre. Si vous pouvez voir d'après ce qui s'est dit dans le fil que personne n'est prêt à s'engager dans la voie que vous proposez alors votre message clôt effectivement le fil sans en avoir l'air. Évidemment il n'y a aucun moyen infaillible pour clore un fil, et même s'il y en avait un, vous n'y auriez pas recours. Mais demander aux participants de faire des progrès visibles ou d'arrêter de poster est tout à fait légitime si vous le faites avec diplomatie. Gardez-vous d'étouffer des discussions prématurément toutefois. Une certaine dose de causette spéculative peut être productive suivant le sujet et demander à ce qu'elle aboutisse trop rapidement fera tourner court le processus créatif et on vous taxera d'impatience.
Ne vous attendez pas à faire cesser un fil instantanément. Il y aura certainement quelques messages de plus après le vôtre, soit parce que les messages se sont croisés, soit parce que les gens veulent avoir le dernier mot. Il n'y a aucune raison de s'inquiéter et il n'est pas nécessaire de poster un nouveau message. Laissez le fil s'éteindre, ou pas suivant le cas. Vous ne pouvez pas avoir le contrôle absolu ; d'un autre côté, statistiquement, vous pouvez espérer avoir un effet significatif à travers plusieurs fils.
[modifier] The Softer the Topic, the Longer the Debate
Although discussion can meander in any topic, the probability of meandering goes up as the technical difficulty of the topic goes down. After all, the greater the technical difficulty, the fewer participants can really follow what's going on. Those who can are likely to be the most experienced developers, who have already taken part in such discussions thousands of times before, and know what sort of behavior is likely to lead to a consensus everyone can live with.
Thus, consensus is hardest to achieve in technical questions that are simple to understand and easy to have an opinion about, and in "soft" topics such as organization, publicity, funding, etc. People can participate in those arguments forever, because there are no qualifications necessary for doing so, no clear ways to decide (even afterward) if a decision was right or wrong, and because simply outwaiting other discussants is sometimes a successful tactic.
The principle that the amount of discussion is inversely proportional to the complexity of the topic has been around for a long time, and is known informally as the Bikeshed Effect. Here is Poul-Henning Kamp's explanation of it, from a now-famous post made to BSD developers: "It's a long story, or rather it's an old story, but it is quite short actually. C. Northcote Parkinson wrote a book in the early 1960'ies, called "Parkinson's Law", which contains a lot of insight into the dynamics of management."
[...]
"In the specific example involving the bike shed, the other vital component is an atomic power-plant, I guess that illustrates the age of the book."
"Parkinson shows how you can go in to the board of directors and get approval for building a multi-million or even billion dollar atomic power plant, but if you want to build a bike shed you will be tangled up in endless discussions."
"Parkinson explains that this is because an atomic plant is so vast, so expensive and so complicated that people cannot grasp it, and rather than try, they fall back on the assumption that somebody else checked all the details before it got this far. Richard P. Feynmann gives a couple of interesting, and very much to the point, examples relating to Los Alamos in his books."
"A bike shed on the other hand. Anyone can build one of those over a weekend, and still have time to watch the game on TV. So no matter how well prepared, no matter how reasonable you are with your proposal, somebody will seize the chance to show that he is doing his job, that he is paying attention, that he is here."
"In Denmark we call it "setting your fingerprint". It is about personal pride and prestige, it is about being able to point somewhere and say "There! I did that." It is a strong trait in politicians, but present in most people given the chance. Just think about footsteps in wet cement."
(His complete post is very much worth reading, too. See Appendix C, Why Should I Care What Color the Bikeshed Is?).
Anyone who's ever taken regular part in group decision-making will recognize what Kamp is talking about. However, it is usually impossible to persuade everyone to avoid painting bikesheds. The best you can do is point out that the phenomenon exists, when you see it happening, and persuade the senior developers—the people whose posts carry the most weight—to drop their paintbrushes early, so at least they're not contributing to the noise. Bikeshed painting parties will never go away entirely, but you can make them shorter and less frequent by spreading an awareness of the phenomenon in the project's culture.
Plus le sujet est facile, plus long est le débat
Bien que la discussion puisse s'égarer avec n'importe quel sujet la possibilité d'égarement augmente quand la difficulté technique du sujet diminue. Après tout, le nombre de participants pouvant réellement suivre la discussion diminue proportionnellement à sa difficulté technique. Ceux qui le peuvent sont certainement les développeurs les plus expérimentés qui ont déjà pris part à ce genre de discussions des milliers de fois auparavant et savent quel genre de comportement peut mener à un consensus viable pour tous.
Le consensus est donc plus difficile à atteindre sur des questions techniques faciles à comprendre et sur lesquelles on peut se faire aisément une opinion ainsi que sur les sujets « légers » tels que l'organisation, la publicité, le financement, etc. Les gens peuvent participer à ces débats indéfiniment car il n'y a pas besoin de qualifications spécifiques pour le faire, ni de moyens clairs de savoir (même après coup) si la décision était bonne ou mauvaise ou encore simplement parce qu'avoir les autres participants à l'usure est une tactique qui réussit parfois.
Le principe selon lequel la somme de discussion est inversement proportionnelle à la complexité du sujet a été énoncé depuis un moment et est connu informellement sous le nom de l'effet Bikeshed (abri à vélos). Voici l'explication qu'en donne Poul-Henning Kamp dans un désomais célèbre message aux développeurs BSD :
C'est une longue histoire, ou plutôt une vieille histoire, mais très brève en réalité. C. Northcote Parkinson a écrit un livre dans les années 60 intitulé "La Loi de Parkinson" qui contient des vues intéressantes sur la dynamique du management.
[...]
Dans cet exemple précis concernant l'abri à vélos l'autre élément important est une centrale nucléaire, pour vous donner une idée de l'âge de l'ouvrage.
Parkinson montre comment vous pouvez obtenir du bureau exécutif l'accord pour construire une centrale nucléaire qui coûte plusieurs millions, voire un milliard de dollars, mais si vous voulez construire un abri à vélos, vous voilà embarqué dans des discussions sans fin.
Parkinson explique que c'est parce que la centrale nucléaire est tellement vaste, tellement chère et tellement complexe que les gens ne peuvent pas l'apréhender et, plutôt que de s'y essayer, ils préfèrent supposer que quelqu'un d'autre a pris la peine de vérifier tous les détails avant d'aller plus loin. Richard P. Feynmann donne dans son livre quelques exemples intéressants et très pertinents concernant Los Alamos.
De l'autre côté, nous avons l'abri à vélos. N'importe qui peut en construire un en un week-end, tout en ayant le temps d'aller regarder le match à la télé. Aussi bien préparée et raisonnable que soit votre proposition, quelqu'un saisira cette opportunité pour montrer qu'il fait son boulot, qu'il veille au grain, qu'il est dans la place.
Au Danemark on appelle ça laisser son empreinte. C'est une question d'amour propre et de prestige qui consiste à désigner quelque chose du doigt en disant : "Voilà ! c'est moi qui l'ai fait." C'est une caractéristique très présente chez les politiciens, mais également chez toute personne à qui on en donne l'occasion. Il n'y a qu'à voir les traces de pas dans le ciment frais.
(Son message complet vaut vraiment la peine d'être lu. Voir Appendice C, « Que m'importe la couleur de l'abri à vélos ? »)
Toute personne qui a été membre d'un groupe de décision reconnaîtra ce dont parle Kamp. Cependant, il est généralement impossible de convaincre tout le monde d'éviter de peindre l'abri à vélos. La meilleure chose que vous pouvez 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 diffusant la prise de conscience du phénomène dans la culture du projet.
[modifier] Avoid Holy Wars
A holy war is a dispute, often but not always over a relatively minor issue, which is not resolvable on the merits of the arguments, but where people feel passionate enough to continue arguing anyway in the hope that their side will prevail. Holy wars are not quite the same as bikeshed paintings. People painting bikesheds are usually quick to jump in with an opinion (because they can), but they won't necessarily feel strongly about it, and indeed will sometimes express other, incompatible opinions, to show that they understand all sides of the issue. In a holy war, on the other hand, understanding the other sides is a sign of weakness. In a holy war, everyone knows there is One Right Answer; they just don't agree on what it is.
Once a holy war has started, it generally cannot be resolved to everyone's satisfaction. It does no good to point out, in the midst of a holy war, that a holy war is going on. Everyone knows that already. Unfortunately, a common feature of holy wars is disagreement on the very question of whether the dispute is resolvable by continued discussion. Viewed from outside, it is clear that neither side is changing the other's mind. Viewed from inside, the other side is being obtuse and not thinking clearly, but they might come around if browbeaten enough. Now, I am not saying there's never a right side in a holy war. Sometimes there is—in the holy wars I've participated in, it's always been my side, of course. But it doesn't matter, because there's no algorithm for convincingly demonstrating that one side or the other is right.
A common, but unsatisfactory, way people try to resolve holy wars is to say "We've already spent far more time and energy discussing this than it's worth! Can we please just drop it?" There are two problems with this. First, that time and energy has already been spent and can never be recovered—the only question now is, how much more effort remains? If some people feel that just a little more discussion will bring the issue to a close, then it still makes sense (from their point of view) to continue.
The other problem with asking for the matter to be dropped is that this is often equivalent to allowing one side, the status quo, to declare victory by inaction. And in some cases, the status quo is known to be unacceptable anyway: everyone agrees that some decision must be made, some action taken. Dropping the subject would be worse for everyone than simply giving up the argument would be for anyone. But since that dilemma applies to all equally, it's still possible to end up arguing forever about what to do.
So how should you handle holy wars?
The first answer is, try to set things up so they don't happen. This is not as hopeless as it sounds:
You can anticipate certain standard holy wars: they tend to come up over programming languages, licenses (see the section called “The GPL and License Compatibility” in Chapter 9, Licenses, Copyrights, and Patents), reply-to munging (see the section called “The Great Reply-to Debate” in Chapter 3, Technical Infrastructure), and a few other topics. Each project usually has a holy war or two all its own, as well, which longtime developers will quickly become familiar with. The techniques for stopping holy wars, or at least limiting their damage, are pretty much the same everywhere. Even if you are positive your side is right, try to find some way to express sympathy and understanding for the points the other side is making. Often the problem in a holy war is that because each side has built its walls as high as possible, and made it clear that any other opinion is sheer foolishness, the act of surrendering or changing one's mind becomes psychologically unbearable: it would be an admission not just of being wrong, but of having been certain and still being wrong. The way you can make this admission palatable for the other side is to express some uncertainty yourself—precisely by showing that you understand the arguments they are making and find them at least sensible, if not finally persuasive. Make a gesture that provides space for a reciprocal gesture, and usually the situation will improve. You are no more or less likely to get the technical result you wanted, but at least you can avoid unnecessary collateral damage to the project's morale.
When a holy war can't be avoided, decide early how much you care, and then be willing to publicly give up. When you do so, you can say that you're backing out because the holy war isn't worth it, but don't express any bitterness and don't take the opportunity for a last parting shot at the opposing side's arguments. Giving up is effective only when done gracefully.
Programming language holy wars are a bit of a special case, because they are often highly technical, yet many people feel qualified to take part in them, and the stakes are very high, since the result may determine what language a good portion of the project's code is written in. The best solution is to choose the language early, with buy-in from influential initial developers, and then defend it on the grounds that it's what you are all comfortable writing in, not on the grounds that it's better than some other language that could have been used instead. Never let the conversation degenerate into an academic comparison of programming languages (this seems to happen especially often when someone brings up Perl, for some reason); that's a death topic that you must simply refuse to be drawn into.
For more historical background on holy wars, see http://catb.org/~esr/jargon/html/H/holy-wars.html, and the paper by Danny Cohen that popularized the term, http://www.ietf.org/rfc/ien/ien137.txt.
Évitez les trolls
Un troll est une dispute portant souvent, mais pas toujours, sur une question plutôt mineure qui ne peut être résolue au simple regard des arguments avancés car elle éveille des passions qui poussent les gens à continuer à discuter jusqu'à faire prévaloir leur point de vue. Les trolls ne sont pas tout à fait semblables aux réunions-pour-la-peinture-de-l'abri-à-vélos. Les gens qui peignent les abris à vélos sont prompts à donner leur avis (car ils le peuvent), mais ne vont pas forcément le défendre avec véhémence et peuvent même à l'occasion émettre d'autres opinions incompatibles pour montrer qu'ils prennent en compte tous les aspects de la question. Dans un sujet à troll, en revanche, prendre en compte les autres points de vue est un signe de faiblesse. Dans un sujet à troll, tout le monde sait qu'il y a Une Réponse Juste, les participants ne sont simplement pas d'accord sur laquelle.
Une fois que le troll est lâché il ne pourra pas être remis en cage en satisfaisant tous les points de vue. Cela ne sert à rien de déclarer en plein milieu d'un troll qu'il s'agit d'un troll. Tout le monde le sait déjà. Malheureusement un trait commun aux trolls est le désaccord sur le fait de savoir si la dispute peut être résolue par la poursuite de la discussion. 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.
Une manière courante, mais non satisfaisante, qu'emploient les gens pour mettre un terme aux trolls consiste à dire : « Nous avons déjà perdu trop de temps et d'énergie à discuter ! Vous voulez pas juste laisser tomber ? » Il y a deux problèmes là-dedans. D'abord, le temps et l'énergie ont déjà été dépensés de manière irréversible, 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 continuer.
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 est de toute façon inacceptable : tout le monde est d'accord, il faut prendre des décisions et agir d'une manière ou d'une autre. Il vaut mieux poursuivre l'argumentation plutôt que d'abandonner le sujet. Mais comme le dilemme s'applique à tous de la même manière il est aussi possible que la discussion continue éternellement.
Alors, comment gérer les trolls ?
La premier réponse est celle-ci : faites en sorte qu'ils ne soient pas libérés. Ce n'est pas aussi irréalisable que n'y parait.
Vous pouvez anticiper certains trolls classiques : ils surgissent quand il est question de langages de programmation, de licences (voir la section intitulée « La GPL et la compatibilité de licence » du Chapitre 9, Licences, droits d'auteurs et brevets), le déguisement des adresses mail (voir la section « Le grand débat du "Répondre à » du Chapitre 3, Infrastructure technique) et 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 pour montrer votre compréhension et votre sympathie quand l'autre camp marque des points. Souvent le problème dans un sujet à troll c'est que chacun des camps 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. Le moyen de rendre cet aveu savoureux pour le camp adverse consiste à manifester quelques incertitudes, en montrant précisément que vous comprenez les arguments qu'ils avancent et les trouvez sensés, même s'ils ne vous convainquent pas entièrement. Faites un geste qui appelle un geste en retour et la situation s'améliorera. Vous n'avez ni plus de chances ni moins de chances d'obtenir le résultat technique souhaité, mais au moins vous pouvez éviter 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 à payer 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 cas un peu spécial 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 l'issue déterminera le langage dans lequel sera écrit en grande partie le code du projet. La meilleure solution consiste à choisir le langage tôt, avec plus de poids donné aux avis des développeurs influents de départ, puis de le défendre avec le simple argument 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é à sa 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.[modifier] The "Noisy Minority" Effect
In any mailing list discussion, it's easy for a small minority to give the impression that there is a great deal of dissent, by flooding the list with numerous lengthy e-mails. It's a bit like a filibuster, except that the illusion of widespread dissent is even more powerful, because it's divided across an arbitrary number of discrete posts and most people won't bother to keep track of who said what, when. They'll just have an instinctive impression that the topic is very controversial, and wait for the fuss to die down.
The best way to counteract this effect is to point it out very clearly and provide supporting evidence showing how small the actual number of dissenters is, compared to those in agreement. In order to increase the disparity, you may want to privately poll people who have been mostly silent, but who you suspect would agree with the majority. Don't say anything that suggests the dissenters were deliberately trying to inflate the impression they were making. Chances are they weren't, and even if they were, there would be no strategic advantage to pointing it out. All you need do is show the actual numbers in a side-by-side comparison, and people will realize that their intuition of the situation does not match reality.
L'effet « minorité bruyante »
Dans 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 majorité de bloquage, 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. Il y a des chances pour qu'il ne l'aient pas fait et s'ils l'ont fait cela n'offre aucun avantage stratégique de le faire remarquer. Tout ce que vous avez à faire est de mettre en avant les chiffres réels dans une comparaison pour que les gens réalisent que leur perception de la situation ne correspond pas à la réalité.
