No es tan fácil tratar con gente díficl en foros electrónicos como lo sería en persona. Con "díficil" no me refiero a "maleducados". La gente maleducada es molesta, pero no son necesariamente díficiles. En este libro ya se ha discutido como manejarlos:comenta la grsoería la primera vez, y desde entonces ignórales o tratalos como otro cualquiera. Si continuan siendo maleducados, ellos mismos se haran tan impopulares que no tendrán influencia en nadie del proyecto, por lo que serán un problema de ellos mismos.
Los casos realmente difíciles son la gente que no son manifiestamente groseros, pero que manipulan o abusan en los procesos del proyecto de una manera que termina costando el tiempo y la energía de otras personas, y todo ello sin traer ningún beneficio al proyecto. Tales personas a menudo buscan puntos de presión en los procedimientos del proyecto, para darse a sí mismos más influencia que de otra manera no tendrían. Esto es mucho más insidioso que la grosería meramente, porque ni el comportamiento ni el daño que causa es aparente a los observadores casuales. Un ejemplo clásico es aquellos que realizan maniobras obstruccionistas, en la que alguien (siempre sonando tan razonable como sea posible, por supuesto) viene demandando que la cuestión bajo discusión no esta lista para una solución, y ofrece más y más posibles soluciones, o nuevos puntos de vista de viejas soluciones, cuando lo que realmente está pasando es que el sentido de un consenso o votación está a punto de ocurrir, y no le gusta por donde va encaminado. Otro ejemplo es cuando hay un debate que no converge en consenso, pero el grupo al menos intenta clarificar los puntos en desacuerdo y produce un sumario para que todo el mundo se refiera a partir de el. El obstruccionista, que sabe que el sumario puede llevar a un punto que a el no le va a gustar, a menudo intentará retrasar el sumario, implacablemente mediante complicadas cuestiones que deberían estar ahí, u objetando sugerencias razonables, o mediante la introducción de nuevos asuntos.
Para contrarrestar tal comportamiento, ayuda el comprender la mentalidad de aquellos que caen en él. La gente generalmente no lo hara conscientemente. Nadie se levanta por la mañana y se dice a sí mismo: "Hoy voy a manipular cínicamente las formas y procedimientos para ser así un irritante obstruccionista." En cambio, tales acciones están a menudo precedidas por un sentimiento de semi-paranoia de estar fuera de las interacciones y decisiones del grupo. La persona piensa que no se le toma seriamente, o (en casos más severos), que existe una conspiración contra él;y que los otros miembros del proyecto han decidido formar un club exclusivo, del cual el no es miembro. Esto entonces justifica en su mente, a tomar las reglas literalmente y encargándose de una manipulación formal de los procedimientos del proyecto, para así hacer que todo el mundo le tome en serio. En casos extremos, la persona puede incluso pensar que está luchando una batalla solo para salvar el proyecto de sí mismo.
Es la naturaleza del propio ataque la que hara que nadie se percate de él al mismo tiempo, y mucha gente no lo notará, a menos que se presente con evidencias muy fuertes. Esto significa que neutralizarlo puede llevar algo de trabajo. No basta con persuadirse a sí mismo de que está ocurriendo; tendrás que organizar muy bien las evidencias para persuadir a los demás de lo que está ocurriendo, y entonces tendrás que distribuir estas evidencias de una manera atenta.
Dado que hay mucho por lo que luchar, a menudo la mejor opción es tolerarlo de vez en cuando. Piensa en esto como un parásito, esto es una dolencia suave: si no es muy debilitante, el proyecto podrá afrontar el permanecer infectado, y la medicina podría tener efectos perjudiciales. Sin embargo, si consigue más daño del que se pueda tolerar, entonces es tiempo de entrar en acción. Empieza reuniendo notas de los patrones que observas. Asegurate de incluir referencias a archivos públicos; esta es una de las razones por la que los proyectos mantiene históricos, para que puedas usarlos tambien. Una vez que tengas una buena recopilación, empieza a entablar conversaciones privadas con otros participantes del proyecto. No les digas lo que has observado; en vez de eso, pregúntales primero que es lo que observan ellos. Esta puede ser tu última oportunidad de conseguir feedback sin filtrar sobre como los demás observan el comportamiento de los que crean problemas; una vez que has empezado a hablar abiertamente, la opinión se polarizará y nadie será capaz de recordar que es lo que anteriormente opinaba sobre el tema en cuestión.
Si las discusiones privadas indican que tambien hay otros que perciben el problema, entonces es hora de hacer algo. Aquí es donde tienes que ser realmente cauteloso, porque sera muy fácil para este tipo de persona hacer parecer como que tú eres el que actua injustamente. Hagas lo que hagas, nunca acuses de abusar maliciosamente de los procedimientos del proyecto, o de ser paranoico, o, en general, de cualquier otra cosa que sospeches que probablemente sea cierta. Tu estrategia deberá mostrarse tanto razonable como consciente del bienestar global del proyecto. Con el objetivo de reformar la actitud de la persona, o de expulsarla del proyecto permanentemente. Dependiendo de los otros desarrolladores, y de tu relación con ellos, puede ser ventajoso conseguir aliados de manera privada primero. O puede que no; ya que puede dificultar el ambiente interno, si la gente piensa que te estas dedicando a una campaña de falsos e impropios rumores.
Recuerda que aunque la otra persona sea la que se este portando destructivamente tu seras la que parezca destructiva si le culpas públicamente y no lo puedes probar. Asegurate de tener varios ejemplos y demostrar lo que estas diciendo, y dilo tan suave como puedes pero siendo directo. Puede que no persuadas a la persona en cuestión, pero estará bien mientras puedas persuadir a los demás.
Recuerdo sólo una situación, en más de 10 años trabajando en Software Libre, donde las cosas fueron tan mal, que nosotros tuvimos que preguntar a alguien para que parase de postear completamente. Como era tan a menudo el caso, el no era maleducado y quería sinceramente ser de utilidad. Simplemente no sabía cuando escribir a la lista y cuando no hacerlo. Nuestras listas estaban abiertas al público, y él escribía muy a menudo, preguntando cuestiones de diferentes temas, que empezó a ser un problema de ruido para la comunidad. Nosotros habíamos intentado preguntarle de buenas maneras para que hiciera un poco más de investigación para las respuestas antes de escribir a la lista, pero no hizo efecto.
La estrategia que al final funcionó es un ejemplo perfecto de como construir una situación neutral, y con datos cuantitativos. Uno de los cuatro desarrolladores hizo una exploración en los archivos, y envío entonces el siguiente mensaje de manera privada a unos pocos desarrolladores. El ofendido (el tercer nombre en la lista de abajo, se muestra aquí como "J. Random") tenía muy poca historia con el proyecto, y no había contribuido ni con código ni documentación. Y aún así era el tercero más activo en escribir mensajes en la lista de correo:
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
En los últimos 25 días, el top de los 6 que más han escrito en la lista de svn [dev|users] han sido:
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>
Diría que cinco de esas personas están contribuyendo con éxito al desarrollo
de la versión 1.0 de subversión en un futuro cercano.
Tambien diría que una de esas personas está constantemente atrayendo tiempo y energía de las
otras cinco, sin mencionar a la lista como un todo, así, (aunque no intencionadamente) está frenando
el desarrollo de Subversion. No hice un análisis de los hilos de correo, pero haciendo una búsqueda
en mi archivo de correo me muestra que a cada correo de esta persona le responde al menos uno o
dos de los otros cinco de la lista anterior.
Creo que algún tipo de intervención radical es necesaria en esto, incluso si nos asusta que el
susodicho se marche. Se ha comprobado que la finura y amabilidad aquí no tienen efecto.
dev@subversion es una lista de correo para facilitar el desarrollo de un sistema de control de versiones,
no una sesión de terapia de grupo.
-Fitz, intentando abrir camino con dificultad por el correo de svn de tres días que había dejado apilado.
Aunque no pueda parecerlo al principio, el comportamiento de J. Random's era un clásico de abuso de los procedimientos del proyecto. El no estaba haciendo nada obvio más que intentando obstruccionar en los votos, y estaba aprovechándose de la ventaja de la política de la lista de correo de depender en la propia moderación de sus miembros. Dejamos al juicio de cada individuo en lo que escribe y sobre que materias. De esta manera, no teníamos recursos de procedimiento para tratar con aquellos que no tenían buen juicio, o que no lo practicaban. No había ninguna regla que pudieras apuntar e indicar que se estaba violando, aunque todo el mundo ya sabía que sus frecuentes correos se estaban convirtiendo en un problema serio.
La estrategia de Fitz era retrospectivamente maestra. El recopilo una cantidad de evidencia irrefutable, y entonces la distribuyo discretamente, enviándola primero a unas pocas personas cuyo soporte sería clave en una acción drástica. Ellos estuvieron de acuerdo en que era necesaria algún tipo de acción, y al final llamamos a J. Random por teléfono, le describimos el problema directamente, y le preguntamos para que simplemente parase de escribir correos a la lista. El nunca comprendio realmente las razones de ello; si hubiera sido capaza de comprenderlo, probablemente hubiera ejercido un juicio apropiado en primer lugar. Pero el acordó en parar de escribir correos, y la lista de correo se convirtio en útil de nuevo. Una de las razones por las que esta estrategia funcionó fue quizás, la amenaza implícita con la que hubieramos empezado a restringir sus posts vía el software de moderación que normalmente se utiliza para prevenir el spam (consulta “Prevenir el Spam” en Capítulo 3, Infraestructura Técnica). Pero la razón por la que fuimos capaces de aquella opción en reserva fue que Fitz había recopilado el apoyo necesario de la gente clave en primer lugar.