Comunicaciones
La capacidad de escribir claramente es quizás la más importante habilidad
que se puede tener en un ambiente de código abierto. A largo plazo
es más importante que el talento para programar. Un gran programador con pocas
habilidades comunicativas puede realizar sólo una cosa a la vez, y
puede tener problemas convenciendo a otros para que le presten atención. Pero un mal
programador con buenas habilidades de comunicación puede coordinar y persuadir
mucha gente para realizar diferentes cosas, y de tal modo tener un
efecto significativo sobre la dirección y el ímpetu de un proyecto.
No parece haber mucha correlación, en cualquier sentido,
entre la capacidad de escribir buen código y la capacidad de comunicarse
con sus compañeros. Hay cierta correlación entre
programar bien y describir bien cuestiones técnicas, pero describir
asuntos técnicos es sólo una pequeña parte de las comunicaciones en un
proyecto. Más importante es la capacidad de enfatizar con su
audiencia, ver sus propios correos y comentarios como lo ven los demás, y
hacer que los demás vean sus propios correos con objetividad similar.
Igualmente importante es notificar cuando un medio o método
de comunicación determinado no está funcionando bien, quizás porque no escala al ritmo que
incrementa el número de usuarios, y tomar el tiempo para hacer algo
al respecto.
Aquello que es obvio en teoría y que se hace duro en la
práctica es que los ambientes de desarrollo de software libre son
desconcertadamente diversos tanto en audiencias como en mecanismos de
comunicación. ¿Debería una opinión dada ser expresada en un mensaje a la
lista de correo, como una anotación en el gestor de fallos, o como un comentario
en el código? Al contestar una pregunta en un foro público, ¿cuánto
conocimiento puedes asumir por parte del lector?, en primer lugar dado que "el
lector" no es el único que hizo la pregunta,
¿pueden todos ver tú respuesta? ¿Como pueden los desarrolladores
permanecer en contacto constructivo con los usuarios, sin ser ahogado
por peticiones de características, informes falsos de fallos, y charla en general? ¿Cómo
dices cuando un medio ha alcanzado los límites de su capacidad, y
que harías al respecto?
Las soluciones a estos problemas son usualmente parciales, ya que cualquier
solucion particular se vuelve finalmente obsoleta por el crecimiento del proyecto o
los cambios en la estructura del mismo. Son a menudo ad
hoc, ya que son respuestas improvisadas a situaciones
dinámicas. Todos los participantes necesitan darse cuenta de como y cuando
la comunicacion puede volverse farragosa, y deben estar implicados en
buscar soluciones. Ayudar a la gente a hacer esto es una gran parte de la direccion en un proyecto
open source. Las secciones siguientes tratan sobre como conducir
tu propia comunicacion y como hacer el mantenimiento de los mecanismos de
comunicacion una prioridad para todo el mundo en el proyecto.Se ha
hecho alguna investigacion academica interesante en esta materia; por ejemplo,
vease Group Awareness in Distributed Software
Development por Gutwin, Penner, y Schneider (solia estar
disponible on-line, pero parece que ha desaparecido, al menos
temporalmente; utiliza una herramienta de busqueda encontrarla).
Tú eres lo que escribes
Considera esto: la única cosa que cualquier persona sabe de ti en
Internet viene de lo que tú escribes, o de lo que otros escriben acerca de ti.
Puedes ser brillante, perceptivo, y carismático en persona pero
si tus correos electrónicos son incoherentes y no estructurados, la gente asumirá
que esé es el verdadero tú. O quizás realmente eres incoherente y
no estructurado en persona, pero nadie tiene por que saberlo, si tus mensajes
son claros e informativos.
Dedicar cierto cuidado a tu escritura valdrá enormemente la pena.
El veterano hacker de software libre Jim Blandy narra la siguiente
historia:
Por el año 1993 trabajaba para la Fundación de Software Libre,
y estábamos llevando a cabo el beta-testing de la versión 19 de GNU Emacs. Haríamos una
publicación beta más o menos cada semana, y la gente la probaría y nos enviaría
informes de error. Había un chico que ninguno de nosotros conocía en
persona pero que hizo un gran trabajo: sus informes de error siempre fueron claros y
nos enfocaba hacia el problema y, cuando nos proporcionaba una corrección,
casi siempre tenía razón. Era un fuera de serie.
Ahora, antes que la FSF pueda utilizar código escrito por alguien, hay que
realizar un papeleo legal para que el interés de esa persona hacia el copyright
del código pase a la FSF. Simplemente tomando el código de completos extraños
dejándolo dentro es una receta para el desastre legal.
Por lo que le envié un correo al chico con los formularios diciéndole "Te envío algo de papeleo
que necesitamos, esto es lo que significa, firmas este, haces que quien te tiene contratado
firme este otro y, entonces podemos comenzar a utilizar tus correcciones. Muchas
gracias."
Me envió un mensaje de vuelta diciendo: "No trabajo para
nadie."
Por lo que le dije: "Bien, eso está bien, simplemente haz que firme tu universidad
y envíamelo de vuelta."
Después de un poco, me escribió de nuevo y me dijo: "Verás,
realmente... tengo trece años y vivo con mis padres."
Debido a que ese chico no escribía como si tuviera trece años nadie
supuso que los tuviera. A continuación se exponen también algunas cosas que
conseguirán además que tu escritura de una buena impresión.
Estructura y formato
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.
Contenido
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:
"Hacerlo de esa manera haría el código totalmente
ilegible. Sería una pesadilla para el mantenimiento, comparado a la
propuesta de J. Random..."
El mismo sentimiento se vuelve más
fuerte cuando está expresado de una forma menos brusca:
"Pienso que eso funciona, pero menos de lo ideal en términos de
legibilidad y mantenimiento. La propuesta de J. Random
evita esos problemas ya que..."
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.
Tono
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.
Reconociendo la grosería
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
en
, si lo has hecho
todavía.
Caras
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, ,
, or , y utilizar
esta dirección para el proyecto.
Evitando los obstáculos corrientes
No envíes un correo sin un propósito
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 para ver más ideas sobre como portarse
en una lista de correo muy concurrida.)
Hilos productivos vs Hilos Improductivos
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.
Cuanto más blando sea el tema, más largo será el debate
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.; see also
.)
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.
Evitando las Guerras Santas
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 in ),
en respuesta a munging (mira
en ), 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
, y el artículo de Danny Cohen
que popularizó el término, .
El efecto "Ruido Minoritario"
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.
Gente difícil
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.
Tratando con gente difícil
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.
Estudio del caso
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
en
). 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.
Manejando el crecimiento
El precio del éxito es muy pesado en el mundo del Open Source. Conforme
tu software se hace más popular, el número de gente que empieza a buscar información
sobre él, se incrementa dramaticamente, mientras el número de gente capaza de proporcionar
información se incrementa mucho más despacio. Además, incluso si el ratio fuera uniformemente
balanceado, todavía existiría un problema de escalabilidad en la forma en que la mayoría de
los proyectos Open source manejan las comunicaciones. Considera por ejemplo las listas de correo.
La mayoría de los proyectos tienen una lista de correo para cuestiones generales de los usuarios; a
veces los nombres de estas listas son "usuarios", "discusiones", o "ayuda" o algo similar. Cualquiera
que sea su nombre, el propósito de esas listas es el mismo: proporcionar un lugar donde la gente pueda
resolver sus cuestiones, mientras otros observan y (presumiblemente) absorben conocimiento de la
observación de ese intercambio de conocimiento.
Estas listas de correo funcionan muy bien hasta unos pocos miles de usuarios
y/o un par de cientos de posts al día. Pero más o menos, a partir de ahí el sistema
empieza a romperse, porque cada suscriptor vee cada post; si el número de post a la lista
empieza a exceder lo que cualquier lector individual puede procesar en un día, la lista se
convierte en una carga para sus miembros. Imagina por ejemplo, si Microsoft tuviera tal
lista de correo para Windows XP. Windows XP tiene cientos de millones de usuarios; aún
incluso si el uno por ciento de ellos tuviera cuestiones en un periodo de veinticuatro
horas, entonces esta lista hipotética cientos de miles de posts al día! Por supuesto,
tal lista de correo no podría existir, porque nadie permanecería subscrito. Este problema
no esta limitado a las listas de correo; la misma lógica se aplica a los canales del IRC,
los foros de discusión online y por ende, a cualquier sistema en el cual un grupo escuche
preguntas de individuos. Las implicaciones son siniestras: el modelo usual del Open Source
del soporte masivamente paralelizado simplemente no escala los niveles necesarios para
la dominación mundial.
No habrá una explosión cuando los foros alcancen su punto de ruptura.
Se trata simplemente de un efecto silencioso de feedback negativo: la gente se borrará de
las listas, o saldrán de los canales del IRC, o a cualquier ritmo cesaran de preocuparse
en preguntar cuestiones, porque verán que no se les escuchará entre tanta gente. Así
cuanta más gente haga de estas su principal elección racional, la actividad de los foros
empezará a permanecer a un nivel inmanejable precisamente porque la gente racional o
(al menos experimentada), empezará a buscar información por otros medios, mientras la gente
sin experiencia permanecerá y continuará preguntando en foros y listas de correo.
En otras palabras, uno de los efectos de continuar con el uso de modelos de comunicación
que no son escalables mientras que el proyecto crece es que la calidad media tanto de preguntas
y respuestas tiene a disminuir, lo cual hace que los nuevos usuarios parezcan más tontos de
lo que son, cuando de hecho probablemente no lo sean. Se trata simplemente de que el ratio
beneficio/costo de el uso de esos foros masificados, disminuye, por lo que de manera
natural, aquellos con experiencia, empezarán a buscar respuestas en otros sitios.
Ajustar los mecanismos de comunicación para poder con el crecimiento del proyecto,
implicará dos estrategias relacionadas:
Reconociendo cuando partes especiales de un foro
no sufren un crecimiento desmesurado, incluso si el
foro se trata como un todo, y separando aquellas partes creando otras nuevas,
en foros más especializados (ejem., no dejes que los buenos se arrastren por
los malos).
Asegurando que existen muchas fuentes de información automáticas
disponibles, y que se mantienen organizadas, actualizadas y fáciles de localizar.
La estrategia (1) normalmente no es muy dura. La mayoría de los proyectos
empiezan con un foro principal: y una lista de correo para discusiones generales,
en las cuales las ideas de características, cuestiones de diseño y problemas de
codificación puedan ser discutidos. Todo el mundo involucrado en el proyecto está
en la lista. Despues de un tiempo, se comprueba que la lista ha evolucionado en
varias sublistas basadas en diferentes temáticas. Por ejemplo, algunos hilos son
claramente sobre desarrollo y diseño; otros son dudad de usuarios del tipo ¿"Cómo
hago tal cosa"?; quizá exista una tercera temática centrada en el registro de procesar
los informes de bugs y peticiones de mejora; y así. Un individuo dado, por supuesto
puede participar en varios tipos diferentes de hilos, pero lo más importante de todo
es que no hay mucho solapamiento entre los diferentes tipos mismos. Pueden ser divididos
en listas separadas sin causar ningún perjuicio en el proyecto, porque los hilos se
mantienen repartidos por temáticas.
Actualmente, realizar esta división es un proceso de dos pasos. Creas la nueva lista
(o el canal IRC, o lo que vaya a ser), y entonces gastas el tiempo necesario de manera
educada pero insistiendo y recordando a la gente a usar los nuevos foros
apropiadamente. Este paso puede llevar semanas pero finalmente la gente captará la idea.
Simplemente tienes que hacer ver a alguien que envía un post al destino equivocado, cual
es el nuevo camino y hacerlo de manera visible, animando a que otras personas ayuden tambien
en los nuevos usuos. Es tambien muy útil tener una página web proporcionando una guía hacía
todas las listas disponibles; tus respuestas simplemente pueden referenciar esta página y,
como gratificación, el destinatario puede aprender sobre las pautas a seguir antes
de escribir un correo.
La estrategia (2) es un proceso en curso, dura durante todo el tiempo de vida del proyecto
e involucra a muchos participantes. Por supuesto es en parte cuestión de tener una documentación
actualizada (mira
en
) y asegurándote que la gente
vaya ahí. Pero es tambien mucho más que eso; las secciones que siguen discuten
esta estrategia en detalle.
Sobresaliente uso de los archivos
Tipicamente, todas las comunicaciones de un proyecto Open Source (excepto algunas
veces conversaciones en el IRC), son archivadas. Los archivos son públicos y se pueden buscar,
y tienen una estabilidad referencial: que significa, una vez que una pieza de información
se ha grabado en una dirección particular, permanece en esa dirección para siempre.
Usa estos archivos tanto como puedas, y tan visiblemente como sea posible. Incluso cuando
sepas la respuesta a alguna pregunta, si piensas que existe una referencia en los archivos que
contiene la respuestas, gasta el tiempo necesario para buscarla y presentarla. Cada vez que hagas
esto de una manera públicamente visible, algunas personas aprenderan la primera vez que significan
esos archivos, y que buscando en ellos pueden encontrar respuestas. Tambien, refiriéndose a los
archivos en vez de reescribir la respuesta, refuerzas la norma social contra la duplicación de
información. ¿Por qué obtenemos la misma respuesta en dos sitios diferentes? Cuando el número de
sitios que se puede encontrar es mantenido a un mínimo, la gente que lo ha encontrado antes están
más predispuestos a recordar qué y donde buscarlo para las próximas veces. Las referencias bien
situadas tambien contribuyen a la calidad de los resultados de búsqueda en general, porque ellos
refuerzan los recursos del objetivo en los rankings de los motores de búsqueda en Internet.
Sin embargo, hay veces en las que duplicar la información tiene sentido.
Por ejemplo, supon que hay una respuesta en los archivos, que no es de tí, diciendo:
Parece que los índices Scanley indexes han sido corrompidos. Para devolverlos a
su estado original, ejecuta estos pasos:
1. Apaga el servidor Scanley.
2. Ejecuta el programa 'descorromper' que viene con Scanley.
3. Inicia el servidor.
Entonces, meses después, ves otro mail indicando que algunos indices
han sido corrompidos. Buscas los archivos y presentas la vieja respuesta anterior,
pero te das cuenta que faltan algunos pasos (quizás por error, o quizá porque el
software ha cambiado desde que se escribió ese post). La clásica manera para manejar
esto, es escribir un nuevo mail, con un conjunto de instrucciones más completo, y
explicitamente dar como obsoleto el anterior post mencionándolo así:
Parece que tus índices Scanley han sido corrompidos. Vimos este problem allá por Julio,
y J. Random publicó una solución en http://blahblahblah/blah. Abajo hay una descripción
más completa de como recuperar tus índices, basado en las instrucciones de J. Random
pero extendiéndolo un poco más:
1. Para el servidor Scanley.
2. Cambiate al usuario con el que se ejecuta el servidor Scanley.
3. Como este usuario, ejecuta el programa 'recuperar' en los índices.
4. Ejecuta Scanley a mano para ver si los índices funcionan ahora.
5. Reinicia el servidor.
(En un mundo ideal, sería posible poner una nota en el viejo post,
indicando que existe información más actualizada y apuntando al nuevo post
que la contiene. Sin embargo, no conozco ningún software de archivación que
ofrezca una característica "obsoleto por", quizá porque sería muy difícil de
implementar de una manera en que no viole la integridad de los archivos. Esta
es otra razón de porqué es buena idea crear páginas web con respuestas a cuestiones
comunes.
Los archivos probablemente son buscados más a menudo para respuestas
a cuestiones técnicas, pero su importancia para el proyecto va más allá de eso.
Si una pauta formal del proyecto son sus leyes establecidas, los archivos son
su ley común: una grabación de todas las decisiones hechas y como se llegó hasta
ellas. En cualquier discusión recurrente, actualmente es casi obligatorio empezar
con una búsqueda en los archivos. Esto permite empezar la discusión con un sumario
del estado actual de las cosas, anticipandose a objeciones, preparando refutaciones
y posiblemente descubriendo ángulos que no habías imaginado. También los otros
participantes esperan de ti que hayas hecho una búsqueda en los
archivos. Incluso si las discusiones previas no llevaron a ninguna parte, tú deberías
incluir sugerencias cuando vuelvas al téma, para que la gente pueda ver por si mismos
a) que no llegaron a ningun consenso, y b) que tú hiciste tu trabajo, y por tanto que
probablemente se este diciendo algo ahora que no se dijo anteriormente.
Trata todos los recursos como archivos
Todos los consejos anteriores son extensibles más allá de los archivos
de las listas de mail. Tener piezas particulares de información de manera estable,
y en direcciones que se puedan encontrar convenientemente debería ser un principio
de organización para toda la información de un proyecto. Vamos a ver la FAQ como un
caso de estudio.
¿Cómo usa la gente una FAQ?
Buscan palabras y frases específicas.
Quieren poder navegarla, disfrutando de la información sin buscar necesariamente
respuestas a cuestiones específicas.
Esperan que motores de búsqueda como google conozcan el contenido de la FAQ, de
manera que las búsquedas puedan ser entradas en la FAQ.
Quieren ser capaces de dirigirse directamente a otra gente en temas específicos
en la FAQ.
Quieren ser capaces de añadir nuevo material a la FAQ, pero
hay que ver que esto ocurre menos a menudo que la búsqueda de respuestas
—Las FAQs son de lejos mucho más leidas que escritas.
El punto 1 implica que la FAQ debería estar disponible en algún tipo de formato
textual. Los puntos 2 y 3 implican que la FAQ debería estar disponible en forma de página HTML,
con el punto 2 indicando adicionalmnente que el HTML debería ser diseñado con legibilidad (ejem.,
necesitaras algún tipo de control sobre su apariencia), y debería tener una tabla de contenidos.
El punto 4 significa que cada entrada individual en la FAQ debería ser asignada como un HTML
named anchor, (anclas con nombre) un tag que permite a la gente alcanzar un sitio particular
en la página. El punto 5 significa que los ficheros fuente de la FAQ deberían estar disponibles
de una manera conveniente (ver en
), un formato que sea fácil de editar.
Named Anchors y atributos ID
Hay dos maneras para que un navegador vaya a un sitio específico
dentro de una página web: anclas con nombre y atributos id.
Un ancla con nombre es simplemente un elemento HTML
de ancla (<a>...</a>), pero con un atributo
"name":
<a name="mylabel">...</a>
Versiones más recientes de HTML soportan un atributo id
genérico, el cual puede adjuntarse a cualquier elemento HTML,
y no sólo a <a>. Por ejemplo:
<p id="mylabel">...</p>
Ambos, anclas con nombre y atributos id son usados de la misma manera.
Uno añade una marca hash y la etiqueta a una URL, y hacer así al navegador que
salte directo a dicho punto de la página:
http://myproject.example.com/faq.html#mylabel
Virtualmente todos los navegadores soportan las anclas con nombre; los navegadores
más modernos soportan el atributo id. Para asegurarnos, recomendaría utilizar tanto
anclas con nombre únicamente, o anclas con nombrey atributos id attributes
juntos (con la misma etiqueta para ambos en un mismo par, por supuesto). Las anclas con nombre
no pueden ser self-closing—incluso aunque no haya texto dentro del elemento, aún así
deberas escribirlo en la forma two-sided:
<a name="mylabel"></a>
...aunque normalmente habrá algún texto, como el título de una sección.
Allá donde utilices un ancla de nombre, o un atributo id, o ambos,
recuerda que la etiqueta no será visible a nadie que navegue a esa ubicación sin
usar la etiqueta. Pero una persona podrá querer descubrir la etiqueta de un sitio
en particular, para que puedan enviar un mail con la URL de la respuesta a una FAQ
enviada a un amigo, por ejemplo. Para ayudar en eto, añade un atributo de título en
el mismo elemento(s) donde has añadido el "name" y/o el atributo "id", por ejemplo:
<a name="mylabel" title="#mylabel">...</a>
Cuando el ratón se situe sobre el texto dentro del elemento con el atributo
del título, la mayoría de los navegadores mostraran una pequeña caja con el título.
Normalmente, incluyo el signo hash para recordar al usuario que esto es lo que pondrá
al final de la URL para ir directo a esta ubicación la próxima vez.
Formatenado la FAQ de esta manera es sólo un ejemplo de como crear un recurso
presentable. Las mismas propiedades—busqueda directa, disponibilidad en la mayoría
de buscadores de Internet, navegación, estabilidad referencial, y (donde se aplique)
edición—son aplicables a otras páginas web, el arbol del código fuente, el seguimiento
de bugs, etc. Simplemente ocurre que la mayoría del software de archivado de listas de correo
hace tiempo que reconocen la importancia de estas propiedades, y es por lo que las listas
de correo tienden a tener estas funcionalidades de manera nativa, mientras otros formatos
requieren de un esfuerzo extra en la parte de mantenimiento( discute como
difundir esta carga de mantenimiento a través de miles de voluntarios).
Tradición en la organización del contenido
Conforme un proyecto gana en complejidad y adquiere historia, la cantidad de datos que
cada participante debe absorber incrementa. Aquellos que llevan en el proyecto mucho tiempo
serán capaces de aprender, e inventar las convenciones del proyecto conforme avanza. A menudo
no serán conscientes del gran cuerpo de tradición que se ha ido acumulando, y puede sorprender
todos los pequeños fallos que los nuevos participantes del proyecto puedan hacer. Por supuesto,
el tema no es que los recién llegados tengan una menor calidad que los de antes; sino que se enfrentan
a una carga de cultura heredada mayor de la que tenían los recien llegados en el pasado.
Las tradiciones que un proyecto acumula son del tipo cómo comunicar y
mantener información y sobre estándares de codificación y otros temas técnicos. Ya
hemos repasado ambas clases de estándares, en
en y
en
respectivamente, y
se han mostrado ejemplos. Sobre lo que trata esta sección es de como mantener
esas pautas actualizadas conforme el proyecto avanza, especialmente pautas sobre
cómo se administran las comunicaciones, porque estas son las únicas que cambian
la mayoría conforme el proyecto crece en tamaño y complejidad.
Primero, busca patrones de cómo la gente se equivoca. Si observas las mismas situaciones
una y otra vez, especialmente con participantes nuevos, se presenta una oportunidad en forma
de pauta que necesita ser documentada pero no lo está. Segundo, no te canses de decir las mismas
cosas una y otra vez, y que no parezca que estás cansado de repetirlas. Tú
y otros veteranos del proyecto tendréis que repetirlas entre vosotros mismos a menudo; este es un
efecto inevitable de la llegada de nuevos participantes.
Cada página web, cada mensaje de lista de correo, y cada canal del IRC, deberá ser considerado
como un espacio de publicidad per no de anuncios comerciales, sino de anuncios sobre los recursos propios
de tu proyecto. Lo que pongas en este espacio dependerá de la procedencia de los que lo vayan a leer.
Un canal IRC para cuestiones de usuario, por ejemplo, atraerá gente que nunca habrá interactuado con
el proyecto antes, a menudo alguien que ha instalado el software, y tiene alguna pregunta que le gustaría
que le respondieran al momento (después de todo, si puediera esperar, hubiera enviado un mail a la lista
de correo la cual probablemente usa menos de su tiempo total, aunque tardaría más en recibir respuesta).
La gente normalmente no realiza una inversión permanente en el canal de IRC, aparecerán, lanzarán su pregunta
y se irán.
De ahí, el tema del canal debería apuntar a gente buscando respuestas técnicas en ese
momento, en vez de, gente que quiera involucrarse con el proyecto de una manera permanente
y para los cuales unas pautas de interaccion serían más apropiadas. Aquí es donde un
canal verdaderamente ocupado lo maneja (comparalo con el ejemplo anterior en
en
):
You are now talking on #linuxhelp
Topic for #linuxhelp is Please READ
http://www.catb.org/~esr/faqs/smart-questions.html &&
http://www.tldp.org/docs.html#howto BEFORE asking questions | Channel
rules are at http://www.nerdfest.org/lh_rules.html | Please consult
http://kerneltrap.org/node/view/799 before asking about upgrading to a
2.6.x kernel | memory read possible: http://tinyurl.com/4s6mc ->
update to 2.6.8.1 or 2.4.27 | hash algo disaster: http://tinyurl.com/6w8rf
| reiser4 out
Con las listas de correo, el "espacio de AD" es un ligero pie de página
añadido a cada mensaje. La mayoría de los proyectos ponen ahí instrucciones de
suscripción/borrado, y quizás un enlace a la página principal del proyecto o también
a la FAQ. Puedes pensar que cualquiera que esté suscrito a la lista sabrá donde encontrar
esa información, y probablemente entonces lo hagan, pero mucha más gente que únicamente
los subscriptores verán esos correos de la lista. Un post archivado se puede enlazar
desde diversos lugares; de hecho, algunos posts se vuelven tan famosos que eventualmente
son leidos por más lectores fuera de la lista que de ella.
El formateo puede crear una gran diferencia. Por ejemplo, en el proyecto, tuvimos un éxito
limitado utilizando la técnica de filtrado de bugs descrita en
en
. Muchos de los falsos bugs
reportados estaban siendo todavía rellenados por gente sin experiencia, y ocurría
cada vez, el informador tenía que ser educado de la misma manera que lo había sido con
las 500 personas de antes. Un día, después de que a uno de nuestros desarrolladores finalmente
se le agotara la paciencia y empezó a criticar y meterse con un pobre usuario por no haberse
leído detenidamente la guía de uso del bug tracker, otro desarrollador decidió que este
patrón había ido ya demasiado lejos. Sugirió que reformatearamos la página frontal del bug
tracker de tal forma que lo más importante, los mandatos para discutir los bugs en la
lista de correo o en los canales IRC antes de rellenarlos, serían letras muy grandes, en rojo
resaltado sobre un fondo amarillo y resaltado claramente sobre todo los demás elementos
de la página. Así lo hicimos (puedes ver los resultados en
), y
y el resultado fue un descenso notable en el ratio de falsos bugs relleandos.
Por supuesto, todavía los tenemos, y siempre los tendremos, pero el ratio ha descendido
considerablemente, incluso aunque el número de usuarios incrementa. El resultado no es solamente
que la base de datos de bugs tiene menos basura, sino que aquellos que responden a los tickets
de bugs lo hacen con buen carácter, y es más probable permanecer amistosamente cuando se responde
a uno de los pocos bugs falsos. Esto mejora tanto la imagen del proyecto como la salud mental de sus
voluntarios.
La leccion para nosotros fue que únicamente escribiendo unas guías de uso no era demsiado.
También tuvimos que colocarlas allá donde más se vieran por la gente que más las iba a necesitar,
y formatearlas de tal manera que su estado y material introductorio estuviese inmediatamente claro
para la gente que no estuviera familiarizada con el proyecto.
Las páginas web estáticas no son el único lugar para publicar las características
del proyecto. Una cierta cantidad de políticas interactivas (en el sentido de recordatorio-amigable
, no en el sentido de enjaular y atar) también son requeridas. Todas las revisiones por pares, incluso
las revisiones de commits descritas en
en
, deberían incluir revisiones
de conformidad o no-conformidad con las normas del proyecto, especialmente en relación
a las convenciones de las comunicaciones.
Otro ejemplo del proyecto Subversion: fijamos una convención de
"r12908" qué significaba "revision 12908 en el repositorio de control
de versiones". El prefijo "r" es facil de escribir, y porque
es la mitad de peso que los dígitos, lo hace un bloque de texto fácilmente
reconocible combinado con digitos. Por supuesto, fijándolo así en la convención
no significaba que todo el mundo lo empezara a usar consistentemente de la manera
correcta. Hasta ahora, cuando un mail de commit viene con un log como este:
------------------------------------------------------------------------
r12908 | qsimon | 2005-02-02 14:15:06 -0600 (Wed, 02 Feb 2005) | 4 lines
Patch from J. Random Contributor <jrcontrib@gmail.com>
* trunk/contrib/client-side/psvn/psvn.el:
Fixed some typos from revision 12828.
------------------------------------------------------------------------
...parte de la revisión de este comit es decir "A partir de ahora, por favor
usa 'r12828', en vez de 'revision 12828' cuando te refieras a cambios del pasado."
Esto no es pedante; es importante tanto para el parseo automático como para los lectores
humanos.
Siguiendo los principios generales, de seguir métodos canonicos de referencia, y
que estos métodos de referencia debieran ser usados consistentemente en todos los sitios,
el proyecto en efecto exporta ciertos estándares. Estos estándares hacen que la gente escriba
herramientas que presenten las comunicaciones del proyecto de una manera más útil; por ejemplo,
una revisión formateada como "r12828" podría transformarse en un enlace vivo dentro del sistema
de navegación del repositorio. Esto sería muy difícil de realizar si la revisión se hubiera escrito
como "revision 12828", tanto porque la forma podría dividirse a través de un salto de línea, y porque
es menos distintiva (la palabra "revision", a menudo aparecerá sola, y los grupos de números también
apareceran solos, allí donde la combinación "r12828" puede significar únicamente un número de revisión).
Asuntos similares se aplican tambien a temas con números, FAQs (truco: utiliza una URL con un
named anchor, como se describe en
), etc.
Incluso para las entidades en las cuales no hay una manera obvia,
la forma canónica, se debería recomendar a la gente el proporcionar piezas
clave de información consistente. Por ejemplo, en lo que se refiere a un mensaje
de lista de correo, no facilites simplemente el destinatario y el asunto; facilita
tambien la URL del archivo y la cabecera Message-ID. Esto último permitirá
a la gente que tenga su propia copia de la lista de correo (la gente a veces copias offline, por
ejemplo para utilizarlas en el portátil mientras viajan) indentificar de manera inequivoca el
mensaje correcto incluso aunque no tengan acceso a los archivos. El destinatario y asunto tampoco
serían demasiado, porque la misma persona podría crear diversos posts en el mismo hilo, incluso
en el mismo día.
Cuanto más crece un proyecto, más importante es este tipo de consistencia. Consitencia signfica
que allá donde todo el mundo mire, verán que se siguen los mismos patrones, así que ellos tambíen
sabran seguir por ellos mismos los patrones. Esto también reduce el número de cuestiones que necesitarán
preguntar. La carga de tener un millon de lectores no es más grande que el tener sólo uno; los problemas
de escalabilidad empiezan a surgir solo cuando un cierto porcentage de estos lectores hacen preguntas.
Conforme el proyecto crece, por tanto, se debe reducir aquel porcentage incrementando la densidad y accesibilidad
de la información, de tal manera que una persona dada pueda encontrar la información que necesite sin
necesidad de preguntar.
Sin conversaciones en el bug tracker
En cualquier proyecto que haga un uso activo del Bug Tracker (sistema de seguimiento
de errores), siempre existe peligro de que este sistema se convierta en un foro de discusión
en sí mismo, incluso aunque las listas de correo sean mejor para ello.
Normalmente empieza de una manera demasiado inocente, alguien anota un tema con, digamos,
una propuesta de solución, o un parche parcial. Otro ve esto, y se da cuenta de que existen
problemas en esa solución, y añade otro punto anotando los problemas. La primera persona
entonces responde otra vez añadiéndolo al tema, y así sucesivamente...
El problema con esto es, primero que el bug tracker es un lugar bastante pesado
para tener una discusión, y segundo, que otras personas pueden no estar prestando atención,
después de todo, se espera que la discusión sobre desarrollo ocurra en la lista de correo
de desarrollo, por lo que será ahí donde buscarán. Puede que la gente no esté subscrita a
la lista de cambios de tickets despues de todo, y aunque lo estén, puede que no la sigan
muy de cerca.
Pero exactamente, ¿en que parte del proceso se cometió el error? ¿Fue cuando la persona
original envío su solución al tema?, ¿debería haberla enviado a la lista de correo mejor? ¿O quizá
fue cuando la segunda persona respondió al tema, en vez de a la lista?
No hay una respuesta correcta, pero hay un principio general:
sí simplemente vas a añadir un apunte, hazlo en el tracker, pero si vas
a empezar una conversacion, entonces hazlo en la lista de correo.
Puede que a veces no seas capaz de saber cual es el caso, simplemente usa el juicio.
Por ejemplo, cuando añadas un parche que contiene una solución potencialmente controvertida,
puedes anticiparte de que la gente tendrá preguntas sobre ella. Así que aunque normalmente
añadas el parche al ticket (asumiendo que no quieres o no puedas realizar el cambio directamente),
en este caso puedes elegir enviarlo a la lista de correo. En todo caso, eventualmente vendrá un punto
donde una parte o la otra indicarán sobre ir desde un simple añadido de datos a la conversación actual;
en el ejemplo que iniciaba esta sección, este sería el segundo que responde, quién dándose cuenta
de que había problemas con el parche, pudo predecir que iba a darse una conversación sobre ello, y de ahí
que debiera hacerse en el medio apropiado.
Para usar una analogía matemática, si la información parece que será rápidamente convergente, entonces
ponla directamente en el bug tracker; si parece que será divergente, entonces el mejor sitio serán una lista
de correo o el canal de IRC.
Esto no significa que nunca debe haber intercambios en el bug tracker. Preguntar sobre más
detalles de la reproducción del fallo al informador original tiende a ser un proceso altamente
convergente. Es poco probable que la respuesta de la persona genere nuevos tickets;
simplemente rellenará información que ya ha sido añadida. No hay necesidad de distrare a la lista
de correo con este proceso; esto significa que; tengas cuidado con una serie de comentarios en el
tracker. Así mismo, si estás demasiado seguro de que el bug ha sido reportado erróneamente (por ejem.,
no es un bug), entonces simplemente puedes decirlo correctamente en el ticket. Incluso apuntandolo
como un problema menor con una solución propuesta está bien, asumiendo que el problema no va a
ser un problema a toda la solución.
Por otra parte, si estás lanzando razones filosóficas sobre el alcance del
bug o el comportamiento apropiado del software, puedes estar seguro de que otros
desarrolladores querrán involucrarse. La discusión tenderá a discrepar por momentos
antes de convergir, así que mejor hacerlo en la lista de correo.
Cuando decidas hacerlo en la lista de correo, enlaza siempre al hilo
de la lista del correo con el ticket. Todavía será importante para alguien
que siga el ticket, ser capáz de alcanzar la discusión, aunque el ticket en si
mismo no esté en el foro de discusión. La persona que empieza el hilo puede
puede encontrar esto muy difícil, pero el open source es fundamentalmente una
cultura de responsabilidad de escribir: es mucho más importante hacer las cosas
fáciles para cientos de miles de personas que pueden leer el bug que para las
tres o cinco personas que pueden escribir sobre él.
Es correcto tomar conclusiones importantes o sumarios de la lista de discusión
y copiarlas en el ticket, si esto hace las cosas más faciles para los lectores. Un punto
común es empezar una lista de discusión, poner un enlace al hilo en el ticket, y entonces
cuando la discusión finalice, copiar el sumario final en el ticket (junto con un enlace al mensaje
conteniendo el sumario), de tal manera que alguien que navegue por este ticket pueda fácilmente
ver a que conclusiones se llegaron sin tener que hacer click en ningún otro sitio.
Date cuenta de que el problema usual de duplicación de datos "dos maestros" no tiene lugar
aquí, porque ambos archivos y comentarios de tickets son normalmente estáticos, datos intercambiables.
Publicidad
En el software libre, existe una continua barrera muy fina entre las
discusiones púramente internas y las declaraciones de relaciones públicas.
Esto es parcialmente así porque la audiencia objetivo no esta muy-definida: dado
que la mayoría o todos los posts son accesibles públicamente, el proyecto
no tiene control sobre la impresión que de él tiene la gente. Alguien; digamos, un
editor; puede arrastrar la atencion de millones de lectores'
a un post sobre el que nadie esperaba que fuera visto fuera del proyecto. Este es un hecho
real con el que todos los proyectos open source viven, pero en la práctica, el riesgo es
normalmente pequeño. En general, los anuncios que el proyecto más quiere publicitar serán
los que más se publicitarán, asumiendo que usas los mecanismos correctos para indicar
los valores más relativos al mundo exterior.
Para grandes comunicados, suele haber cuatro o cinco canales principales de distribución,
en cuales los anuncios deben ser hechos lo más simultáneamente posible.:
Probablemente la página principal de tu proyecto es la página más
vista de tu proyecto. Si tienes un gran comunicado, pon la propaganda ahí.
La propaganda debería ser un pequeño resumen que enlace a la noticia de
prensa (ver abajo) para más información.
Al mismo tiempo, debes tener una parte del sitio web denominada
"Noticias" o "Notas de prensa" donde los anuncios se describan en detalle.
Parte del propósito de las notas de prensa es proporcionar un simple objeto
de anuncio canónico al que otros sitios puedan enlazar, por lo que hay
que asegurarse que está correctamente estructurado: tanto con una nueva
página por release, como una entrada discreta de blog, o cualquier otro
tipo de entidad que pueda ser enlazada manteniéndose todavía a parte
de otras notas de prensa en la misma área.
Si tu proyecto tiene un feed RSS, asegúrate de que el anuncio tambíen
irá por él. Esto puede ocurrir automáticamente al crear la nota de prensa, dependiendo
de como está configurado tu sitio web.
(RSS es un mecanismo para distribuir sumarios de noticias
a través de meta-datos-enriquecidos a subscriptores, esto es, a gente que ha indicado
un interés en recibir esos sumarios. Mira
para más información sobre RSS.)
Si el anuncio va a ser sobre una nueva versión de el software,
entonces actualiza la entrada de tu proyecto en
(mira
sobre crear entradas en primer lugar).
Cada vez que actualices una entrada de Freshmeat, esta entrada irá a la lista
de cambios de Freshmeat del día. Esta lista de cambios se actualiza no sólo
en el propio Freshmeat, sino también en varios sitios de portales (incluyendo
) el cual es visto tempranamente por hordas
de gente. Freshmeat también ofrece la misma vía de datos a través de feed RSS,
de tal manera que la gente que no esté subscrita al RSS de tu proyecto todavía
puede ver el anuncio vía el RSS de Freshmeat.
Envía un mail a tú lista de correo de anuncios del proyecto.
Este nombre de lista actualmente debe ser algo como "anuncios", esto es,
announce@yourprojectdomain.org,
ya que es una convención muy estándar actualmente, y en la definición
de la lista debe indicarse claramente que se trata de una lista con un
tráfico muy bajo, reservada para anuncios internos del proyecto.
La mayoría de esos anuncios serán sobre nuevas releases de software, y
ocasionalmente de otros eventos, tales como fundraising drive, o sobre
descubrimientos de vulnerabilidades de seguridad (ver
)
después en este capítulo, también puede enviarse
un cambio de rumbo en la dirección del proyecto. Al tratarse de una
lista de tráfico bajo y usada sólo para cosas importantes, la
lista de anuncios tiene típicamente el mayor
número de subscriptores de cualquier lista de correo del proyecto
(por supuesto, esto significa que no deberías abusar de ella- consideralo
cuidadosamente antes de utilizarla). Para evitar que gente al azar
envíe anuncios, o lo que es peor, que llegue spam a través de ella,
la lista de anuncios debe ser siempre moderada.
Intenta realizar los anuncios en todos esos sitios al mismo tiempo
, tanto como sea posible. A la gente puede confundirle si ven un anuncio
en la lista de correo pero no lo ven reflejado en la página principal del
proyecto o en su área de anuncios de prensa. Si tienes los diversos cambios
(correos, ediciones de página web, etc.) encolados y preparados para enviarlos
de una vez, podrás mantener la ventana de inconsistencia al mínimo.
Para un evento poco importante, puedes prescindir de alguno
o todos los consejos de arriba. El evento todavía será conocido por
el mundo exterior en proporción directa a su importancia. Por ejemplo, cuando
una nueva liberación de software es un gran evento, marcar meramente la
fecha de la siguiente liberación también debe tenerse en cuenta, aunque
no sea tan importante como la liberación del software. Marcar la
fecha merece un correo a la lista de correo diario (no a la lista
de anuncios), y una actualización en la ruta del proyecto o del estado
en la página web, pero no más.
Sin embargo, todavía puedes ver que las fechas aparecen en
otros sitios de Internet, donde hay gente interesada en el proyecto.
La gente suele actuar como lurkers en tus listas de correo, simplmente
escuchando y sin decir nunca nada, no son necesariamente silenciosos
en otros sitios. El boca a boca da una amplia distribución; deberías
contar con ello, y construir incluso los anuncios menores de tal manera
para la transmisión informal exacta. Específicamente, posts, que
esperas que sean citados deberían tener una parte tiene-que-ser-citada,
así como tú escribiste el anuncio formal. Por ejemplo:
Simplemente una actualización de progreso: estamos
planeando liberar una versión 2.0 de Scanley a mediados de agosto de 2005.
Siempre puedes revisar
http://www.scanley.org/status.html en busca de actualizaciones. La principal
nueva característica será búsquedas con expresiones regulares.
Otras nuevas características incluyen: ... También
habrá varias correciones de bugs, incluyendo: ...
El primer párrafo es corto, da las dos piezas más importantes de información
(la fecha de liberación y las principales nuevas características),
y una URL para visitar en busca de más noticias. Sí este párrafo es la única
cosa que se muestra en la pantalla de alguien, todavía lo estas haciendo muy bien.
El resto del correo podría perderse sin afectar a la esencia del contenido.
Por supuesto, en ocasiones la gente enlazará al correo completo, pero a menudo,
citarán sólamente una parte. Dado que esto es una posibilidad, querrás poder
hacerlo fácil para ellos, y conseguir alguna influencia sobre lo que se
citará.
Anunciando Vulnerabilidades de Seguridad
Manejar una vulnerabilidad de seguridad es diferente del manejo
de cualquier otro tipo de reporte de error. En el software libre, hacer las
cosas de manera abierta y transparente es normalmente casi como un credo religioso.
Cada paso del proceso estándar de manejo de errores es visible a todo aquel
que le preocupe verlo: la llegada del informe inicial, la consiguiente discusión,
y la correción eventual.
Los errores de Seguridad son diferentes. Estos pueden comprometer datos
de usuarios, y posiblemente ordenadores completos de usuarios.
Para discutir tales problemas de manera abierta tiene que anunciarse
su existencia a todo el mundo—incluyendo a todas las partes que pueden
hacer un uso malicioso de la vulnerabilidad. Incluso realizando meramente el commit
de una solución se anuncia efectivamente la existencia de la vulnerabilidad (existen
atacantes potenciales que pueden buscar los logs de commits en proyectos públicos,
buscando sistemáticamente cambios que indiquen problemas de seguridad en el código
antes del cambio). La mayoría de proyectos open source han resuelto aproximadamente
de la misma manera estos conflictos entre el secretismo y la abertura,
basándose en estas guías básicas:
No hables sobre la vulnerabilidad de manera pública
hasta que una solución esté disponible; entonces proporciona la
solución al mismo tiempo exactamente que anuncias la vulnerabilidad.
Busca una solución tan rápido como puedas—
especialmente si alguien externo al proyecto informo de la vulnerabilidad,
porque sabes entonces que hay al menos una persona de fuera del proyecto
que es capaz de explotar esa vulnerabilidad.
En la práctica, estos principios nos llevan a una serie de
principios bastante estandarizados, los cuales se describen en la siguiente
sección.
Recibiendo el informe
Obviamente, un proyecto necesita la característica de que cualquiera pueda informar
sobre un error de seguridad. Pero la dirección regular para informar de errores
no será, porque también puede ser vista por cualquiera. Por ello, tendrá que
haber una lista de correo separada para recibir informes de errores de seguridad.
Esta lista de correo no debe tener los archivos de manera que se puedan leer
públicamente, y debe controlarse estrictamente a los subscriptores de la misma—
sólo los desarrolladores de confianza y que lleven tiempo en el proyecto, podrán
estar en la lista. Si necesitas una definición formal de "confianza", puedes
orientarte con "cualquiera que ha tenido acceso para realizar commits desde hace
dos años o más" o algo similar, para evitar favoritismos. Este es el grupo que
manejará los errores de seguridad.
Idealmente, la lista de seguridad no debería estar moderada o protegida
contra el spam, ya que no querremos que un informe importante pueda filtrarse o
se retrase simplemente porque los moderadores no estuvieron online aquel fin de semana.
Si usas software automática de protección de spam, intenta realizar una configuración
con características de gran tolerancia; es mejor dejar pasar unos cuantos correos spam
que perder un informe. Para que la lista sea efectiva, por supuesto que debes informar
de su dirección; pero dado que no estará moderada, y en gran parte, ligeramente protegida
de spam, intenta no publicar su dirección sin algun tipo de transformación y ocultación
de la dirección, tal y como se describe en
en
.
Afortunadamente, el ocultar la dirección de correo no significa que ésta sea
ilegible; echa un vistazo a
, y mira
el código HTML de esta página, para ver un ejemplo.
Desarrolla la solución silenciosamente
¿Qué hace la lista de seguridad cuando recibe un informe?
La primera tarea es evaluar la urgencia y severidad del problema.
:
¿Cómo de seria es la vulnerabilidad? Permite que un
atacante malicioso tome la computadora de alguien que utiliza
tu sofware? o únicamente hay una fuga de información sobre el
tamaño de algounos de sus archivos?
¿Cómo de fácil es explotar la vulnerabilidad? Se puede
realizar el ataque con scripts, o hacerlo requiere un conocimiento
circunstancial, suposiciones y suerte?
¿Quién te informó del problema?
La respuesta a esta pregunta, por supuesto que no cambia
la naturaleza de la vulnerabilidad, pero te da una idea de
cómo otras personas pueden conocerla. Si el informe viene de
uno de los desarrolladores del propio proyecto, puedes respirar
algo tranquilo (pero sólo un poco), porque puedes confiar en
que ellos no se lo dirán a nadie más. Por otra parte, si viene
de una dirección de correo como anonymous14@globalhackerz.net,
entonces lo mejor será que actúes tan rápido como puedas. Después de todo
la persona te hizo un favor informando del problema, pero no tienes idea
de a cuanta gente más se lo ha contado, o cuanto tiempo esperará antes
de explotar la vulnerabilidad en instalaciones en producción.
Nota que la diferencia que estamos hablando aquí es un rango estrecho
entre urgente y extremadamente urgente.
Incluso cuando el informe viene de una fuente conocida, puede haber otra gente en
la red que descubrieron el bug hace tiempo y no han informado de ello. La única vez
que las cosas no son urgentes es cuando el bug inherentemente no compromente la seguridad
muy severamente.
El ejemplo de "anonymous14@globalhackerz.net" por
cierto, no es burlón. Realmente puedes obtener informes de gente con
identidades-encubiertas que, por sus palabras y comportamiento, nunca
clarifican si estan de tu parte o no. No importa: si te han informado de el
agujero de seguridad, ellos sienten que te han hecho un buen favor, y
tú deberías responderles de la misma manera. Agredeciéndoles el informe,
facilitándoles una fecha antes de la cual planeas liberar un parche público,
y mantenlo al tanto. Algunas veces ellos pueden darte una fecha—que
es, una amenaza implícita de publicar el bug en una fecha dada, si estás preparado o no.
Esto puede parecer un juego de poder de intimidación, pero es más una acción
preferente resultado de decepciones anteriores con productores de software
que no respondían y no se tomaban los informes de seguridad en serio.
This may feel like a bullying power play, but it's more likely a
preëmptive action resulting from past disappointment with
unresponsive software producers who didn't take security reports
seriously enough. De todas maneras, no puedes permitirte ignorar a esta persona.
Después de todo, si el bug es severo, el tiene conocimiento que podría causar grandes
problemas a tus usuarios. Trata a estos informadores bien, y espera que ellos tambien
te traten bien a tí.
Otro informador frecuente de agujeros de seguridad es el profesional de la
seguridad, alguien que audita código cómo parte de su trabajo y se mantiene al día
con las últimas noticias en las vulnerabilidades de software. Esta gente normalmente
tiene experiencia en ambos lados de la vallya—ellos tanto han recibido
como enviado informes, probablemente más que la mayoría los desarrolladores de tu
proyecto tengan. Ellos normalmente también te darán una fecha fija para solucionar
la vulnerabilidad antes de hacerla pública. Esta fecha puede ser negociable, pero
esto dependerá del informador; las fechas fijadas han sido reconocidas entre los
profesionales de la seguridad como la única vía fiable para que las organizaciones
solucionen los problemas de seguridad puntualmente. Por lo que no trates la fecha
fijada como algo grosero; es una larga tradición, y hay buenas razones para ello.
Una vez que conozcas la severidad y urgencia, puedes empezar a trabajar en la
solución. A veces hay un sacrificio entre hacer una solución elegante y hacerla rápida;
por esto, debeis acordar la urgencia antes de empezar. Manten la discusión de la solución
restringida únicamente a los miembros de la lista, por supuesto también al informador
original (si el quiere estar involucrado) y con cualquier desarrollador que se necesite
contactar por razones técnicas.
No hagas el commit de la solución en el repositorio. Mantelo en forma de parche
hasta la fecha de ir al público. Si fueras a hacer el commit, incluso con un
mensaje de log aparentemente inocnete, alguién puede darse cuenta y comprender
el cambio. Nunca sabes quién está observando tu repositorio y porque estos pueden
estar interesados. Deshabilitar los correos del commit no ayudará; primero de todo,
el intervalo en la secuencia del mail del commit resultaría sospechoso, y de cualquier
manera, los datos todavía estarían disponibles en el repositorio. Simplmente haz todo
el desarrollo en un parche y mantén el parche en algún lugar privado, quizás un repositorio
privado y separado que sólo lo conozca la gente que está al tanto del bug. (Si usas un
sistema de control de versiones descentralizado tal como Arch o SVK, puedes hacer el trabajo
bajo el control de versión completo, y mantener simplemente el repositorio inaccesible a
los desconocidos.)
Números CAN/CVE
Puedes haber visto un número CAN o
un número CVE asociados con problemas de seguridad.
Estos números son del tipo "CAN-2004-0397" o
"CVE-2002-0092", por ejemplo.
Ambos tipos de números representan el mismo tipo de entidad: una
entrada en la lista de "Exposiciones y Vulnerabilidades Comunes" mantenida
en . El propósito de esta lista
es proporcionar nombres estandarizados para todos los problemas de seguridad
conocidos, de tal forma que todo el mundo tenga un único, nombre canónico
que usar cuando se discuta una, y un sitio central para encontrar más información.
La única diferencia entre número "CAN" y número "CVE" es que el primero representa
una entrada candidata, pero todavía no aprobada para incluirse en la lista oficial
de la junta editorial CVE, y el último representa una entrada aprobada. Sin embargo,
ambos tipos de entradas son visibles al público, y un número de entrada no cambia cuando
es aprobado—el prefijo "CAN" es reemplazado simplmente con "CVE".
Una entrada CAN/CVE no contiene en sí misma una descripción completa del bug
y como protegerse contra el. En lugar de eso, contiene un breve sumario, y una lista
de referencias a recursos externos (tal como archivos de listas de correo) donde la
gente puede ir para conseguir información más detallada. El propósito real de
es proporcionar un espacio bien organizado
en el cual cada vulnerabilidad pueda tener un nombre y una ruta clara a más datos.
Mira
cómo un ejemplo de una entrada. Observa que las referencias pueden ser muy secas,
con fuentes apareciendo como abreviaciones crípticas. Note that the references can be very
terse, with sources appearing as cryptic abbreviations. Una clave a estas abreviaciones
está en .
Si tu vulnerabilidad cumple los criterios de CVE, puedes adquirir un número
CAN. El proceso para hacer esto es deliberadamente por ingreso: básicamente
tienes que conocer a alguien, o conocer a alguien que conozca a alguien. Esto no es
tan disparatado como pueda sonar. Con el fin de evitar que la Junta Editorial de CVE
este abrumada con falsos o envíos pobremente escritos, reciben los envíos sólo de
fuentes de las que ya confían. Con el fin de conseguir listar tu vulnerabilidad
, por lo tanto, necesitas encontrar un camino de conocimiento de tu proyecto
al Consejo Editorial de CVE. Pregunta entre tus desarrolladores; alguno de ellos
probablemente conocerá a alguien que haya realizado previamente el proceso de
CAN, o conoce a alguien que lo ha hecho, etc. La ventaja de hacerlo de esta
manera es tambien que en algún lugar a través de la cadena, alguien puede
saber lo suficiente para decirte que a) no contará como una vulnerabilidad o exposición
de acuerdo a los criterios de MITRE, por lo que no es necesario enviarlo, o b) la vulnerabilidad
ya tiene un número CAN o. Lo último puede ocurrir si el bug ya ha sido
publicado en otra lista de avisos de seguridad, por ejemplo en
o en la lista de correo BugTraq en .
(Si esto ha ocurrido y tu proyecto no se ha enterado, entonces deberías preocuparte por
quien más puede saber algo que todavía no sabes.)
Si después de todo consigues un número CAN/CVE, normalmente querrás conseguirlo
en la primera etapa de la investigación del bug, para que todas las comunicaciones
consiguientes puedan referirse con ese número. Las entradas CAN están embargadas
hasta la fecha de publicación; la entrada existirá como una reserva vacía (para
que no pierdas el nombre), pero no revelará ninguna información sobre la vulnerabilidad
hasta la fecha en la cual anunciarás el bug y la solución.
Más información sobre el proceso CAN/CVE puede encontrase en
, y una
exposición particularmente clara de el uso de los números CAN/CVE de un
proyecto open source en
.
Pre-notificacion
Una vez que tu equipo de respuesta a seguridad (este es, aquellos desarrolladores que
están en la lista de correo de seguridad, o quien ha estado involucrado con
un informe particular) tienen un arreglo listo, necesitas decidir como distribuirlo.
Si simplemente realizas un commit con el arreglo en tu repositorio, o de
lo contrario lo anuncias al mundo, efectivamente estarás forzando a todo el mundo
que use tu software a actualizarse inmediatamente o estarán en riesgo de ser hackeados.
A veces es apropiado, por lo tanto, hacer pre-notificaciones
para ciertos usuarios importantes. Esto es particularmente cierto con software cliente/servidor
, donde puede haber servidores bien conocidos que serán objetivos tentadores para
atacantes. Los administradores de estos servidores apreciarán el tener un día
o dos extra para realizar la actualización, de tal manera que ya estén
protegidos una vez que el exploit sea de conocimiento público.
La Pre-notificación simplemente significa enviar correos a
esos administradores antes de la fecha de publicación, avisándoles de
la vulnerabilidad y de cómo solucionarla. Deberías enviar pre-notificaciones
sólo a gente en la que confíes que serán discretos con la información. Esto
es, la cualificación para recibir pre-notificaciones es doble: el destinatario
debe administrar un gran e importante servidor donde un compromiso sería un
asunto serio, y el emisor debe saber que no cotorreará
sobre el problema de seguridad antes de la fecha de publicación.
Envía cada correo de pre-notificación individualmente (de uno en uno) a
cada receptor. No envíes a la lista completa de receptores
de una vez, porque podrán verse los nombres de cada uno; lo que significa que
esencialmente estás alertando a cada receptor con el hecho de que cada uno de
los otros receptores pueden tener un agujero de seguridad
en su servidor. Enviarselo a todos vía CC ciegas (BCC) tampoco es una buena
solución, porque algunos administradores protegen sus bandejas con filtros de
spam tanto bloquean como reducen la prioridad de los correos con BCC, ya que
mucho spam es enviado vía BCC actualmente.
Este es un correo de ejemplo de pre-notificación:
De: Tú nombre aquí
A: admin@large-famous-server.com
Responder-A: Tú nombre aquí (no la dirección de la lista de seguridad)
Asunto: Notificación confidencial de vulnerabilidad Scanley.
Este correo es una pre-notificación confidencial de una alerta de seguridad
en el servidor Scanley.
Por favor *no reenvíes* ninguna parte de este correo a nadie. El anuncio
público no se hará hasta el 19 de Mayo, y nos gustaría mantener la información
en secreto hasta entonces.
Estas recibiendo este correo porque (pensamos) que administras un servidor Scanley,
y quierrías tenerlo parcheado antes de que este agujero de seguridad sea público el 19 de Mayo.
Referencias:
===========
CAN-2004-1771: Desbordamiento de pila en consultas de Scanley
Vulnerabilidad:
==============
Se puede conseguir que el servidor ejecute comandos arbitrarios
si la configuración local esta mal configurada y el cliente envía
una consulta malformada.
Severidad:
=========
Muy severa, puede involucrar la ejecución de código arbitrario en el servidor.
Solución alternativa:
============
Configurando la opción 'natural-language-processing' a 'off' en
scanley.conf cierra esta vulnerabilidad.
Parche:
======
El parche de abajo se aplica a Scanley 3.0, 3.1, y 3.2.
Una nueva distribución pública (Scanley 3.2.1) se hará el 19 de Mayo o un poco antes,
de tal manera que esté disponible al mismo tiempo que esta vulnerabilidad se haga pública.
La única diferencia entre 3.2 y 3.2.1 será este parche.
[...el parche viene aquí...]
Si tienes un número CAN, inclúyelo en la pre-notificación (cómo
se muestra arriba), incluso aunque la información esté todavía oculta y de ahí
que la página de MITRE no mostrará nada. Incluyendo el número CAN permite al
receptor conocer con certeza que el bug con el que han sido pre-notificados es
el mismo que luego oirán hablar en los canales públicos, por lo que no tendrán que
preocuparse si es necesario realizar alguna acción, qué es precisamente el objetivo
de los números CAN/CVE.
Distribuyendo la solución públicamente
El último paso en el manejo de un bug de seguridad es distribuir la solución
públicamente. En un único y comprensivo anuncio, deberías describir el problema,
dar los números CAN/CVE si los tiene, describir alguna solución temporal, y cómo
solucionarlo permanentemente. Normalmente "fix" significa actualizar a una
nueva versión del software, aunque algunas veces puede significar aplicar un parche,
particularmente si el software normalmente es ejecutado desde las fuentes.
Si creas una nueva versión disponible, debe diferenciarse de las versiones existentes
en únicamente el parche de seguridad. De esta manera, admins conservadores podrán actualizar
sin preocuparse sobre a que más puede afectarle; tampoco tendrán que preocuparse de futuras
actualizaciones, porque la solución del fallo de seguridad vendrá integrado en todas las
futuras versiones (Detalles de procedimientos de liberación de versiones discutidos en
en
.)
Al margen de que la solución pública al bug de seguridad conlleve una
nueva versión, haz el anuncio con aproximadamente con la misma prioridad con
la que harías una nueva liberación de versión: envía un mail a la lista de
anuncios del proyecto, crea una nueva nota de prensa de la
liberación, actualiza la entreada de Freshmeat, etc.
Mientras tú nunca deberías restar importancia a la existencia de un bug
de seguridad por asuntos de la reputación del proyecto, ciertamente puedes
definir un tono de la importancia del anuncio de seguridad que coincida
con la severidad actual del problema. Si el agujero de seguridad es simplemente
una exposición de información menor, y no existe un exploit que permita tomar
un control total de la computadora del usuario, entonces no puede justificar
mucha preocupación. Puedes incluso decidir el no distraer a la lista de
anuncios con él. Después de todo, si el proyecto empieza
con este tipo de anuncios cada cierto tiempo, los usuarios pueden empezar a
pensar que el software es menos seguro de lo que actualmente es, y también
pueden dejar de creerte cuando exista un problema realmente grave que deba
anunciarse. Mira
cómo una buena
introducción al problema de judgar la severidad.
En general, si no estás seguro en como tratar un problema de seguridad, encuentra
a alguien con experiencia y habla con él sobre ello. Evaluar y manejar vulnerabilidades
es en gran parte una destreza adquirida, y es fácil cometer fallos las primeras veces.