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.