Un obst�culo com�n en la participaci�n de un proyecto online es pensar que t� tienes que responder a todo. No tienes que hacerlo. Lo primero de todo, normalmente se generar�n m�s hilos de correo de los que t� puedas manejar, al menos despu�s de que el proyecto ha pasado sus primeros meses. Segundo, incluso en los hilos de correo en los que has decidido tomar parte, mucho de lo que comenta la gente no requerir� una respuesta. Los foros de desarrollo en particular tiendes a ser dominados por tres tipos de mensajes:
Mensajes proponiendo algo que -no es trivial-
Mensajes mostrando apoyo u oposici�n a algo o a lo que alguien ha dicho.
Mensajes de recapitulaci�n
Ninguno de esosde manera inherente requerir� una respuesta, particularmente si puedes ser justamente seguro, bas�ndote en revisar el hilo desde el principio, que alguien m�s probablemente dir� lo que tu ibas a decir de cualquier manera. (Si te preocupa que te tomen en un bucle de esperar-esperar porque todos los dem�s est�n usando esta t�ctica tambien, no lo hagas; casi siempre habr� alguien por ah� que se tender� a crisparse.) Una respuesta deber�a ser motivada por un prop�sito definitivo. Preg�ntate a ti mismo primero: �Sabes que es lo que quieres conseguir? Y segundo: �no se conseguir� a menos que digas algo?
Dos buenas razones para a�adir tu voz a un hilo de corre son a) cuando veas un movimiento de proposici�n y sospeches que t� eres el �nico que as� lo percibe, y b) cuando veas que no hay entendimiento entre otros, y sepas que puedes solucionarlo con un correo clarific�ndolo todo. Tambien generalmente est� bien escribir �nicamente para dar las gracias a alguien por algo, o para decir "Yo tambien!", porque un lector puede decir en seguida que tal correo no requiere ninguna respuesta ni acci�n adicional, y por lo tanto el esfuerzo mental demnadado por el post termina limpliamente cuando el lector llega a la �ltima l�nea de el correo. Pero incluso entonces, piensalo dos veces antes de decir algo; es siempre mejor dejar a la gente deseando que escribas m�s a menudo que deseando que escribas menos. (Consulta la segunda parte de Ap�ndice�C, Why Should I Care What Color the Bikeshed Is? para ver m�s ideas sobre como portarse en una lista de correo muy concurrida.)
En una lista de correo muy concurrida, tienes dos imperativos. Uno, obviamente es comprender en que es lo que necesitas poner tu atenci�n y que es lo que puedes ignorar. El otro es evitar de alguna manera el causar ruido: no s�lo quieres que tus propios posts tengan un ratio de gran ruido/se�al, sino que tambien quieres que sean el tipo de mensajes que estimulan a otra gente a escribir mails con un ratio similar de se�al/ruido, o no escribir nada.
Para ver como hacer eso, vamos a considerar el contexto en el cual se hace. �Cuales son algunos de los sellos de un hilo improductivo?
Argumentos que ya se han hecho antes se empiezan a repetir, porque el que los hace piensa que nadie le ha escuchado la primera vez.
Se incrementan los n�veles de exageraci�n y participaci�n mientras el inter�s se hace cada vez m�s peque�o.
Una mayor�a de comentarios que provienen de gente que hablan poco o nada, mientras que la gente que tiene a hacer las cosas permanece en silencio.
Muchas ideas se discuten sin un prop�sito claro de que hacer con ellas. Por supuesto, cualquier idea interesante empieza con una visi�n imprecisa; la cuesti�n importante es que direcci�n tomar� a partir de ah�. Parece que el hilo empieza a convertir la visi�n en algo m�s concreto, o est� derivando en sub-visiones y disputas ontol�gicas?)
S�lo porque un hilo de correo no sea productivo al principio no significa que sea una perdida de tiempo. Puede tratar sobre un tema importante, en cuyo caso el hecho de que no se est� produciendo ning�n progreseo es todo lo m�s molesto.
Guiar un hilo de correo hacia la utilidad sin ser agresivo es todo un arte. No funcionar� simplemente amonestando a la gente para que pare de gastar su tiempo, o pregunt�ndoles que no escriban a menos que tengan algo constructivo que decir. Por supuesto puedes pensar en esas cosas en privado, pero si lo dices en la lista de correo sonar� ofensivo. En lugar de eso, tienes que sugerir condiciones para promover progresos; gu�a a la gente, un camino a seguir que lleve a los resultados que quieres, y todo ello sin que tu conducta parezca dictatoria. La distinci�n es en gran parte el tono. Por ejemplo, esto esta mal:
Esta discusi�n no va a ning�n lado. Por favor podemos dejar este tema hasta que alguien tenga un parche que implemente una de esas proposiciones? No hay raz�n para mantenernos en ello todo el rato diciendo las mismas cosas. El c�digo hace m�s ruido que las palabras, chicos.
Donde esto esta bien:
Varias propuestas han estado flotando en este hilo, pero ninguno ha tenido todos los detalles completos, al menos no demasiados como para hacer una votaci�n arriba-o-abajo. Y todav�a no estamos diciendo nada nuevo; estamos simplemente reiterando lo que ya se ha dicho anteriormente. As� que lo mejor a partir de este punto ser� probablemente para posteriores correos contener tanto una especificaci�n completa para la caracter�stica propuesta, o un parche. Entonces al menos tendr�amos una acci�n definitiva que tomar (ejem, tener un consenso en la especificaci�n, o aplicar el parche).
Compara la segunda propuesta con la primera. La segunda manera no traza una l�nea entre t� y los dem�s, ni les acusa de mantener la discusi�n en una espiral. Habla sobre "nosotros", que es lo importante hayas participado o no en el hilo de correo anteriormente, porque recuerada a todo el mundo que incluso aquellos que han estado en silencio hasta entonces en el hilo de correo todav�a pueden participar en el resultado del hilo de correo. Describe porque el hilo no va a ninguna parte, pero lo hace sin peyorativas ni juicios; simplemente muestra el estado de algunos hechos sin sentimiento. Lo m�s importante, ofrece un curso de acci�n positivo, de manera que en vez de que la gente sienta que la discusi�n esta siendo cerrada (una restricci�n contra la cual ellos pueden s�lo estar tentados a rebelar), se sentir�n como si se les estuviera ofreciendo una manera de tomar parte en la conversaci�n a un nivel m�s constructivo. Este es un est�ndar con el cual la gente querr� quedarse.
Siempre no querr�s convertir un hilo de correo en el siguiente nivel de construcci�n; otras veces querr�s dejarlo pasar. El prop�sito de tu correo, entonces, es hacer una cosa o la otra. Si puedes decir el camino que deber� tomar el hilo de correo de manera que nadie lo est� haciendo as� para tomar los pasos que sugeriste, entonces tu correo ha cerrado el hilo sin aparentar hacerlo. Por supuesto, no hay una manera infalibe de cerrar un hilo, e incluso si la hubiera, no querr�as usarla. Pero preguntando a los participantes a crear progresos visibles o parar de escrbiri correos es perfectamente defendible, si se hace diplom�ticamente. Sin embargo, se cauteloso de anular los hilos de correo prematuramente. Alguna cantidad de charla especulativa puede llegar a ser productiva, dependiendo del tema, y preguntando para que se resuelva demasiado r�pida apagar� el proceso creativo, as� como tambien te hara parecer impaciente.
Don't expect any thread to stop on a dime. Probablemente habr� todav�a unos pocos correos despues del tuyo, ya sea porque los mails se cruzan en la red, o porque la gente quiere tener la �ltima palabra. Esto no es nada por lo que preocuparse, y no necesitas escribir otro correo otra vez. Simplemente deja que el hilo se vaya esfumando o que no se esfume como puede ser el caso. No puedes tener control completo; por otra parte, puedes esperar tener estad�sticamente un efecto significativo a trav�s de varios hilos de correo.
Aunque las discusiones pueden extenderse a cualquier topico, la probabilidad de que se vayan extendiendo va conforme la dificultad tecnica del tema disminuye. Despues de todo cuanta mas sea la dificultad tecnica, menor sera el numero de participantes que realmente podran seguirla. Aquellos quienes pueden ser los desarrolladores mas experimentados, quienes ya han tomado parte en esas discusiones antes cientos de veces, y conocen el tipo de comportamiento es el que va a llevar a un consenso con el cual todo el mundo este de acuerdo.
De esta manera, en cuestiones tecnicas que son simples de comprender y faciles de tener una opinion sobre ellas, es dificil llegar a un consenso, y en temas "blandos" como organizacion, publicidad, ingresos, etc. La gente puede participar en aquellos argumentos siempre, porque no es necesario ninguna cualificacion para hacerlo, no hay un camino claro para decidir (incluso despues de todo) si una decision fue buena o mala, y porque simplemente esperar a que otros discutan es a veces una tactica correcta.
El principio de que la cantidad de discusion es inversamente proporcional a la complejidad del tema tratado, ha estado ahi durante algun tiempo, y es conocido informalmente como el Efecto Bikeshed . Aqui esta la explicacion de Poul-Henning Kamp's, de un correo ahora famoso, hecho en la lista de desarrolladores de BSD:
Es una larga historia o mas bien es una vieja historia, pero es bastante escasa actualmente. C. Northcote Parkinson escribio un libro en los comienzoa de 1960 titulado "La ley de Parkinson", la cual contenia mucho entendimiento sobre la dinamica de la gestion.
[...]
En el ejemplo especifico cubriendo el refugio de bicicletas, el otro componente vital es una planta de energia atomica, supongo que ilustra la epoca de el libro. .
Parkinson nos muestra que puedes ir a un consejo de direccion y conseguir la aprobacion de un edificio multi millonario o incluso de billones de dolares de una planta de energia atomica, pero si quieres construir un refugio de bicicletas te veras implicado en discusiones sin fin.
Parkinson explica que esto es porque una planta de energia atomica es tan enorme, tan cara y tan complicada que la gente no tendra conocimiento de ello, y en lugar de intentarlo, recurriran al supuesto de que alguien revisara todos los detalles antes de ir mas alla. Richard P. Feynmann dio un par de interesantes, y muy cercanos a esto ejemplos en relacion a los Alamos en sus libros.
Por otra parte, un refugio para bicletas. Cualquiera puede construir uno de esos en un fin de semana, y todavia tendra tiempo para ver la TV. Asi que no importa lo bien preparado que estes, tampoco importa lo razonable que seas en tu proposicion, alguien se hara con la oportunidad para demostrar que esta haciendo su trabajo, que esta atento, que esta ahi.
En Dinamarca lo llamamos "deja tu huella". Trata sobre el orgullo personal y el prestigio, va sobre ser capaz de se�alar en algun sitio y decir "Hay! esto lo hice Yo." Es fuerte, simplemente piensa en las pisadas del semento mojado.
(Su post completo es una lectura de mucho valor. Miralo.Ap�ndice�C, Why Should I Care What Color the Bikeshed Is?; see also http://bikeshed.com.)
Cualquiera que regularmente tome parte en decisiones hechas en grupo reconocera sobre que es lo que esta hablando Kamp. Sin embargo, normalmente es imposible persuadir a todo el mundo a evitar pintar un cobijo de bicis. Lo mejor que puedes hacer es se�alar que el fenomeno existe, y cuando veas que esta ocurriendo, persuadir al desarrollador senior; las personas cuyos mails llevan todo el peso; a soltar sus brochas pronto, asi al menos no contribuiran al ruido. Las fiestas para pintar bicis nunca se esfumaran enteramente, pero puedes hacerlas mas cortas y menos frecuentes extendiendo una concienciacion del fenomeno en la cultura del proyecto.
Una Guerra Santa es una disputa, a menudo pero no siempre sobre un tema relativamente menor el cual no se puede resolver con los meritos de los argumentos, pero donde la gente se siente demasiado apasionada para continuar discutiendo de cualquier manera con la esperanza de que su lado prevalecera. Las Guerras Santas no son lo mismo que la pintura de un garaje de bicicletas. La gente de la pintura de bicicletas normalmente salen rapido con una opinion (porque pueden), pero ellos, necesariamente no se sentiran demasiado apasionados sobre ello, y por lo tanto, otras veces, expresaran opiniones incompatibles para mostrar que ellos comprenden todas las caras del tema tratado. Por otra parte, en una Guerra Santa, comprender a las otras partes es un signo de debilidad. En una Guerra Santa, todo el mundo sabe que hay UNA Respuesta Correcta; Per ellos no estan de acuerdo con esta.
Una vez que una Guerra Santa ha empezado, generalmente no se puede resolver con la satisfaccion de todo el mundo. No es bueno mostrar, en el medio de una Guerra Santa, que esta esta teniendo lugar. Todo el mundo ya lo sabe. Desafortunadamente una caracteristica comun de las Guerra Santa es el desacuerdo en cada cuestion si la disputa se puede resolver continuando la discusion. Visto desde fuera, esta claro que ninguna parte va a cambiar la opinion de los otros. Visto desde dentro, la otra parte esta siendo obtusa y no esta pensando claramente, pero pueden cambiar de opinion si las cosas se vuelven feas. Ahora,no estoy diciendo que no haya una parte con razon en una guerra santa. A veces la hay en las Guerras Santas que yo he participado, siempre ha sido mi bando, por supuesto. Pero no importa porque no hay algoritmo para demostrar convencidamente que una parte o la otra estan en lo cierto.
Un comun, pero insatisfactorio modo de intentar solucinar una Guerra Santa es decir "Ya hemos gastado bastante tiempo y energia de lo que vale discutiendo esto! Por favor, �podemos dejarlo? Hay dos problemas en esto. Primero, que el tiempo y la energia ya se han gastado y ya no se pueden recuperar; la unica cuestion ahora es, cuanto esfuerzo mas permanecera? Si todavia alguno siente que un poco mas de discusion resolvera la cuestion pronto, entonces todavia tiene sentido (desde su punto de vista) continuar.
El otro problema en preguntar para que la cuestion sea zanjada es que esto es a menudo equivalente a permitir a una parte el status quo, a declarar la victoria por inaccion. Y en algunos casos, el status quo es conocido por ser de cualquier forma inaceptable: todo el mundo esta de acuerdo en que se debe llegar a una decision, se debe tomar alguna accion. Dejar el tema seria peor para todo el mundo que simplemente apoyando el argumento que daria alguien. Pero dado que el dilema se aplica igualmente a todo el mundo, todavia es posible terminar discutiendo por siempre sobre que hacer.
�Como deberias manejar una Guerra Santa?
Puedes anticipar ciertas Guerras Santa estandar: tienden a tratar sobre lenguajes de programacion, licencias (mira “La GPL y compatibilidad entre licencias” in Cap�tulo�9, Licencias, Copyrights y Patentes), en respuesta a munging (mira “El gran debate del Reply-To” en Cap�tulo�3, Infraestructura T�cnica), y algunos otros topicos. Normalmente cada proyecto tiene una o dos Guerras Santas, tambien, las cuales los desarrolladores mas experimentados estaran ya familiarizados. Las tecnicas para frenar las Guerras Santas, o al menos limitar su da�o, son casi las mismas en cualquier lugar. Incluso si eres positivo y tu parte es correcta, intenta encontrar alguna manera de expresar simpatia y comprension hacia los puntos de vista que los otros hacen. A menudo el problema en una Guerra Santa es porque cada parte ha construido sus muros lo mas alto posible, y dejan claro que cualquier otra opinion es totalmente idiota, el acto de rendirse o cambiar el pensamiento de alguien se hace psicologicamente insostenible: ser�a un reconocimiento no solamente siendo err�neo, pero habiendo sido ciertamentey todavia siendo err�neo. La manera en que puedes hacer este reconocimiento aceptable por la otra parte es expresar alguna duda tu mismo; precisamente mostrando que comprendes sus argumentos y al menos eres sensible a ellos, si no persuasivo finalmente. Haz un gesto que proporcione espacio para un gesto rec�proco, y normalmente la situaci�n mejorar�. No es ni m�s ni menos probable que consigas el resultado t�cnico que quer�as, pero al menos puedes evitar el da�o colateral innecesario a la moral del proyecto.
Cuando una Guerra Santa no se puede evitar, decide pronto cuanto la apoyas, y entonces est�te dispuesto p�blicamente a ceder. Cuando hagas esto, puedes decir que no est�s respald�ndola porque la Guerra Santa no lo vale, pero no expreses ning�n rencor y no tomes la oportunidad para una despedida disparando contra los argumentos de la otra parte. Darse por vencido es efectivo s�lo cuando se hace con elegancia.
Las Guerras Santas de lenguajes de programaci�n son un caso especial, porque a menudo son mayormente t�cnicas, todav�a mucha gente se siente cualificada para tomar parte en ellas, y el interes es muy alto, ya que el resultado puede determinar en gran medida en que lenguaje se va a escribir el proyecto. La mejor soluci�n es elegir el lenguaje pronto, con la influencia de los desarrolladores iniciales, y entonces defenderlo en los terrenos en los que eres comfortable escribiendo, no en el terreno que ser�a mejor en el que otro lenguaje se pudiera utilizar. Nunca dejes que la conversaci�n en una comparaci�n acad�mica de lenguajes de programaci�n (esto parece ocurrir especialmente cuando alguien menciona Perl, por alguna raz�n); �ste es un t�pico muerto en el que simplemente debes evitar caer.
Para consultar m�s fondo hist�rico de las Guerras Santas, mira http://catb.org/~esr/jargon/html/H/holy-wars.html, y el art�culo de Danny Cohen que populariz� el t�rmino, http://www.ietf.org/rfc/ien/ien137.txt.
En cualquier discusion de una lista de correo, es f�cil para una peque�a minor�a dar la impresi�n de que hay un gran acuerdo de contrariead, esto es inundando la lista con numerosos y largos emails. Es igual a hacer una maniobra obstruccionista, excepto que la ilusi�n de la disensi�n general es incluso m�s poderosa, porque est� dividida entre un n�mero arbitrario de posts discretos y a la mayor�a de la gente no le importa seguir la pista de qui�n ha dicho que, cuando. S�lo tienen una impresi�n instintiva de que el tema es muy controvertido, y esperan a que el esc�ndalo disminuya.
La mejor manera de contrarrestar este efecto es indicarlo muy claramente y proporcionar pistas respaldadas mostrando c�mo de peque�o es el n�mero actual de disidentes comparado a los que est�n en acuerdo. Para incrementar la disparidad, puedes querer encuestar de manera privada a la gente que ha estado la mayor parte del tiempo en silencio, pero que sospechas que estar�n de acuerdo con la mayor�a. been mostly silent, but who you suspect would agree with the majority. No digas nada que sugiera que los disidentes estaban intentando deliberadamente inflar la impresi�n que estaban creando. Oportunidades que no tuvieron, e incluso si las tuvieron no hab�a una ventaja estrat�gica para se�alarla. Todo lo que necesitas es mostrar el n�mero actual en una comparaci�n cara-a-cara, y la gente se dara cuenta que su intuici�n de la situaci�n no coincid�a con la realidad.
Este consejo no s�lo se aplica a temas con una clara posici�n a-favor-en-contra. Se aplica a cualquier discusi�n donde hay un alboroto, pero no esta claro que la mayor�a de la gente considere ese tema bajo discusi�n que sea un problema real. Despues de todo, si estas de acuerdo en que el tema no es digno de acci�n, y puedes ver que ha fallado en atraer la atenci�n (incluso si ha generado muchos mails), puedes observar p�blicamente que no est� teniendo tracci�n. Si el efecto "ruido minoritario" ha funcionado, tu post parecer� un soplo de aire fresco. La mayor�a de la impresi�n de la gente de la discusi�n se dar� cuenta de que ese punto habr� sido algo turbio: Huh, seguro que sienten como que hay un gran acuerdo aqui, porque seguramente hay un mont�n de posts, pero no puedo ver que est� habiendo ning�n progreso claro." Explicando como la manera en que la discusi�n se hizo parezca m�s turbulenta de lo que realmente es, t� retrospectivamente le dar�s una nueva forma, a trav�s de la cual la gente pueda recapitular su comprensi�n del resultado.