Capítulo 6. Comunicaciones

No caigas en la trampa de escribir todo como si fuera un mensaje de teléfono móvil. Escribe frases completas, poniendo en mayúsculas la primera palabra de cada frase, y usando separaciones de párrafo donde sea necesario. Esto es lo más importante en correos electrónicos y otras composiciones. En el IRC u otros foros efímeros similares, generalmente es correcto dejar de poner mayúsculas, utilizar formas comprimidas o expresiones comunes, etc. Simplemente no lleves esos hábitos a foros más formales o persistentes. Correos electrónicos, documentación, informes de error y otras piezas de escritura que suelen tener una larga vida deberían escribirse usando una gramática y una spelling estándar, y tener una estructura narrativa coherente. Esto no se debe a que haya algo inherentemente bueno siguiendo reglas arbitrarias, sino a que estas reglas no son arbitrarias: evolucionan en las formas presentes ya que hacen que el texto sea más leíble y, por esa razón, deberías seguirlas. La legibilidad no sólo es deseable para que la mayoría de gente entienda lo que escribes, sino porque hace que que parezcas la clase de persona que se toma su tiempo en comunicarse de una forma clara: es decir, alguien a quien vale la pena prestar atención.

En particular, para correos electrónicos, desarrolladores experimientados de open source han decidido ciertas convenciones:

Envía correos solo de texto plano, no en HTML, texto enriquecido u otros formatos ya que podrían no ser leidos por lectores que leen sólo texto plano. Formatea las líneas para que estén sobre las 72 columnas de largo. No excedas las 80 columnas, que ha sido de facto el ancho estándar del terminal (es decir, hay gente que utiliza terminales más anchos, pero nadie utiliza terminales no más estrechos). Al hacer las líneas un poco menores de 80 columnas da cabida a unos cuantos niveles de caracteres de citado para ser añadidos en otras respuestas sin forzar un estrechamiento de tu texto.

Utiliza saltos de línea reales. Algunos clientes de correo muestran un falso formateo de línea, mientras estás escribiendo un correo, viéndose en la pantalla saltos de línea donde en realidad no los hay. Cuando se envía el correo, no tendrá los saltos de línea que se pensaba y se presentará con un formato horroroso en la pantalla de la gente. Si tu cliente de correo muestra falsos saltos de línea, busca posibilidad de quitar la opción para ver los saltos de línea reales a medida que escribes el correo.

Cuando incluyas salida de pantalla, trozos de código u otro texto preformateado, desplázalo claramente, de forma que a simple vista se pueda fácilmente ver los límites entre tu texto y el material que estés incluyendo. (Nunca esperé escribir este consejo cuando comencé el libro, pero en un número de listas de correo de código abierto posterior, he visto gente mezclando textos de diferentes fuentes sin dejar claro qué es qué. El efecto es muy frustante. Hacen los correos bastante difíciles de entender y, francamente, hace que esas personas parezcan un poco desorganizadas).

