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.