POSS Chap 6 Part 3
Un article de Framalang Wiki.
[modifier] Difficult People
Difficult people are no easier to deal with in electronic forums than they are in person. By "difficult" I don't mean "rude". Rude people are annoying, but they're not necessarily difficult. This book has already discussed how to handle them: comment on the rudeness the first time, and from then on, either ignore them or treat them the same as anyone else. If they continue being rude, they will usually make themselves so unpopular as to have no influence on others in the project, so they are a self-containing problem.
The really difficult cases are people who are not overtly rude, but who manipulate or abuse the project's processes in a way that ends up costing other people time and energy, yet do not bring any benefit to the project. Such people often look for wedgepoints in the project's procedures, to give themselves more influence than they might otherwise have. This is much more insidious than mere rudeness, because neither the behavior nor the damage it causes is apparent to casual observers. A classic example is the filibuster, in which someone (always sounding as reasonable as possible, of course) keeps claiming that the matter under discussion is not ready for resolution, and offers more and more possible solutions, or new viewpoints on old solutions, when what is really going on is that he senses that a consensus or a ballot is about to form, and doesn't like where it is probably headed. Another example is when there's a debate that won't converge on consensus, but the group tries to at least clarify the points of disagreement and produce a summary for everyone to refer to from then on. The obstructionist, who knows the summary may lead to a result he doesn't like, will often try to delay even the summary, by relentlessly complicating the question of what should be in it, either by objecting to reasonable suggestions or by introducing unexpected new items.
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.
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.
[modifier] Handling Difficult People
To counteract such behavior, it helps to understand the mentality of those who engage in it. People generally do not do it consciously. No one wakes up in the morning and says to himself: "Today I'm going to cynically manipulate procedural forms in order to be an irritating obstructionist." Instead, such actions are often preceded by a semi-paranoid feeling of being shut out of group interactions and decisions. The person feels he is not being taken seriously, or (in the more severe cases) that there is almost a conspiracy against him—that the other project members have decided to form an exclusive club, of which he is not a member. This then justifies, in his mind, taking rules literally and engaging in a formal manipulation of the project's procedures, in order to make everyone else take him seriously. In extreme cases, the person can even believe that he is fighting a lonely battle to save the project from itself.
It is the nature of such an attack from within that not everyone will notice it at the same time, and some people may not see it at all unless presented with very strong evidence. This means that neutralizing it can be quite a bit of work. It's not enough to persuade yourself that it's happening; you have to marshal enough evidence to persuade others too, and then you have to distribute that evidence in a thoughtful way.
Given that it's so much work to fight, it's often better just to tolerate it for a while. Think of it like a parasitic but mild disease: if it's not too debilitating, the project can afford to remain infected, and medicine might have harmful side effects. However, if it gets too damaging to tolerate, then it's time for action. Start gathering notes on the patterns you see. Make sure to include references to public archives—this is one of the reasons the project keeps records, so you might as well use them. Once you've got a good case built, start having private conversations with other project participants. Don't tell them what you've observed; instead, first ask them what they've observed. This may be your last chance to get unfiltered feedback about how others see the troublemaker's behavior; once you start openly talking about it, opinion will become polarized and no one will be able to remember what he formerly thought about the matter.
If private discussions indicate that at least some others see the problem too, then it's time to do something. That's when you have to get really cautious, because it's very easy for this sort of person to try to make it appear as though you're picking on them unfairly. Whatever you do, never accuse them of maliciously abusing the project's procedures, of being paranoid, or, in general, of any of the other things that you suspect are probably true. Your strategy should be to look both more reasonable and more concerned with the overall welfare of the project, with the goal of either reforming the person's behavior, or getting them to go away permanently. Depending on the other developers, and your relationship with them, it may be advantageous to gather allies privately first. Or it may not; that might just create ill will behind the scenes, if people think you're engaging in an improper whispering campaign.
Remember that although the other person may be the one behaving destructively, you will be the one who appears destructive if you make a public charge that you can't back up. Be sure to have plenty of examples to demonstrate what you're saying, and say it as gently as possible while still being direct. You may not persuade the person in question, but that's okay as long as you persuade everyone else.
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.
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.
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.
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.
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.
[modifier] Case study
I remember only one situation, in more than 10 years of working in free software, where things got so bad that we actually had to ask someone to stop posting altogether. As is so often the case, he was not rude, and sincerely wanted only to be helpful. He just didn't know when to post and when not to post. Our lists were open to the public, and he was posting so often, and asking questions on so many different topics, that it was getting to be a noise problem for the community. We'd already tried asking him nicely to do a little more research for answers before posting, but that had no effect.
The strategy that finally worked is a perfect example of how to build a strong case on neutral, quantitative data. One of our developers did some digging in the archives, and then sent the following message privately to a few developers. The offender (the third name on the list below, shown here as "J. Random") had very little history with the project, and had contributed no code or documentation. Yet he was the third most active poster on the mailing lists:
From: "Brian W. Fitzpatrick" <fitz@collab.net>
To: [... recipient list omitted for anonymity ...]
Subject: The Subversion Energy Sink
Date : Wed, 12 Nov 2003 23:37:47 -0600
In the last 25 days, the top 6 posters to the svn [dev|users] list have been:
- 294 kfogel@collab.net
- 236 "C. Michael Pilato" <cmpilato@collab.net>
- 220 "J. Random" <jrandom@problematic-poster.com>
- 176 Branko Čibej <brane@xbc.nu>
- 130 Philip Martin <philip@codematters.co.uk>
- 126 Ben Collins-Sussman <sussman@collab.net>
I would say that five of these people are contributing to Subversion
hitting 1.0 in the near future.
I would also say that one of these people is consistently drawing time
and energy from the other 5, not to mention the list as a whole, thus
(albeit unintentionally) slowing the development of Subversion. I did
not do a threaded analysis, but vgrepping my Subversion mail spool tells
me that every mail from this person is responded to at least once by at
least 2 of the other 5 people on the above list.
I think some sort of radical intervention is necessary here, even if we
do scare the aforementioned person away. Niceties and kindness have
already proven to have no effect.
dev@subversion is a mailing list to facilitate development of a version
control system, not a group therapy session.
-Fitz, attempting to wade through three days of svn mail that he let
pile up.*
Though it might not seem so at first, J. Random's behavior was a classic case of abusing project procedures. He wasn't doing something obvious like trying to filibuster a vote, but he was taking advantage of the mailing list's policy of relying on self-moderation by its members. We left it to each individual's judgement when to post and on what topics. Thus, we had no procedural recourse for dealing with someone who either did not have, or would not exercise, such judgement. There was no rule one could point to and say the fellow was violating it, yet everyone knew that his frequent posting was getting to be a serious problem.
Etude 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.
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 :
De : "Brian W. Fitzpatrick" <fitz@collab.net>
A : [... liste des destinataires omise pour conserver l'anonymat ...]
Sujet: The Subversion Energy Sink
Date: Wed, 12 Nov 2003 23:37:47 -0600
Dans les 25 derniers jours, les 6 personnes ayant posté le plus dans
la liste svn [dev|users] sont :
- 294 kfogel@collab.net
- 236 "C. Michael Pilato" <cmpilato@collab.net>
- 220 "A. Nonyme" <anonyme@problematic-poster.com>
- 176 Branko Čibej <brane@xbc.nu>
- 130 Philip Martin <philip@codematters.co.uk>
- 126 Ben Collins-Sussman <sussman@collab.net>
Je dirais que 5 de ces personnes contribuent à atteindre Subversion 1.0
dans un avenir proche.
J'ajouterai que l'une de ces personnes prend du temps et de l'énergie
aux 5 autres, sans parler de la liste dans son ensemble, ralentissant ainsi
(fût-ce involontairement) le développement de Subversion. Je n'ai pas fait
une analyse fil par fil, mais un vgrepp sur mon spool de mail Subversion
me dit que chaque mail de cette personne reçoit une réponse au moins
une fois par au minimum 2 des 5 autres personnes de la liste ci-dessus.
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
avérées sans effet.
dev@subversion est une liste destinée à faciliter le développement d'un
logiciel de gestion de version, ce n'est pas une séance de thérapie de groupe.
-Fitz, cherchant à ne pas se noyer dans trois jours de mails svn
qu'il a laissés s'empiler.
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.