Cuando cites el correo de alguien, inserta tus repuestas donde sea más apropiado, en diferentes lugares si es necesario, y elimina las partes de su correo que no utilices. Si estás escribiendo un comentario rápido con referencia a todo el correo, es correcto hacerlo top-post (Es decir, poner tu respuesta encima del texto citado; de lo contrario, deberías citar primero la parte relevante del texto original, seguido de tu respuesta.

Construye el asunto de los nuevos correos con cuidado. Es la línea más importante de un correo, ya que permite a cualquier otra persona del proyecto decidir si leer más o no. Los lectores de correo modernos organizan los grupos de mensajes relacionados en hilos, que pueden no solo definirse por un asunto común sino por otras cabeceras (que a menudo no se muestran). Entienden que si un hilo comienza a derivar hacia un nuevo tema, puedes y debes ajustar el asunto adecuadamente cuando respondas. La integridad del hilo persistirá, debido a aquellas otras cabeceras, pero el nuevo asunto ayudará a la gente que mira un resumen del hilo a saber que el tema ha derivado. Asimismo, si realmente quieres comenzar un nuevo tema, hazlo creando un nuevo mensaje y no respondiendo uno ya existente y cambiándole el asunto. De esta forma, tu correo podría estar agrupado en el mismo hilo del correo que estás respondiendo y así volver loca a la gente pensando sobre algo que no es. Recuerda: la penalización no será la pérdida de tiempo, sino la pequeña hendidura en tu credibilidad como alguien fluido en el uso de las herramientas de comunicación.

Correos electrónicos bien formateados atraen a los lectores, pero el contenido los mantiene. Ningún conjunto fijo de reglas puede garantizar el buen contenido, por supuesto, hay algunos principios que lo hacen más prometedor.

Hacer las cosas fáciles para tus lectores. Hay una tonelada de información flotando alrededor en cualquier proyecto activo de software libre, y los lectores no pueden esperar estar al corriente de la mayor parte de ella, de hecho, no siempre pueden esperar familiarizarse. En lo posible, tus correos deben sumunistrar información en la forma más conveniente para los lectores. Si tienes que pasar unos dos minutos extra buscando el URL de un hilo particular en los archivos de la lista de correo, atendiendo al objetivo de librar a tus lectores de hacerlo, vale la pena. Si tienes que pasar unos 5 o 10 minutos extra resumiendo las conclusiones de un hilo complejo, con la intención de brindarle a las personas el contexto en el cual comprederán tu correo, entonces hazlo. Piénsalo de esta manera: el mayor éxito en un proyecto, es aumentar el cociente lector-a-escritor en cualquier foro dado. Si cada correo tuyo es visto por n personas, entonces como n aumenta, la utilidad de realizar un esfuerzo adicional para ayudar a aquellas personas aumenta con el tiempo. Y como las personas te verán imponer este estándar, trabajarán imitándolo en sus propias comunicaciones. El resultado es, idealmente, un incremento en la eficiencia global del proyecto: cuando hay una elección entre n personas realizando un esfuerzo y una persona haciendolo, el proyecto prefiere el segundo.

No acostumbrarse a la hipérbole. La exageración de correos online es una clásica competencia de armamento. Por ejemplo, a una persona que reporta un fallo puede preocuparle que los desarrolladores no le presten la suficiente atención, así que lo describirá como grave, gran problema que es prevenirle (y a todos sus amigos/compañeros de trabajo/primos) de la utilización del software productivamente, cuando es solamente una molestia leve. Pero la exageración no está limitada a los usuarios; los programadores frecuentemente hacen lo mismo durante debates técnicos, especialmente cuando el desacuerdo es una cuestión de gustos más que de corección:

El mismo sentimiento se vuelve más fuerte cuando está expresado de una forma menos brusca:

No podrás librarte completamente de la hipérbole, y en general no es necesario hacerlo. Comparada con otras formas retóricas, la hipérbole no es globalmente dañina y perjudica principalmente al autor. Los destinatarios pueden comprender, solamente que el remitente pierde un poco más de credibilidad cada vez. Por lo tanto, para bien de tu influencia en el proyecto, intenta proceder con moderación. De esa manera, cuando necesitas presentar un punto fuerte, las personas te tomarán con seriedad.

Corregir dos veces. Para cualquier mensaje más largo que el tamaño medio de un párrafo, se recomienda volver a leerlo de arriba a abajo antes de enviarlo pero después de que lo tengas listo. Éste es un conocido consejo para cualquiera que haya tomado una clase de composición, pero es especialmente importante para las discusiones en línea. Ya que el proceso de composición en línea tiende a ser altamente discontinuo (en el transcurso de escritura de un mensaje, podrías necesitar retroceder y revisar otros correos, visitar ciertas páginas web, ejecutar un comando para capturar su salida de depuración, etc.), es especialmente fácil perder el sentido de tu papel narrativo. Mensajes que fueron escritos discontinuamente y no fueron revisados antes de ser enviados son frecuentemente reconocibles como tal, mucho el disgusto (o uno esperaría) de sus autores. Tómate el tiempo para examinar lo que envías. Cuanto más estructurados sean tus mensajes, más leidos serán.

Después de escribir miles de mensajes, probablemente notarás que tu estilo tiende a ser extremadamente conciso. Esto parece ser la norma en la mayoría de los foros técnicos, y no hay nada malo con ello. Un nivel de brevedad que sería inaceptable en interacciones sociales normales es sencillamente el común para los hackers de software libre. Aquí está una respuesta a la que yo recurrí una vez en una lista de correo acerca de cierto software gratuito de administración de contenido, citado en su totalidad:

¿Puedes explicar exactamente con que problema
te enfrentas?

Además:

¿Qué versión de Slash estás usando? No pude encontrarlo en
tu mensaje original.

¿Exactamente como compilaste el código de apache/mod_perl?

¿Probaste el parche de Apache 2.0 que fue colocado en
slashcode.com?

  Shane

Eso es ser conciso! No tiene bienvenida, ni despedida con excepción de su nombre, y el mensaje en sí es solamente una serie de preguntas expresadas de la forma más compacta. Su oración declarativa fue una crítica implícita de mi mensaje original. Aunque, me alegra ver el correo de Shane, y no tomar su brevedad como un producto de cualquier otro motivo que no sea el de ser una persona ocupada. El mero hecho de que él haga preguntas, en vez de ignorar mi mensaje, significa que él es esta dispuesto a dedicarle cierto tiempo a mi problema.

¿Reaccionarán positivamente todos los lectores a este estilo? No necesariamente; depende de la persona y el contexto. Por ejemplo, si una persona envía un correo reconociendo que cometió un error (quizás codificó un fallo), y sabes por experiencias pasadas que esta persona tiende a ser un poco insegura, entonces mientras puedas escribir una respuesta compacta, deberías asegurarte de dejarlo con algo de mención hacia sus sentimientos. La mayor parte de tu respuesta puede ser un breve análisis de la situación desde el punto de vista del ingeniero, tan conciso como quieras. Pero al final, deberías despedirte con algo que indique que la brevedad no debe ser tomada como frialdad. Por ejemplo, si sólo escribiste montones de consejos indicando exactamente como la persona debería corregir el fallo, entonces debes despedirte con "Buena suerte, NOMBRE_DE_LA_PERSONA" para indicar que le deseas suerte y que no eres malgeniado. Una carita sonriente colocada estratégicamente u otro emoticón, también puede con frecuencia ser suficiente para tranquilizar a un interlocutor.

Puede resultar un tanto extraño centrarse en el sentimiento de los colaboradores, asi como tambien en lo superficial de lo que dicen por decirlo de alguna manera sin rodeos, los sentimientos afectan a la productividad. Los sentimientos tambien son importantes por otras razones, porque incluso confinandonos a nosotros mismos a razones puramente utilitarias, podemos notar que la gente infeliz escribe peor software, y/o menos. Dada la naturaleza restrictiva de la mayoria de los medios electronicos, aunque, a menudo no habra indicios patentes de como se siente una persona. Tendras que realizar una adecuada suposicion basandote en a) como se sentiria la mayoria de la gente en esa situacion, y b) que es lo que conoces de esa persona particular a partir de interacciones pasadas. Algunas personas prefieren una actitud mas pasiva, y simplemente estan de acuerdo con todo el mundo sin cuestionarlos, la idea tras esto es que si un participante no dice abiertamente que es lo que piensa, entonces uno no tiene nada que hacer tratandole como pensaba que lo hacia. No comparto este enfoque, por un par de razones. Una, la gente no se comporta de esa manera en la vida real, asi que porque deberian hacerlo online? Dos, dado que la mayoria de las interacciones tienen lugar en foros publicos, la gente tiende a ser incluso mas moderada expresando las emociones que lo podrian ser en privado. Para ser mas preciso, a menudo estan deseando expresar emociones directamente a otros, tales como de agradecimiento o indignacion, pero no emociones directamente intimas como inseguridad u orgullo. Todavía, la mayoría de los humanos trabajan mejor cuando saben que los demás son conscientes de su estado de ánimo. Prestando atención a a pequeñas pistas, normalmente podrás suponerlo acertadamente la mayoría del tiempo, y motivar a la gente a estar involucrada con un mayor grado que de otra manera no podrían.

Por supuesto no quiero decir que, tú rol sea el de un terapeuta de grupo, ayudando constantemente a todo el mundo a estar al corriente de sus sentimientos. Pero poniendo una especial atención a patrones a largo-plazo en el comportamiento de la gente, empezarás a tener una sensación de ellos como individuos incluso aunque nunca los hayas conocido cara a cara. Y siendo sensible en el tono de tus mensajes escritos, podrás tener una cantidad sorprendente de influencia sobre los sentimientos de los demás, que es el último beneficio del proyecto.

Una de las características que definen la cultura del código abierto son son las nociones distintivas de qué constituye grosería y qué no. Mientras que los convenios que se describen debajo no son únicos para el desarrollo de software libre, ni tampoco para el software en general debería ser familiar para cualquiera que trabaje en disciplinas de las matemáticas, ciencias puras o la ingeniería el software libre, con sus porosos límites y un constante influjo de recién llegados, es un entorno donde es especialmente probable encontrar estas convenciones por gente no familiarizada con ellas.

Comencemos con las cosas que no son groseras (maleducadas):

La crítica técnica, incluso cuando es directa y sin tacto, no es una grosería. De hecho, puede ser una forma de adulación: la crítica es decir, por implicación, que vale la pena tomarse en serio el destinatario,y vale la pena invertir tiempo en él. Es decir, cuanto más viable fuera simplemente ignorar el mensaje de alguien, se entiende más por un cumplido molestarse en criticarlo (a no ser que la crítica se convierta, por su puesto, en un ataque ad hominem o alguna otra forma de grosería obvia).

Preguntas directas, sin adornos, como la que Shane me hizo en el correo anterior tampoco es grosería. Preguntas que, en otros contextos, pueden parecer frias, retóricas e incluso a modo de burla, son formuladas a menudo de una forma seria, y no tienen más intención que obtener información lo más rápido posible. La famosa pregunta del soporte técnico "¿Está su ordenador conectado?" es un ejemplo clásico de esto. La persona de soporte realmente necesita saber si tu ordenador está contectado y, después de unos pocos días en el trabajo, se ha cansado de adornar su pregunta de florituras ("Le pido disculpas, quisiera que me contestara unas simples preguntas para descartar algunas posibilidades. Algunas pueden parecer muy básicas, pero tenga paciencia..."). En este punto, no le importa seguir adornando más simplemente pregunta directamente: ¿está o no está conectado? Preguntas similares se hacen en todo momento en las lista de distribución del software libre. La intención no es insultar al destinatario, sino descartar rápidamente las explicaciones más obvias (y quizás más comunes). Los destinatarios que lo entiendan y reaccionen de ese modo ganarán puntos en tener una visión tolerante sin provocarse. Pero los destinatarios que reaccionen mal tampoco deberían ser reprendidos. Es simplemente una colisión de culturas, no es culpa de nadie. Explica amablemente que tu pregunta (o crítica) no tiene significados ocultos; que solo significaba obtener (o transmitir) la información de la forma más eficientemente posible, nada más.

Entonces, ¿qué es grosería?

Bajo el mismo principo por el cual las críticas a detalles técnicos es una forma de halago, no proporcionar críticas de calidad puede ser un tipo de insulto. No quiero decir simplemente que ignorando el trabajo de alguien, sea una propuesta, cambio en el código, nuevas informaciones o cualquier cosa. A menos que explicitamente prometas una reacción detallada más adelante, normalmente es OK simplemente no reaccionando de ninguna manera. La gente asumirá así que no tuviste tiempo de decir nada. Pero si tu reaccionas , no escatimes: tómate el tiempo para analizar detalladamente las cosas, proporcionar ejemplos concretos allá donde sea apropiado, rebuscar a través de los archivos para encontrar información relacionada del pasado, etc. O si no tienes tiempo para realizar todo ese esfuerzo, pero todavía necesitas escribir algún tipo de respuesta corta, entonces exponlo de manera abierta y breve en tu mensaje ("Creo que hay un tema abierto para esto, pero desafortunadamente no tuve tiempo para buscarlo, lo siento"). Lo principal es reconocer la existencia de la norma cultural, ya sea algo satisfactorio o reconociendo abiertamente que ha fallado ligeramente esta vez. Sea lo que sea, la norma es reforzar. Pero el no cumplir esta norma mientras que al mismo tiempo no se explica el porque fallaste en conecerlo, es lo mismo que decir el tópico (y aquellos que participan en ello) no mereció tu tiempo. Es mejor mostrar que tu tiempo es muy valioso siendo seco que siendo vago.

Hay muchas otras formas de grosería, por supuesto, pero la mayoría no es específica del desarrollo de software libre, y el sentido común es una buena forma de evitarlas. Véase también “Cortar de Raíz la Mala Educación” en Capítulo 2, Primeros Pasos, si lo has hecho todavía.

Hay una parte en el cerebro humano dedicada específicamente a reconocer caras. Es conocida informalmente como "área de fusión de caras", y sus capacidades son mayoritariamente innatas , no se han aprendido. Resulta que reconocer a las personas individualmente es una técnica tan crucial de supervivencia que hemos desarrollado un hardware especializado para ello..

La colaboración basada en Internet es por ello psicologicamente curiosa porque implica una estrecha colaboración entre seres humanos que nunca se identificarían entre ellos por los más naturales e intuitivos métodos: reconocimiento facial el primero de todos, pero tambien por el sonido de la voz, postura, etc. Para compensar esto, intenta usar un consistente Nombre en todas partes. Debería ser la primera parte de tu dirección de email (la parte antes de el signo @), tu nombre del IRC, tu nombre para hacer commit en los repositorios, tu marca de nombre en cualquier lado y así. Este nombre es tu "cara" online : un tipo de cadena de identificación que sirve el mismo propósito que tu cara real, aunque no lo es, desafortunadamente, estimula el mismo hardware consitutido en el cerebro.

El nombre que muestras debería ser una permutación intuitiva de tu nombre real (el mío por ejemplo, es "kfogel"). En algunas situaciones estará acompañado de tu nombre completo, por ejemplo en las cabeceras del correo:

From: "Karl Fogel" <kfogel@whateverdomain.com>

Actualmente, hay dos puntos a tener en cuenta en ese ejemplo. Como ya he mencionado anteriormente, el nombre que mostraremos coincidirá con el nombre real de una manera intuitiva. Pero tambien, el nombre real es real. Esto es, no se compone de una denominación como:

From: "Wonder Hacker" <wonderhacker@whateverdomain.com>

Hay una famosa tira cómica de Paul Steiner, del 5 de Julio de 1993 publicada en The New Yorker, que muestra a un perro que ha iniciado sesión en un terminal de ordenador, menospreciando y contando a los demás de manera conspiratoria: "En Internet, nadie sabe que tú eres un perro." Este tipo de pensamiento es una mentira detrás de tanto ensalzamiento propio, significado de estar a la moda con las identidades online que la gente se atribuye a ellos mismos; como llamándose uno mismo "Wonder Hacker" causará que la gente piense que uno es un maravilloso hacker. Pero los hechos permanecen: incluso si nadie sabe que tu eres un perro, todavía seras un perro. Una fantástica identidad online nunca impresiona a los lectores. En vez de esto, les hace creer que eres más una imagen que una persona con fundamento, o que simplemente eres inseguro. Utiliza tu nombre real para todas las interacciones, o si por alguna razón necesitas un anónimo, entonces crea un nombre que se parezca perfectamente a un nombre real, y úsalo consistentemente.

Además de mantener tu imagen online consistente, hay algunas cosas más que puedes hacer para que resulte más atractiva. Si posees un título oficial (ejem., "doctor", "profesor", "director"), no hagas obstentación de ello, no lo menciones a menos que sea directamente relevante a la conversación. El mundo hacker en general y la cultura del Software Libre en particular, tienden a ver la muestra de títulos como un signo de exclusión y de inseguridad. Esta bien si tu título aparece como parte de un bloque de firma standard al final de cada mail que envías, pero no lo utilices como una herramienta para reforzar tu posición en una discusión; al intentarlo está garantizado el fracaso. Tu quieres que la gente te respete como persona, no por el título.

Hablando de bloques de firma: mantelos pequeños y con buen gusto, o mejor todavía, inexistentes. Evita largas responsabilidades legales fijadas al final de cada mail, especialmente cuando estos expresen sentimientos incompatibles con la participación en un proyecto de software libre. Por ejemplo, el siguiente clásico del género aparece al final de cada post que un usuario particular hace en una lista de mail pública donde yo estoy:

IMPORTANT NOTICE

If you have received this e-mail in error or wish to read our e-mail
disclaimer statement and monitoring policy, please refer to the
statement below or contact the sender.

This communication is from Deloitte & Touche LLP.  Deloitte &
Touche LLP is a limited liability partnership registered in England
and Wales with registered number OC303675.  A list of members' names
is available for inspection at Stonecutter Court, 1 Stonecutter
Street, London EC4A 4TR, United Kingdom, the firm's principal place of
business and registered office.  Deloitte & Touche LLP is
authorised and regulated by the Financial Services Authority.

This communication and any attachments contain information which is
confidential and may also be privileged.  It is for the exclusive use
of the intended recipient(s).  If you are not the intended
recipient(s) please note that any form of disclosure, distribution,
copying or use of this communication or the information in it or in
any attachments is strictly prohibited and may be unlawful.  If you
have received this communication in error, please return it with the
title "received in error" to IT.SECURITY.UK@deloitte.co.uk then delete
the email and destroy any copies of it.

E-mail communications cannot be guaranteed to be secure or error free,
as information could be intercepted, corrupted, amended, lost,
destroyed, arrive late or incomplete, or contain viruses.  We do not
accept liability for any such matters or their consequences.  Anyone
who communicates with us by e-mail is taken to accept the risks in
doing so.

When addressed to our clients, any opinions or advice contained in
this e-mail and any attachments are subject to the terms and
conditions expressed in the governing Deloitte & Touche LLP client
engagement letter.

Opinions, conclusions and other information in this e-mail and any
attachments which do not relate to the official business of the firm
are neither given nor endorsed by it.

Para alguien que únicamente se quiere presentar para preguntar alguna cuestión ahora y entonces, esta gran "renuncia" parece un poco fuera de lugar pero probablemente no hace ningún daño. Sin embargo, si esta persona quería participar activamente en el proyecto, este formalismo-legal empezaría a tener un efecto más insidioso. Enviaría al menos dos señales potencialmente destructivas: primero, qué esta persona no tiene un control total sobre sus herramientas; está atrapado dentro de una cuenta de correo corporativa que acarrea un mensaje molesto al final de cada mail, y el no tiene ningúna manera de evitarlo; y segundo, que tiene poco o ningún apoyo de su organización para contribuir en las actividades del software libre. Cierto, que la organización claramente no le ha prohibido completamente de postear en listas públicas, pero hace que sus posts se distingan con un mensaje frío, ya que el riesgo de dejar información confidencial debe figurarse sobre las demás prioridades.

Si trabajas para una organización que insiste en añadir tales bloques de firma en todos los mail salientes, entonces considera tener una cuenta de correo gratuito de, por ejemplo, gmail.google.com, www.hotmail.com, or www.yahoo.com, y utilizar esta dirección para el proyecto.