Infraestructura Técnica
Los proyectos de software libre dependen de tecnologías
que aportan la captura selectiva e integración de la información.
Mientras mejor se sean usadas estas tecnologías y se persuada a otros
para utilizarlas, mayor será el éxito del proyecto.
Esto se vuelve más
cierto mientras el proyecto crece. Un buen manejo de la información es
lo que previene a un proyecto open source de colapsar bajo el peso
de la Ley de Brook,De su libroEl mes mítico
del hombre, 1975. Más en en.wikipedia.org/wiki/The_Mythical_Man-Month, en.wikipedia.org/wiki/Brooks_Law, y
en.wikipedia.org/wiki/Fred_Brooks.
la cual afirma que asignar fuerza de trabajo adicional a un proyecto
retrasado lo demorará aún más. Fred Brooks observó que la complejidad
de las comunicaciones en un proyecto se incrementa alcuadradodel
número de participantes. Cuando solo unas pocas personas están
involucradas, todos pueden hablar entre todos fácilmente, pero cuando
cientos de personas están involucradas, ya no es posible que cada uno
de los individuos se mantengan constantemente al tanto de lo que todos
los demás están haciendo. Si dirigir bien un proyecto de software libre
se trata de hacer que todos se sientan como si estuviesen trabajando
juntos en la misma habitación, es obvio preguntar: ¿Qué sucedería si
todas las personas en una habitación atestada de gente hablase a la vez?
Este problema no es nuevo. En una habitación no metafórica
atestada, la solución es un procedimiento parlamentario
: guías formales acerca de cómo tener discusiones en tiempo
real en grupos grandes, cómo asegurarse de que las disensiones más
importantes no se pierdan entre comentarios irrelevantes, cómo formar
subcomites, cómo reconocer y registrar cuando se toman decisiones, etc. Las partes
más importantes en un procedimiento parlamentario especifican como
deben interactuar los grupos con su sistema de manejo de información.
Algunos comentarios se hacen para el registro, otros no. El registro
mismo es sujeto a manipulación directa y se entiende que no es una
transcripción literal de lo que ha ocurrido, sino que es una
representación a lo que el grupo está dispuesto a acordar
sobre lo sucedido. El registro no es monolítico, sino
que toma diferentes formas para diferentes propósitos. Comprende los
minutos de encuentros individuales, una colección completa de todos
los minutos de todos los encuentros, sumarios, agendas y sus
anotaciones, reportes de comités, reportes de corresponsales no
presentes, listas de acción, etc.
Dado que Internet no es realmente una habitación, no debemos
preocuparnos acerca de replicar aquellas partes de los procesos
parlamentarios que mantiene a algunas personas calladas mientras
las demás hablan. Pero cuando nos referimos a técnicas de manejo de
la información, proyectos open source bien dirigidos son como
procesos parlamentarios en esteroides. Ya que todas las comunicaciones
en los proyectos open source suceden por escrito, sistemas muy
elaborados han evolucionado para enrutar y etiquetar apropiadamente
los datos, para minimizar las repeticiones de forma que se eviten
divergencias espuriosas, para almacenar y buscar los datos, para
corregir información incorrecta u obsoleta y para
asociar bits dispares de información con cada uno mientras que nuevas
conexiones son observadas. Los participantes activos en los proyectos
open source integran muchas de estas técnicas y a menudo realizaran
complejas labores manuales para asegurar que la información sea dirigida
correctamente. Pero todo el esfuerzo depende al final de un sofisticado
soporte informático. Tanto que sea posible, los mismos medios
de comunicación deben realizar éste enrutamiento, etiquetado y
registro y debería mantener la información al alcance de los humanos
de la manera más conveniente posible. En la práctica, por supuesto,
los humanos siguen necesitando intervenir en muchos puntos durante
el proceso y también es importante que estos programas hagan ésta intervención
lo más conveniente. Pero por lo general, si los humanos se encargan de
etiquetar y enrutar información acertadamente desde su primera entrada
en el sistema, entonces el software debería estar configurado para dar
el máximo uso posible a esa metadata.
El consejo de éste capítulo es intensamente práctico, basado en
las experiencias con aplicaciones y patrones específicos. Pero el objetivo
no es sólo enseñar una colección particular de técnicas. Es también
demostrar, utilizando pequeños ejemplos, la actitud general que mejor
fomentará el correcto uso de los sistemas de manejo de información
en el proyecto. Esta actitud incluye una combinación de habilidades
técnicas y don de gentes. Las habilidades técnicas son esenciales
porque las aplicaciones de manejo de información siempre requieren
cierta configuración y además una cierta cantidad de mantenimiento
y puesta apunto mientras nuevas necesidades vayan surgiendo (por ejemplo,
mirad la discusión de como manejar el crecimiento del proyecto en
más adelante
en éste capítulo). El don de gentes es necesario porque la
comunidad humana también requiere de cierto mantenimiento: no siempre
es inmediatamente obvio como utilizar estas herramientas para obtener
una ventaja completa y en algunos casos los proyectos tienen convenciones
conflictivas (por ejemplo, la discusión de como crear cabeceras
Reply-to en los mensajes salientes de las
lista de correos, en ).
Todos los involucrados en el proyecto van a necesitar ser animados,
en el momento correcto de la forma correcta, para que sigan manteniendo
la información del proyecto bien organizada. Mientras más involucrado
esté el contribuyente, más complejas y especializadas serán las técnicas
que se esperará que aprendan.
El manejo de información no tiene soluciones rápidas ya que existen
demasiadas variables. Pueden que finalmente se tenga todo configurado
justo como se desea y tener a la mayoría de la comunidad participando
pero luego el crecimiento del proyecto hace de estas practicas no escalables.
El puede que el crecimiento del proyecto se estabilice y que la comunidad
de usuarios y desarrolladores acuerden una relación confortable con
la infraestructura técnica pero llega alguien e inventa un nuevo servicio
de manejo de información completo y pronto muchos de los recién llegados
empezarán a preguntar que por qué no es utilizado en el proyecto—
por ejemplo, esto sucedió en muchos proyectos de software
libre anteriores a la invención del Wiki (más en
en.wikipedia.org/wiki/Wiki) y más recientemente ha estado pasando
en proyectos cuyos flujos de trabajo fueron desarrollados antes de la
aparición de los pull-requests de GitHub (ver )
como la forma canónica de empaquetar las contribuciones propuestas.
Muchas cuestiones de la infraestructura son
materia de juicio, incluyendo las desventajas entre la conveniencia de
aquellos generando información y la conveniencia de aquellos quienes la
consumen o entre el tiempo requerido para configurar el software de
manejo de la información y los beneficios que le brinda al proyecto.
Cuidado con la tentación de automatizar demasiado, esto es,
automatizar cosas que realmente requieren de atención por parte de los
humanos. La infraestructura técnica es importante, pero lo que hace que
los proyectos de software libre funcionen es el cuidado—y la
expresión inteligente de éste cuidado—de los humanos involucrados.
Principalmente, la infraestructura técnica está para ofrecer medios
fáciles para aplicar dichos cuidados.
Lo que necesita un proyecto
La mayoría de los proyectos open source ofrecen al menos un mínimo
y estándar conjunto de herramientas para manejar información:
Sitio Web
Principalmente, conducto de información centralizado
en un sentido del proyecto para el público. El sitio
web puede también servir como una interfaz para
otras herramientas del proyecto.
Listas de Correo / Foros de Mensajes
Usualmente es el foro de comunicación más activo
del proyecto, y el "medio de registro."
Control de Versiones
Permite a los desarrolladores realizar cambios al código
convenientemente, incluso retroceder y exportar cambios.
Le permite a todos mirar lo que está sucediendo con el
código.
Gestión de fallos
Permite a los desarrolladores mantener un registro de en qué
están trabajando, coordinandose entre ellos y planear
lanzamientos. Permite que todo el mundo pueda realizar
búsquedas acerca del estado de los fallos y registrar
información (p.e. recetas reproducibles) acerca de fallos
en particular. Puede ser utilizado para seguir no solo
fallos, sino también lanzamientos, tareas,
nuevas características,etc.
Chat en tiempo real
Un sitio para discusiones rápidas, sencillas e
intercambios de preguntas/respuestas. No siempre
se archiva completamente.
Cada una de estas herramientas está dirigida a distintas necesidades,
pero sus funciones están también interrelacionadas y se debe hacer que
estas herramientas trabajen en conjunto. Más abajo examinaremos como podemos
lograr esto y más importante aun como hacer que las personas se acostumbren
a usarlas.
Se pueden evitar muchos dolores de cabeza por escoger y configurar
muchas de estas herramientas si en su lugar utilizamos un hosting enlatado
: un servicio en línea que ofrece servicios preempacados y con plantillas
de algunas o todas las herramientas de colaboración necesarias para
llevar a cabo un proyecto de software libre. Más en
a continuación en éste mismo capítulo para una discusión más
profunda acerca de las ventajas y desventajas de estas soluciones.
Sitio Web
possv2 24 March 2013: If you're reading this note, then
you've encountered this chapter while it's undergoing substantial
revision; see producingoss.com/v2.html for details.
Para nuestros propósitos, el sitio web
significa las páginas web dedicadas a ayudar a la gente a participar
en el proyecto como desarrolladores, documentadores, etc. Tenga en
cuenta que esto es diferente de la página web principal de cara al
usuario. En muchos proyectos, los usuarios tienen necesidades
diferentes y, a menudo (estadísticamente hablando) una mentalidad
diferente de los desarrolladores. Los tipos de páginas web más
útiles para los usuarios no son necesariamente las mismas que son
útiles para los desarrolladores — no trate de hacer
una sitio web de "talla única" sólo para ahorrar un poco de esfuerzo
de escritura y mantenimiento: terminará con un sitio que no
está del todo bien, para cualquiera de las audiencias.
Los dos tipos de sitios deben enlazados entre sí, por supuesto,
y, en particular, es importante que el sitio orientado al usuario tenga,
colocado de alguna manera en una esquina del agún lugar, una clara
enlace con el sitio de los desarrolladores, ya que la mayoría de los
nuevos desarrolladores darán sus primeros pasos en las páginas de
usuario y buscarán un camino desde allí hacia la zona de los
desarrolladores.
Un ejemplo puede aclarar esto. Al escribir estas líneas, en
noviembre de 2013, la suite ofimática LibreOffice tiene su principal
sitio web orientado al usuario en libreoffice.org, como era de
esperar. Si usted fuera un usuario que quiere descargar e instalar
LibreOffice, usted comenzaría allí, iría directamente al enlace
"Descargar", y así sucesivamente. Pero si usted fuera un desarrollador
que busca (por ejemplo) corregir un error en LibreOffice, puede
empezar en libreoffice.org, pero
estaría buscando un enlace que diga algo así como "Desarrolladores",
o "Desarrollo", o "Involúcrate" — en otras palabras,
estaría buscando la puerta de entrada a la zona de desarrollo.
En el caso de LibreOffice, al igual que algunos otros grandes
proyectos, en realidad tienen un par de diferentes pasarelas. Hay un
enlace que dice "Involúcrate",
y otro que dice "Desarrolladores".
La página "Involúcrate" está dirigida a la más amplia gama de
potenciales contribuyentes: desarrolladores, sí, pero también
documentadores, los probadores de garantía de calidad,
voluntarios de marketing, voluntarios de infraestructura web,
financistas o alguna especie de donantes, diseñadores de interfaz,
voluntarios para el foro de soporte, etc. Esto libera la página
"Desarrolladores" para dirigirse a un público más bien estrecho de los
programadores que deseen participar en la mejora del código de
LibreOffice. El conjunto de enlaces y breves descripciones
proporcionadas en ambas páginas es admirablemente claro y conciso: se
puede saber de inmediato al mirar si usted está en el lugar correcto
para lo que quiere hacer, y de esa manera, saber cuál es el siguiente
lugar en que debe hacer clic. La página de "Desarrollo" da un poco de
información acerca de dónde encontrar el código, cómo comunicarse con
los otros desarrolladores, cómo presentar errores, y cosas por el
estilo, pero, lo más importante, apunta a lo que los más experimentados
colaboradores de código abierto reconocerían al instante como la
verdadera puerta de acceso a la información
activamente mantenida sobre desarrollo: el wiki de desarrollo en wiki.documentfoundation.org/Development.
Esta división en dos pasarelas para los contribuidores, una para
todo tipo de contribuciones y otra espacíficamente para los codificadores,
es probable que tenga sentido para un proyecto grande y multifacético
como LibreOffice. Tendrá que usar su juicio para determinar si ese
tipo de subdivisión es apropiado para su proyecto; al menos al
principio, probablemente no lo es. Es mejor empezar con una pasarela
unificada para los colaboradores, dirigida a todos los tipos de
contribuyentes que se pueden esperar, y si esa página nunca es lo
suficientemente grande o lo suficientemente compleja como para sentir
que es difícil de manejar — escucha con atención las
quejas al respecto, ya que usted y otros participantes desde hace mucho
tiempo estarán insensibilizados naturalmente a las debilidades de las
páginas introductorias — entonces usted puede dividirla
siempre y cuando parezca lo mejor.
Desde un punto de vista técnico no hay mucho que decir acerca de
la creación de la página web del proyecto. La configuración de un
servidor web y la creación de páginas web son tareas bastante simples,
y la mayoría de las cosas importantes que decir sobre el diseño y la
disposición fueron cubiertas en el capítulo anterior. La función
principal del sitio web es presentar una visión general clara y
acogedora del proyecto, y unir las otras herramientas (sistema de
control de versiones, seguimiento de errores, etc.). Si usted no tiene
los conocimientos necesarios para configurar un servidor web por ti
mismo, por lo general no es difícil encontrar a alguien que lo haga y
esté dispuesto a ayudar. Sin embargo, para ahorrar tiempo y esfuerzo,
las personas a menudo prefieren usar uno de los sitios de hospedaje
enlatados.
Hosting Enlatado
Un sitio de hosting enlatado (hospedaje
enlatado) es un servicio online que ofrece algunas o todas las
herramientas de colaboración en línea necesarias para ejecutar un
proyecto de software libre. Como mínimo, un sitio de hospedaje enlatado
ofrece repositorios públicos de control de versiones y de seguimiento
de fallos; La mayoría ofrecen también espacio de wiki, muchos ofrecen
también hospedaje a la lista de correo, y algunos ofrecen pruebas de
integración continua y otros servicios.
Hay dos ventajas principales de utilizar un sitio de hospedaje
enlatado. La primera es la capacidad de los servidores y ancho de
banda: sus servidores son cajas fornidas sentadas en tuberías realmente
grandes. No importa que tan exitoso se vuelva su proyecto, usted no va
a quedarse sin espacio en disco o a inundar la conexión de red. La
segunda ventaja es la simplicidad. Ellos ya han elegido un gestor de
fallos, un sistema de control de versiones, tal vez el software del
foro de discusión, y todo lo que necesita para ejecutar un proyecto.
Ya han configurado las herramientas, han dispuesto de una autenticación
con un único inicio de sesión donde sea posible, se hace cargo de las
copias de seguridad de todos los datos almacenados en las herramientas,
etc. No es necesario tomar muchas decisiones. Todo lo que tienes que
hacer es llenar un formulario de registro, pulse un botón y de pronto
usted tiene un sitio web de desarrollo de proyectos.
Estos son beneficios muy significativos. La desventaja, por
supuesto, es que usted debe aceptar sus opciones
y configuraciones, aunque sea mejor algo diferente para su proyecto.
Por lo general, los sitios se pueden ajustar bajo ciertos parámetros
estrechos, pero nunca se tiene el control de grano fino que usted
tendría si usted configura el sitio usted mismo y tiene acceso
administrativo completo al servidor.
Un ejemplo perfecto de esto es el manejo de los archivos
generados. Algunas páginas web del proyecto pueden ser archivos
generarados—por ejemplo, existen sistemas para mantener los
datos del FAQ en un formato maestro fácil de editar, a partir del
cual el HTML, PDF y otros formatos de presentación se pueden
generar. Como se explica en
anteriormente en este capítulo, a usted no le gustaría
versionar los formatos generados, sólo el archivo maestro. Pero
cuando su sitio web está alojado en el servidor de otra persona,
puede ser difícil de preparar un hook (gancho) personalizado para
regenerar la versión HTML en línea de la FAQ cada vez que se
cambie el archivo maestro.
Si usted elige un sitio de hospedaje, deje abierta la opción de
cambiar a un sitio diferente en el futuro, mediante el uso de un nombre
de dominio personalizado como domicilio del desarrollo del proyecto.
Usted puede redireccionar esa URL al sitio enlatado, o tener una página
de inicio de desarrollo totalmente personalizada en la URL principal y
enlazarla al sitio enlatado para funcionalidades específicas.
Simplemente tratar de arreglar las cosas de tal manera que si más
adelante decide utilizar una solución de alojamiento diferente, la
dirección principal del proyecto no tiene por qué cambiar.
Y si usted no está seguro de si se debe usar un hosting
enlatado, entonces probablemente debería utilizarlo. Estos sitios han
integrado sus servicios en miles de formas (Sólo un ejemplo: si un
commit menciona un número de ticket de fallo usando un formato
determinado, entonces la gente navegando ese commit más tarde se
encontrará con que se vincula automáticamente a ese ticket), cosa que
sería laboriosa para usted reproducir, sobre todo si es la primera
vez que lleva a cabo un proyecto de código abierto. El universo de
posibles configuraciones de las herramientas de colaboración es vasto
y complejo, pero el mismo conjunto de opciones ha enfrentado todo el
mundo corriendo un proyecto de código abierto y hay algunas soluciones
asentadas ahora. Cada uno de los sitios de hospedaje implementa un
subconjunto razonable de ese espacio de soluciones, y al menos que
tenga razones para creer que puedes hacerlo mejor, el proyecto
funcionará probablemente mejor usando uno de esos sitios.
Selección de un sitio de hosting enlatado
En la actualidad hay tantos sitios que proporcionan hosting
enlatados libre de cargos para proyectos liberados bajo licencias de
código abierto que no hay espacio aquí para revisarlos todos.
Así que voy a hacerlo fácil: elige GitHub. Es, por mucho, el más popular y
parece decidido a permanecer de esa manera, o incluso crecer en su
predominio, por varios años en adelante. Tiene un buen conjunto de
características e integraciones. Muchos desarrolladores ya están
familiarizados con GitHub y tienen una cuenta allí. Tiene una API para una interacción
mediante programación con los recursos del proyecto, y si bien no
ofrece actualmente las listas de correo, hay un montón de otros
lugares que pueden hospedarlas, como los Grupos de Google.
Si usted no se convence por GitHub (por ejemplo, porque el
proyecto utiliza, por decir, Mercurial en lugar de Git), pero no
está seguro de dónde alojar, eche un vistazo minucioso a Comparación de los servicios de alojamiento para software de código
abierto; que es el primer lugar para buscar, hasta a la fecha,
la información completa sobre las opciones de alojamiento de proyectos
de código abierto. Actualmente los otros dos sitios de alojamiento más
populares son Google Code
Hosting, SourceForge, pero consulte la
página de Wikipedia antes de tomar una decisión.
Alojamiento en una infraestructura completamente de código
abierto
Aunque todos los sitios de hospedaje usan un montón de software
libre, la mayoría de ellos también escribieron su propio software
para unir todo, lo que significa que el medio ambiente de alojamiento
no es fácilmente reproducible por otros. Por ejemplo, mientras que la
propia Git es un software libre, GitHub es un servicio alojado
corriendo en parte con el software propietario — si
deja GitHub, no se la puede llevar con usted, por lo menos no
toda.
Algunos proyectos prefieren un sitio de hospedaje que se
ejecute en una infraestructura de software totalmente libre y que
podría, en teoría, ser reproducida de forma independiente de llegar a
ser necesario. Afortunadamente, existen tales sitios, el más conocido
es Gitorious, GNU Savannah, y GitLab (para la fecha de este escrito
a principios de 2014). Por otra parte, cualquier servicio que ofrezca
hospedaje para plataformas de colaboración de código como Redmine o Trac ofrece efectivamente
alojamiento que preserva plenamente la libertad, ya que estas
plataformas incluyen la mayoría de las características que se
necesitan para ejecutar un proyecto de código abierto; algunas
empresas ofrecen este tipo de plataforma comercial de hosting con una
tasa de costo cero o muy barato para los proyectos de código
abierto.
¿Debería alojar su proyecto en una infraestructura completamente
de código abierto? Si bien sería ideal tener acceso a todo el código
que se ejecuta el sitio, mi opinión es que lo crucial es tener una
forma de exportar los datos del proyecto, y ser capaz de
interactuar con los datos de maneras automatizables. Un sitio que
cumpla con estos criterios realmente nunca podrá encerrarte en él, e
incluso será extensible, hasta cierto punto, a través de su interfaz
de programación. Aunque hay algo de valor en tener todo el código que
se ejecuta un sitio de alojamiento disponible bajo los términos de
código abierto, de todas formas en la práctica las exigencias de la
implementación real de ese código en un entorno de producción son
prohibitivos para la mayoría de los proyectos. Estos sitios necesitan
varios servidores, redes personalizadas, y el personal de tiempo
completo para que sigan funcionando; el mero hecho de tener el código
no sería suficiente para duplicar o "forkear" el servicio de todos
modos. Lo principal es sólo asegurarse de que sus datos no se
encuentran atrapados.
Por supuesto, todo lo anterior sólo se aplica a los
servidores. Su proyecto no debe exigir a los participantes ejecutar
software de colaboración privativos en sus propias máquinas.
El anonimato y la participación
Un problema que no es exclusivo a los sitios enlatados, pero con
mayor frecuencia se encuentra allí, es la sobre-exigencia de registro
de usuario para participar en diversos aspectos del proyecto. El
adecuado grado de exigencia es un poco una cuestión de criterio. El
registro de usuarios ayuda a evitar el spam, por un lado, y aunque
cada commit se revise es aún probable que usted no quiera extraños
anónimos subiendo cambios al repositorio, por ejemplo.
Pero a veces el registro del usuario termina siendo requerido
para tareas que deben ser autorizados a visitantes no registrados,
especialmente la capacidad de registrar tickets en el gestor de fallos,
y para comentar sobre los tickets existentes. Al requerir un nombre de
usuario que haya iniciado sesión en tales acciones, el proyecto eleva
la barra de compromiso de lo que deberían ser tareas rápidas y
convenientes. También cambia la demografía de quienes registran errores,
ya que los que se toman la molestia de crear una cuenta de usuario en
el sitio del proyecto son apenas una muestra aleatoria incluso de entre
los usuarios que están dispuestos a registrar errores (que a su vez ya
son un subconjunto parcial de todos los usuarios del proyecto). Por
supuesto, uno quiere ser capaz de ponerse en contacto con alguien que
introdujo los datos en el gestor de tickets, pero teniendo un campo en
el que se pueda introducir la dirección de correo electrónico (si
quiere) es suficiente. Si un nuevo usuario ve un error y quiere
denunciarlo, sólo se moslestará por tener que llenar un formulario de
creación de su cuenta antes de poder entrar en el gestor de fallos.
Él puede simplemente decidir no presentar el error en absoluto.
Si usted tiene el control sobre las acciones que se pueden hacer
de forma anónima, asegúrese de que al menos todas
las acciones de sólo lectura se les permita a los visitantes que no han
iniciado sesión, y si es posible que los portales de entrada de datos,
como el gestor de fallos, que tienden a llevar la información de los
usuarios a los desarrolladores, también se puedan utilizar de forma
anónima, aunque, por supuesto, todavía pueden ser necesarias algunas
técnicas anti-spam, como captchas.
Listas de Correo / Foros de Mensajes
Los foros de discusión en el que los participantes publican y
responden a mensajes son el pan y la mantequilla de las comunicaciones
en el proyecto. Durante mucho tiempo estos fueron principalmente las
listas de discusión basadas en correo electrónico, pero la distinción
entre los foros basados en la web y listas de correo estan,
afortunadamente, desapareciendo poco a poco. Servicios como Grupos de Google (que no es
en sí de código abierto) y Gmane.org (que sí es) ya han establecido que la accesibilidad
cruzada de los foros de mensajes como listas de correo y viceversa es
la meta mínima a alcanzar, y sistemas modernos de gestión de discusiónes
como GroupServer y Sympa reflejan esto.
Debido a esta unificación casi terminada entre las listas de
correo y foros basados en la web Que tardó un tiempo
en llegar — ver rants.org/2008/03/06/thread_theory para más. Y no, no soy
demasiado digno para referirme a mi propio artículo de
blog., utilizaré los términos foro de
mensajes y lista de correo más o
menos de la misma manera. Se refieren a cualquier tipo de foro basado
en mensajes donde las publicaciones están unidas entre sí en hilos
(temas), es posible suscribirse, se pueden consultar archivos de
mensajes anteriores, y en el foro se puede interactuar por vía email
o a través de un navegador web.
Si un usuario está expuesto a cualquier canal aparte de las
páginas web de un proyecto, es muy probable que sea uno de los foros
de mensajes del proyecto. Pero antes de que experimente el propio foro,
experimentará el proceso de encontrar los foros adecuados. El proyecto
debe tener una descripción prominentemente ubicada de todos los foros
públicos disponibles, para dar a los recién llegados una guía para
decidir en cuáles navegar o publicar primero. Una descripción típica
podría decir algo como esto:
Las listas de correo son los principales canales de comunicación del
día a día de la comunidad Scanley. Usted no tiene que estar suscrito
para publicar en una lista, pero si es la primera vez que
publica (ya sea que esté suscrito o no), su mensaje puede ser
retenido en una cola de moderación hasta que un moderador humano
tenga la oportunidad de confirmar que el mensaje no es spam.
Lamentamos este retraso; culpe a los spammers que lo hacen necesario.
Scanley tiene las siguientes listas:
users {_AT_} scanley.org:
Discusión sobre el uso de Scanley o programación con la API Scanley,
sugerencias de posibles mejoras, etc. Usted puede examinar los archivos
de users@ en <<<enlace al archivo>>> o suscribirse aquí:
<<<enlace para suscribirse>>>.
dev {_AT_} scanley.org:
Discusión sobre el desarrollo de Scanley. Mantenedores y contribuyentes
están suscritas a esta lista. Usted puede examinar los archivos
de dev@ en <<<enlace al archivo>>> o suscribirse aquí:
<<<enlace para suscribirse>>>.
(A veces los hilos se cruzan entre users@ y dev@, y los desarrolladores de
Scanley suelen participar en los debates de ambas listas. En general si no
está seguro dónde una pregunta o mensaje deberían ir, inícielo en
users@. Si debe ser una discusión sobre el desarrollo,
alguien le sugerirá movierlo hacia dev@.)
announcements {_AT_} scanley.org:
Esta es una lista de bajo tráfico, de sólo suscripción. Los desarrolladores
de Scanley publican aquí anuncios de nuevas versiones y en ocasionales otras
noticias de interés para toda la comunidad Scanley, pero la discusión se
lleva a cabo en users@ o dev@. <<<enlace para
suscribirse>>>.
notifications {_AT_} scanley.org:
Todos los mensajes de commit del código, tickets del gestor de fallos, fallos
automatizados de construcción/integración, etc, son enviados a esta lista.
La mayoría de los desarrolladores deberían suscribirse: <<<enlace
para suscribirse>>>.
También hay una lista no pública a la que pudieras necesitar hacer un envío, aunque
sólo los desarrolladores están suscritos:
security {_AT_} scanley.org:
Donde el proyecto Scanley recibe informes confidenciales de
las vulnerabilidades de seguridad. Por supuesto, se hará público
el informe al final, pero sólo después de que se publique una
solución; consulte nuestra página de procedimientos de seguridad
para más [...]
Elegir el software correcto para la gestión del foro
Vale la pena invertir algo de tiempo en la elección del sistema
de gestión de listas de correo adecuado para su proyecto. Las
herramientas modernas de gestión de listas ofrecen al menos las
siguientes características:
Acceso a través de correos o basado en web
Los usuarios deben ser capaces de suscribirse a los foros
por correo electrónico, y leerlos en la web (en la que se
organizan en conversaciones o "hilos", tal como se haría
en un lector de correo).
Características para la moderación
Moderar es revisar los mensajes, especialmente los mensajes
de primera vez, para asegurar que no son SPAM antes de que
lleguen a la lista. La moderación incluye necesariamente a
seres humanos administradores, pero el software puede
realizar un gran trabajo para hacerlo más sencillo. Se
discute más acerca de la moderación luego.
Interfaz Administrativa
Hay muchas cosas que los administradores necesitan hacer
además de la moderación de spam — por
ejemplo, la eliminación de las direcciones obsoletas, una
tarea que puede llegar a ser urgente cuando la dirección de
un destinatario comienza a enviar respuestas automáticas
del tipo "ya no tengo ésta dirección de correo" a la lista
en respuesta a cada mensaje (aunque algunos sistemas incluso
pueden detectar esto y dar de baja a la persona de forma
automática). Si su software de foro no tiene capacidades
administrativas decentes, enseguida se dará cuenta, y
debería considerar un cambio de software.
Manipulación de las cabeceras
Algunas personas tienen sofisticados filtros y reglas de
respuestas configuradas en sus clientes de correo, y depende
del foro añadir o manipular ciertas cabeceras estándar. Ver
más adelante en este
capítulo para más información sobre esto.
Archivo
Todos los mensajes enviados a las listas son almacenados y
hechos públicos en la web. (Ver
en para más
información sobre la importancia de los archivos públicos).
Por lo general, el archivador es una parte natural del
sistema de foros de mensajes; de vez en cuando, es una
herramienta independiente que debe integrarse.
El objetivo de la lista de arriba es sencillamente mostrar que
la administración de los foros es un problema complejo sobre el cual
se ha pensado mucho, y hasta cierto grado está resuelto. No es
necesario convertirse en un experto, pero tendrá que aprender al menos
un poco sobre esto, y deberá suponer que la administración de las
listas ocupará algo de atención de vez en cuando durante la duración
cualquier proyecto de software libre. A continuación examinaremos
algunos de los problemas más comunes que podemos encontrar al
configurar las listas de correo.
Prevenir el Spam
Entre el momento cuando ésta frase es escrita y cuando es
publicada, el problema a lo largo y ancho de Internet el problema
del Spam probablemente sea el doble de severo—o al menos
parecerá que es así. Hubo una época, no mucho tiempo atrás, cuando
se podía administrar una lista de correos sin la necesidad de tomar
medidas para prevenir el Spam. Algún mensaje extraviado ocasional
aparecía pero con tan poca frecuencia que solo era una molestia
de bajo nivel. Esa época ya es historia. Hoy, las listas de correo
que no toman medidas preventivas en contra del Spam se verá
sumergida rápidamente en correo basura hasta el punto de ser inútil.
Prevenir el Spam es una prioridad.
La prevención de spam se divide en dos categorías: prevenir
que mensajes basura aparezcan en la lista y prevenir que la lista
sea utilizada como fuente de nuevas direcciones de correo para los
spammers. La primera es la más importante para su proyecto, así que
la examinaremos primero.
Filtrado de los mensajes
Existen tres técnicas básicas para prevenir mensajes basura y
muchas aplicaciones para listas ofrecen las tres. Lo mejor es utilizarlas
en tandem:
Sólo permitir automáticamente
mensajes de los suscriptores a la lista.
Esto es efectivo hasta cierto punto y necesita
de poca administración ya que usualmente es sólo
cuestión de cambiar algunos puntos en la configuración
de la aplicación de listas. Hay que apuntar que
aquellos mensajes que no son aprobados automáticamente
no deben ser desechados. En su lugar, deben ir hacia
una cola de moderación. Primero, se deben permitir
mensajes de quienes no están suscritos: una
persona con una pregunta o sugerencia no debería
tener que suscribirse a la lista para hacer una
pregunta. Segundo, incluso quienes están suscritos
envían mensajes desde cuentas diferentes de la que
han utilizado para suscribirse. Las direcciones de
correo electrónico no son un método eficaz para
identificar a las personas y no debe ser utilizado
para esto.
Filtrar los mensajes utilizando
un programa de detección de spam.
Si la aplicación de listas de correo lo permite (la mayoría
lo hace) se pueden filtrar los mensajes utilizando un filtro
anti-spam. El filtrado automático de Spam no es perfecto, y
nunca lo será, ya que existe un pulso sin fin entre los
spammers y los escritores de filtros. A pesar de esto, se puede
reducir enormemente la cantidad de Spam que llega a la cola
de moderación y dado que mientras más larga sea ésta cola, se
necesitaran más tiempo examinándola, así que cualquier filtrado
automático es beneficioso.
No hay lugar suficiente para unas instrucciones detalladas
sobre como configurar filtros de Spam. Habrá que consultar la
documentación de la aplicación de listas de correo para esto
(en
más adelante en éste capítulo). Las aplicaciones para
listas vienen con características para la prevención de Spam,
pero quizás sería una buena idea añadir una solución de un
tercero. He tenido buenas experiencias con estas dos:
SpamAssassin (spamassassin.apache.org)
y SpamProbe (spamprobe.sourceforge.net).
Esto no es una crítica contra otros filtros anti spam open
source que al parecer son muy buenos también. Sucede que sólo
he tenido la oportunidad de utilizar estos dos y estar
satisfecho con ellos.
Moderación.
Para aquellos correos que no son automáticamente
aceptados por su virtud de ser enviados por un suscriptor
a la lista y que pasan a través del filtro anti-spam, si es
que lo hay, la ultima fase es la moderación:
el correo es enrutado a un área especial de espera, donde alguien
lo examina y lo confirma o rechaza.
Confirmar un mensaje usualmente se puede hacer de dos
formas:
se puede aceptar el mensaje del remitente sólo una vez o se le
puede indicar
al sistema que acepte éste y todos los mensajes futuros
de éste remitente. Casi siempre deseamos hacer lo último
de manera que podamos reducir la carga futura en la moderación.
— después de todo, alguien que ha enviado un
mensaje válido a un foro es poco probable que se transforme de
repente en un spammer más tarde.
Rechazar un mensaje se hace marcando el artículo para
ser descartado, o diciendole explícitamente al sistema que
el mensaje era spam por lo que el sistema puede mejorar su
capacidad de reconocer spams futuros. A veces, usted
también tiene la opción de descartar automáticamente los
futuros correos electrónicos del mismo remitente sin que
estos jamás pasen por la cola de moderación, pero rara vez
hay una razón para hacer esto, ya que de todos modos los
spammers no envían desde la misma dirección dos veces.
Curiosamente, la mayoría de los sistemas de mensajes
de foro aún no han dado a la interfaz de administrativa de
la cola de moderación la atención que merece, considerando
qué tan común es la tarea, por lo que la moderación a
menudo requiere todavía mayor número de clics y gestos de
interfaz de usuario de los que debería. Espero que esta
situación mejore en el futuro. Mientras tanto, tal vez
saber que no está solo en su frustración atenuará un poco
su decepción.
Hay que asegurarse de que la moderación sólo
se utiliza para filtrar el spam, y quizás para mensajes claramente fuera de contexto, como
cuando alguien envía un correo a la lista equivocada. Aunque el sistema de
moderación por lo general puede ofrecer una manera de responder directamente
al remitente, nunca debería usar utilizar ese métdo para responder a preguntas
que realmente pertenecen a la lista, incluso si se sabe la respuesta
inmediatamente. De hacer esto, se privaria a la comunidad del proyecto
de una visión exacta de que tipo de preguntas hace la gente y privaría
a las personas de la oportunidad de responder ellos mismos a preguntas y/o ver las
respuestas de otros. La moderación de las listas debe ser estrictamente
para mantenerlas libres de spam y de correos ampliamente fuera de contexto,
nada más.
Ocultar las direcciones en los archivos
Para prevenir que los spammers utilicen las listas de correo
como una fuente de direcciones, una técnica muy común es la de ocultar
las direcciones de correo de la gente en el registro, reemplazándolas
como por ejemplo:
jrandom@somedomain.com
por
jrandom_AT_somedomain.com
o
jrandomNOSPAM@somedomain.com
o algo similar igual de obvio (para un humano). Ya que los
recolectores de direcciones por lo general funcionan reptando por
paginas web—incluyendo el archivo de nuestra lista de correo—
y buscando secuencias conteniendo "@", modificar las direcciones
es una forma para que sean invisibles o inútiles para los spammers.
Esto no hace nada para prevenir que se envié spam desde la lista,
por supuesto, pero si evita que se incremente la cantidad de spam
enviado directamente a las cuentas personales de los usuarios de
la lista.
Ocultar las direcciones puede ser algo controversial. A algunas
personas les puede gustar mucho y se sorprenderán si el registro no lo
hace automáticamente. Otras pueden pensar que es demasiado inconveniente
(porque los humanos también tenemos que traducir las direcciones antes
de utilizarlas). Algunas veces las personas afirman que es inefectivo,
porque los recolectores en teoría pueden compensar cualquier patrón
de modificación consistente. No obstante, hay que señalar que existe
evidencia empírica de que ocultar las direcciones es
efectivo, como se puede ver en cdt.org/speech/spam/030319spamreport.shtml.
Lo ideal sería que la aplicación administrativa de la lista
diese la posibilidad de escoger a cada individuo, utilizando una cabecera si/no
especial o configurándolo en las preferencias de la cuenta del
suscriptor. Sin embargo, no conozco ninguna aplicación que permita hacer
esto para cada suscriptor o para cada mensaje, así que por ahora el
administrador de la lista debe tomar la decisión en nombre de todos
(asumiendo que el archivador ofrece ésta característica, lo cual no
es siempre así). Por si sirve de algo, yo me inclino ligeramente
hacia ocultar las direcciones.
Algunas personas son muy cuidadosas para evitar enviar sus
direcciones de correo electrónico en paginas web o en cualquier lugar
donde un recolector de spam pueda verla, y podrían ser decepcionante
que todo ese cuidado sea perdido gracias al registro de la lista de correo.
Mientras tanto, la inconveniencia al ocultar las direcciones que impone en
los usuarios del registro es muy pequeña, dada la trivialidad de transformar
las direcciones al formato correcto si se necesita contactar con esa
persona. Pero hay que seguir pensando en que, al final, sigue siendo
una lucha sin fin: para cuando haya leído esto, los recolectores
podrían haber evolucionado hasta el punto de reconocer la mayoría
de formas comúnmente utilizadas para ocultar y tendremos que pensar
en algo más.
El gran debate del Reply-To
Antes en hice incapie
en la importancia de asegurar que las discusiones se mantengan en foros
públicos y hable acerca de porque a veces tomar medidas activas es necesario
para prevenir que algunas conversaciones deriven a hilos privados. Este capítulo
es acerca de todo lo relacionado con preparar el software de comunicación
del proyecto para que realice la mayor cantidad de trabajo posible para
la gente. Así que,
si la aplicación para la administración de las listas de correo ofrece una
manera automática de encausar las discusiones a la lista, habría que
pensar que habilitarla es la opción correcta.
Bueno, quizás no. Existe tal característica, pero tiene algunas
desventajas muy importantes. Usarla o no es uno de los debates más
calientes en la administración de las listas de correo—admitamoslo,
no es una controversia que vaya a aparecer en las noticias, pero se puede
iniciar de vez en cuando en los proyectos de software libre. A continuación,
voy a describir esta característica, proponer los argumentos de cada
posición y hacer la mejor recomendación que puedo.
Esta característica en si misma es muy sencilla: la aplicación
para las listas puede, si lo deseamos, automáticamente establecer
la cabecera Reply-To en todos los mensajes para dirigir todas las
respuestas a la lista. Así que, sin importar lo que escriba el
remitente en este campo (o si ni siquiera lo establecen) para
cuando los suscriptores a la lista vean el mensaje, éste contendrá
la dirección de la lista en la cabecera:
Reply-to: discuss@lists.example.org
Esto puede parecer algo bueno, porque virtualmente todos
los clientes de correo prestan atención a esta cabecera y ahora
cada vez que alguien responda a algún mensaje, su respuesta
será automáticamente dirigida a la lista, no sólo a quien ha
enviado el mensaje que se responde. Por supuesto que el remitente
puede manualmente modificar esto, pero lo importante es que
por defecto las respuestas son enviadas a
la lista. Este es un ejemplo perfecto de como utilizar la tecnología
para animar la colaboración.
Desafortunadamente, existen algunas desventajas. La primera es
conocida como el problema No puedo llegar a casa:
a veces, el remitente original establece su dirección de correo
real en el campo Reply-to porque por alguna razón u otra envían
correos utilizando una dirección diferente a la que utilizan
para recibirlos. Las personas que envían y reciben correos desde el
mismo sitio no tienen éste problema y quizás se sorprendan de que
siquiera existe. Pero para quienes utilizan configuraciones de correo
inusuales o quienes no pueden controlar como se forma el campo
From de su dirección de correo electrónico (quizás porque envían
correos desde sus trabajos y no tienen ninguna influencia sobre
el departamento de sistemas) el utilizar el campo Reply-To quizás
sea la única manera que tienen para asegurarse de que las respuestas
a sus mensajes les llegan (encuentran el camino a casa). Así que si
la aplicación de las listas sobre escribe estoEn teoría,
el software de la lista podría agregar la dirección
de las listas a cualquier destino Reply-to que ya exista, si fuera el
caso, en lugar de sobrescribirlo. En la práctica, por razones que no
conozco, la mayoría del software de lista lo sobrescribe en lugar de
agregar., esta persona
puede que nunca vea las respuestas a sus mensajes.
La segunda desventaja se refiere a las expectativas y en mi
opinión, el argumento más fuerte en contra del cambio del Reply-To.
La mayoría de los usuarios experimentados de correo electrónico
están acostumbrados a dos métodos básicos de responder:
Responder a todos y Responder
al remitente. Todos los clientes de correo tienen
botones separados para estas dos acciones. Sus usuarios saben que
para responder a todos los incluidos en la lista, deben escoger,
responder a todos y que para responder sólo al remitente en privado,
deben seleccionar Responder al remitente. Aunque se desee animar
a que la gente responda a la lista siempre que sea posible, existen
ciertas circunstancias cuando un mensaje privado al remitente es
prerrogativo—por ejemplo, desean compartir información
confidencial, algo que sería inapropiado para una lista pública.
Ahora consideremos lo que sucede cuando la lista sobre escribe
la cabecera Reply-To original del remitente. Quien responde pulsa
la opción de Responder al remitente, con la esperanza de enviar
un mensaje privado al autor original. Porque esta es la conducta
esperada y quizás esta persona no se moleste en examinar
cuidadosamente la dirección del destinatario en el nuevo mensaje. Redacta
su correo privado, un mensaje confidencial, uno que puede diga algo
embarazoso acerca de alguien de la lista y pulsa el botón de enviar.
Inesperadamente el mensaje llega a la lista
unos minutos después. Cierto, en teoría debería haber revisado
cuidadosamente el destinatario y no debería haber asumido nada
acerca del campo Reply-To. Pero por lo general este campo se
compone con su dirección de correo personal (o en su lugar, los clientes
de correo lo hacen) y muchos usuarios asiduos del correo electrónico
dan esto por seguro. De hecho, cuando alguien determina
deliberadamente el campo Reply-To a alguna otra dirección, como la de
la lista, usualmente señalan esto en el contenido del mensaje, de forma
que quienes respondan no se sorprendan de lo que sucede cuando lo hacen.
Dada la posibilidad de consecuencias muy severas de esta conducta
inesperada, mi preferencia es la de configurar la aplicación de la lista
para que nunca toque la cabecera Reply-To. Este caso de cuando se utiliza
la tecnología para animar la colaboración tiene, a mi parecer, efectos
colaterales potencialmente peligrosos. Por otro lado, existen argumentos
concretos del otro lado de este debate. Sea lo que sea que se escoja,
puede que en ocasiones algunas personas pregunten por qué no se ha
escogido el otro camino. Dado que esto no es algo que se quiere sea
el principal tema de discusión en la lista, puede ser conveniente
tener una respuesta preparada del tipo que sea más propensa a poner
fin a la discusión en lugar de animarla. Hay que asegurarse de
no insistir en que esta decisión, sea cual sea,
es obviamente la única correcta (incluso cuando se crea que esto es
así). En cambio, hay que señalar que este es un viejo debate, que
existen buenos argumentos de cada lado, que ninguna decisión iba a
satisfacer a todos los usuarios y que por esto se ha tomado la mejor
decisión que se podía. Amablemente se pide que el tema no
vuelva a surgir a menos que alguien tenga algo realmente nuevo que decir,
entonces hay que mantenerse alejado y esperar a que muera
por causas naturales.
Alguien podría sugerir una votación. Se puede permitir esto si se
quiere, pero personalmente no creo que contar manos sea una solución
satisfactoria en este caso. El castigo para alguien que se vea sorprendido
por este comportamiento es demasiado (accidentalmente enviar un correo
privado a la lista publica) y las molestias para todos los demás es
pequeña (ocasionalmente recordarle a alguien que deben responder a la
lista) por esto no está claro de que la mayoría, aunque sean la mayoría,
deban poner a una minoría bajo ese riesgo.
No he llegado a tocar todos los aspectos acerca de este tema, sólo
los que me han parecido de especial importancia. Para una discusión completa,
se pueden leer los siguientes documentos, los cuales son siempre citados
cuando se entra en el debate:
Leave Reply-to alone,
por Chip Rosenthal
unicom.com/pw/reply-to-harmful.html
Set Reply-to to list,
por Simon Hill
metasystema.net/essays/reply-to.mhtml
A pesar de las benignas preferencias indicadas anteriormente, no
creo que exista una única respuestas correcta y he participado
felizmente de muchas listas que cambiabanel Reply-To.
Lo mejor que se puede hacer, es centrarse en alguna de las dos vías desde
el principio e intentar no verse enredado en debates sobre esto despues.
Cuando el debate resurja cada ciertos años, ya que inevitablemente
sucederá, se puede dirigir a la gente a la discusión archivada de la
última vez.
Dos fantasías
Algún día, alguien tendrá la brillante idea de implementar una
opción Responder a la lista en su cliente de correo.
Podría utilizar alguna de las cabeceras para listas mencionadas antes
para descubrir la dirección de la lista de correos y luego direccionar
las respuestas directamente a la lista, ignorando cualquier otro destinatario,
ya que probablemente muchos estén suscritos a la lista de todas formas.
Eventualmente, otros clientes implementarán esta característica y todo
el debate desaparecerá. (De hecho, el cliente de correos
Mutt ofrece esta opción.
Poco después de que este libro apareciera, Michael Bernstein me escribió para comentarme lo siguiente:
"Existen otros clientes de correos que implementan una función de
responder a la lista a parte de Mutt. Por ejemplo, Evolution tiene
una combinación de teclas, pero no un botón (Ctrl+L).")
Una mejor solución sería que el tratamiento del campo Reply-To fuese
una opción por suscriptor. Quienes deseen que la lista modifique
sus cabeceras Reply-To (ya sea en sus mensajes o en los de otros)
podría solicitarlo, y quienes no lo desean, se les deja tranquilos.
Aunque no conozco ninguna aplicación para listas de correo que permita
esto para cada suscriptor. Así que por ahora, parece que estamos atados
a una configuración global.Desde que escribí esto, he
aprendido que existe al menos un sistema de gestión de listas que ofrece
esta característica: Siesta.
Hay un artículo sobre este en
Archivo
Los detalles técnicos para configurar un archivo para
la lista de correos son específicos de la aplicación utilizada y están
fuera del alcance de este libro. Si tiene que escoger o configurar
un archivador, es conveniente considerar lo siguiente:
Actualización rápida
A menudo la gente querrá ser referida a un mensaje enviado
recientemente. Si es posible, el archivador deberá
archivar cada mensaje instantáneamente, de tal manera de que cuando
el mensaje aparezca en la lista de correos, ya esté en el archivo.
Si esa opción no esta disponible entonces al menos hay que intentar
configurar el archivado para que se realice cada hora o así. (Por
defecto, algunos archivadores ejecutan el proceso de actualización
cada noche, pero en la práctica esta demora es demasiado larga
para una lista de correos.
Estabilidad referencial
Una vez que un mensaje es archivado bajo una URL en
particular, debe ser accesible desde esa URL para siempre.
Incluso si el archivo es reconstruido o restaurado de un
respaldo, cualquier URL que haya sido hecha publica debe
permanecer igual. Las referencias estables hacen posible
que los buscadores de Internet sean capaces de indexar el
archivo, lo cual es una gran ventaja para los usuarios que
buscan respuestas. Las referencias estables son también
importantes porque los mensajes de la lista y los hilos
son enlazados desde el gestor de fallos (
más adelante en este capítulo) o
en la documentación de otros proyectos.
Lo ideal sería que la aplicación de la lista de correos
incluya la URL del mensaje archivado o al menos la porción
de la URL específica del mensaje en una cabecera cuando este
es distribuido. De esta manera la gente que haya recibido el
mensaje podrá conocer su lugar en el archivo sin la necesidad
de visitar el archivo, lo cual es de gran ayuda, ya que cualquier
actividad que implique el uso del navegador web es automáticamente
un consumo de tiempo. Que alguna aplicación de listas de
correos ofrece esta posibilidad no lo sé. Desafortunadamente,
los que he utilizado no la tienen. Pero esto es algo que hay
que buscar (o si desarrolla una aplicación de listas, esta es
una característica que debe considerar implementar, por favor).
Soporte de hilos
Desde cualquier mensaje debe ser posible ir al hilo
(grupo de mensajes relacionados) al que pertenece el mensaje. Cada
hilo debe tener su propia URL también, separado del URL de los
mensajes del hilo.
Búsquedas
Un archivo que no permita búsquedas—tanto en el cuerpo
de los mensajes como por autor o según el asunto—es casi
inútil. Hay que señalar que algunos archivadores permiten búsquedas
al remitir la labor a un buscador externo como Google. Esto es
aceptable, pero por lo general, las búsquedas directas son más
finas, porque permiten a quien busca, especificar que los
resultados sean mostrados, por ejemplo, según el asunto y no
según el cuerpo del mensaje.
Lo anterior es sólo una lista técnica para ayudar a evaluar y
configurar un archivador. Hacer que la gente de hecho utilice
el archivo como ventaja para el proyecto es discutido en capítulos posteriores
en particular en .
Estas son algunas de las herramientas para la ejecución de foros
de mensajes. Si el lugar donde usted es el anfitrión de su proyecto ya
cuenta con la configuración por defecto, entonces puedes usarla y no
tiene que elegir. Pero si usted tiene que instalar uno usted mismo, a
continuación están algunas de las posibilidades. (Por supuesto,
probablemente hay otras herramientas por ahí que yo no he logrado
encontrar, por lo que no tome esto como una lista completa).
Grupos de Google — groups.google.com
Listar los Grupos de Google de primero fue una decisión
difícil. El servicio no es en sí misma de código abierto, y algunas
de sus funciones administrativas pueden ser un poco difícil de
usar. Sin embargo, sus ventajas son sustanciales: los archivos de su
grupo están siempre en línea y se pueden hacer búsquedas; usted no
tiene que preocuparse por la escalabilidad, las copias de seguridad,
u otros problemas de infraestructura en tiempo de ejecución; las
características de la moderación y la prevención de spam son
bastante buenas (con esta último siendo constantemente mejorado, que
es importante en la carrera armamentista sin fin del spam); y los
Grupos de Google son fácilmente accesibles tanto a través de correo
electrónico como la web, de manera que es probable que ya sea
familiar para muchos participantes. Estas son ventajas fuertes. Si
lo que desea es conseguir que su proyecto se inicie, y no quiere
gastar demasiado tiempo pensando en qué software o servicio para foro de
mensajes utilizar, "Google Groups" es una buena opción por defecto.
GroupServer —
Tiene un archivador incorporado y una interfaz basada en Web
integrada. GroupServer tiene un poco de trabajo de configurarción,
pero una vez que lo tenga instalado y funcionando se ofrece a los
usuarios una buena experiencia. Usted puede encontrar hostings con
GroupServer alojado gratis o a bajo costo para los foros de su
proyecto, por ejemplo, de OnlineGroups.net.
Sympa — sympa.org
Desarrollado y mantenido por un consorcio de universidades
francesas, y diseñado para una instancia determinada de manejar
tanto listas muy grandes (> 700.000 miembros, según ellos) como un
gran número de listas. Sympa puede trabajar con una variedad de
dependencias; por ejemplo, se puede ejecutar con sendmail o
postfix, qmail o exim como agente de transferencia de mensajes
subyacente. Tiene incorporado en el archivado basado en Web.
Mailman — list.org
Durante muchos años, Mailman era la norma para las listas
de correo de los proyectos de código abierto. Viene con un archivador
incorporado, Pipermail, y la posibilidad de conectarse en archivadores
externos. Desafortunadamente, Mailman está mostrando su edad ahora,
y si bien es muy fiable en cuanto a la entrega de mensajes y otras
funcionalidades bajo el capó, las interfaces de
administración — especialmente para la suscripción y la
moderación de spam — son frustrante para aquellos que
están acostumbrados a la web moderna. Al escribir estas líneas a
finales de 2013, el tan esperado Mailman 3 estaba todavía en desarrollo,
pero estaba a punto de entrar en beta-testing; en el momento en que
usted lea esto, Mailman 3 puediera ser libertado, y valdría la pena un
vistazo. Se supone que solucionaría muchos de los problemas de Mailman
2, y pudiera Mailman ser una elección razonable de nuevo.
Dada — dadamailproject.com
No he utilizado Dada yo mismo, pero se mantiene activa y, por
lo menos a partir de las apariencias externas, bastante elegante y
atractivo. Note que para usarlo para listas participativas, al
contrario de listas de anuncios, al parecer se necesita activar el
plug-in "Dada-Bridge". Hay disponibles ofertas de alojamiento e
instalación comerciales de Dada, o puede descargar el código e
instalarlo usted mismo.
Control de Versiones
Un sistema de control de versiones (o
sistema de control de revisiones) es una combinación
de tecnologías y practicas para seguir y controlar los cambios
realizados en los ficheros del proyecto, en particular en el código
fuente, en la documentación y en las páginas web. Si nunca antes se ha
utilizado un control de versiones, lo primero que hay que hacer es conseguir
a alguien que sí lo haya hecho y hacer que se una al proyecto. Hoy en día
todo el mundo espera que al menos el código fuente del proyecto este
bajo un control de versiones y probablemente no se tomen el proyecto
seriamente si no se utiliza este sistema con un mínimo de competencia.
La razón por la cual el control de versiones es universal es porque
ayuda virtualmente en todos los aspectos al dirigir un proyecto: comunicación
entre los desarrolladores, manejo de los lanzamientos, administración de fallos,
estabilidad entre el código y los esfuerzos de desarrollo experimental y
atribución y autorización en los cambios de los desarrolladores. El sistema
de control de versiones permite a una fuerza coordinadora central
abarcar todas estas áreas. El núcleo del sistema es la
gestión de cambios: identificar cada cambio a los ficheros
del proyecto, anotar cada cambio con meta-data como la fecha y el autor
de la modificación y disponer esta información para quien sea y como sea.
Es un mecanismo de comunicación donde el cambio es la unidad básica de
información.
Aun no hemos discutido todos los aspectos de utilizar un sistema
de control de versiones ya que es un tema tan extenso que será
introducido según el tópico a lo largo de este libro. Ahora, vamos a
concentrarnos en seleccionar y configurar un sistema de control de versiones
de forma que fomentemos un desarrollo cooperativo.
Vocabulario del Control de Versiones
En este libro no podemos enseñar como utilizar el control de
versiones si nunca antes lo ha utilizado, pero sería imposible continuar
sin conocer algunos términos clave. Estos son útiles independientemente
del sistema particular utilizado: son definiciones básicas y verbos sobre
la colaboración en red y serán utilizados a lo largo del libro. Incluso
si no existiera ningún sistema de control de versiones, el problema del
control de los cambios aun existiría y estas palabras nos dan un lenguaje
para hablar acerca de este problema consistentemente.
commit
Realizar un cambio en el proyecto. Formalmente, almacenar
un cambio en la base de datos del control de versiones de
forma que pueda ser incorporado en lanzamientos futuros del
proyecto. "Commit" puede ser utilizado como un verbo o como
un sustantivo. Como un sustantivo, es esencialmente un
sinónimo de "cambio". Por ejemplo: "He commited una reparación
para un fallo reportado en Mac OS X que hacia que el servidor
se colgara. Jóse ¿podrías por favor revisarlo y verificar que
no estoy haciendo mal la asignación?"
Solicitar los cambios (commits) que han realizado
otros en la copia local del proyecto, esto actualiza
esta copia a la ultima versión. Es una operación muy
común ya que la mayoría de los desarrolladores actualizan
su código varias veces al día y así saben que están
ejecutando casi lo mismo que los otros desarrolladores, así
que si se descubre un fallo es muy posible que este aun
no haya sido resuelto. Por ejemplo: "Hey, he notado
que el código del índice está fallando en el último
byte. ¿Es esto un nuevo fallo?" "Sí, pero fue resuelto
la semana pasada—prueba actualizar para resolverlo."
Mensaje de registro
Un pequeño comentario añadido a cada commit que describe
el tipo y el propósito del commit. Los mensajes de
registro forman parte de los documentos más importantes
de cualquier proyecto ya que son un puente entre el
lenguaje altamente técnico de los cambios individuales
en el código y el lenguaje más orientado al usuario de
características, resolución de fallos y progreso del
proyecto. Más adelante vamos a ver la forma de distribuir
estos mensajes a la audiencia apropiada y también
en discutimos
como ENCOURAGE a los voluntarios para que escriban mensajes
de registro útiles y concisos.
repositorio
Una base de datos en la que los cambios son almacenados. Algunas
versiones de sistemas de control de versiones son centralizados,
es decir, existe un único repositorio maestro, el cual almacena
todos los cambios en el proyecto. Otros sistemas son descentralizados,
cada desarrollador tiene su propio repositorio y los cambios pueden
ser intercambiados entre repositorios arbitrariamente. El sistema
de control de versiones mantiene un registro de las dependencias
entre estos cambios y cuando llega el momento de realizar un
lanzamiento, un conjunto particular de cambios es aprobado
para ese lanzamiento. La cuestión de cual sistema es mejor
es otra de las guerras santas del desarrollo de software.
Intentad no caer en la trampa de discutir sobre esto en las
listas de correo del proyecto.
checkout
El proceso de obtener una copia del proyecto desde el repositorio.
Por lo general, un checkout produce un árbol de directorios
llamado "copia funcional" desde el cual los cambios serán
enviados de vuelta al repositorio original. En algunas versiones
descentralizadas de sistemas de control, cada copia funcional
es en si mismo un repositorio y los cambios son empujados (o
atraídos) a cualquier repositorio que este dispuesto a aceptarlos.
copia funcional
El árbol de directorios privado de cada desarrollador que
que contiene el código fuente del proyecto y posiblemente
las páginas web u otros documentos. Una copia funcional
también contiene un pequeña cantidad de meta-data administrada
por el sistema de control de versiones, informando a la copia
funcional cual es repositorio central de procedencia, la
revisión de los ficheros presentes, etc. Generalmente, cada
desarrollador tiene su propia copia funciona en la cual
realiza y prueba los cambios y desde la cual envía sus
commits (cambios).
revisión,
cambio,
conjunto de cambios
Una revisión es usualmente una encarnación específica de un
fichero o directorio en particular. Por ejemplo, si el proyecto
se inicia en la revisión 6 del fichero F y alguien envía un
cambio al fichero F, esto produce la revisión 7 de F. Algunos
sistemas también utilizan revisión (revision), cambio (change)
o conjunto de cambios (changeset) para referirse a un conjunto
de cambios enviados juntos como una unidad conceptual.
Estos conceptos pueden tener distintos significados técnicos
en cada sistema de control de versiones, pero en general, la idea es
siempre la misma: dar un sistema para comunicar de manera precisa la
historia de cambios en un fichero o conjunto de ficheros (inmediatamente
antes y después de que se ha corregido un fallo). Por ejemplo: "Eso
se ha resuelto en la revisión 10" o "Se ha corregido eso en la revisión
10 del fichero foo.c."
Cuando se habla sobre ficheros o una colección de ficheros sin
especificar una revisión en particular, por lo general se asume que
nos referimos a la revisión disponible más reciente.
"Versión" Versus "Revisión"
El termino versión es a veces utilizado
como un sinónimo para "revisión", pero aquí no voy a utilizarla de esta
forma, ya que se puede confundir fácilmente con "versión" en el sentido
de una versión de un programa—así que, el número de lanzamiento
o edición como en "Versión 1.0". Y aunque la frase "control de versiones"
es un estándar, continuare utilizándolo como sinónimo para "control
de revisiones" y para "control de cambios".
diff
Una representación contextual de un cambio. Un diff muestra las lineas
que han sido modificadas, como y además, algunas lineas contextuales
rodeándolas a cada lado. Un desarrollador familiarizado con el código
puede, con leer un diff de ese código, entender lo que hace el cambio
e incluso detectar fallos.
etiqueta (tag)
Una etiqueta para una colección particular de ficheros en una revisión
específica. Los tags son utilizados para preservar capturas interesantes
del proyecto. Por ejemplo, un tag es hecho para cada lanzamiento público,
de forma que cada persona pueda obtener, directamente desde el sistema
de control de versiones, el conjunto exacto de ficheros/revisiones
que componen el lanzamiento. Algunos tags comunes son como
Release_1_0, Delivery_00456,
etc.
rama (branch)
Es una copia del proyecto, bajo el control de versiones, pero aislado,
de forma que los cambios realizados en esta rama no afecten al resto
del proyecto y vice versa, excepto cuando los cambios sean
deliberadamente "unidos" de un lado al otro. Las ramas también son
conocidas como "lineas de desarrollo". Incluso cuando un proyecto
no tiene ramas específicas se considera que el desarrollo se esta
produciendo en la rama principal, también conocida como "línea
primaria" o "trunk".
Las ramas o branches, permiten aislar diferentes lineas de
desarrollo de si mismas. Por ejemplo, una rama puede ser utilizada
para un desarrollo experimental que sería demasiado inestable para
la rama principal. O al contrario, una rama puede ser utilizada
como sitio para estabilizar una versión para lanzamiento. Durante
el proceso de lanzamiento, el desarrollo regular se mantendría ininterrumpida
en la rama principal. Mientras tanto, en la rama de lanzamiento,
ningún cambio es aceptado excepto aquellos aprobados por el
responsable del lanzamiento. De esta manera, realizar un lanzamiento
no tiene porque interferir con el trabajo de desarrollo que se está
realizando. Para más información
más adelante en el capítulo para una discusión más
detallada sobre las ramas.
merge
Mover un cambio de una rama a otra, lo que incluye unir desde
la rama principal a otra rama o vice versa. De hecho, estos
son las uniones más comunes y es rara la ocasión en la que
esto se hace entre dos ramas no principales. Para más
información sobre los merge .
"Merge" tiene otro significado: es lo que hace el sistema de control
de versiones cuando se encuentra con que dos personas han realizado
cambios en un mismo fichero sin relación alguna. Ya que estos cambios
no interfieren entre ellos, cuando alguna de estas personas actualizan
su copia del fichero (el cual ya contiene los cambios) los cambios
de la otra persona serán unidos automáticamente. Esto sucede muy a
menudo, especialmente en proyectos con múltiples personas realizando
cambios en el mismo código. Cuando dos cambios diferentes están
relacionados, el resultado es un "conflicto".
conflicto
Sucede cuando dos o más personas intentan realizar diferentes
cambios en la misma porción de código. Todos los sistemas
de control de versiones detectan estos conflictos automáticamente
y notifican a al menos uno de los humanos involucrados de que
sus cambios entran en conflicto con los de alguien más. Es
entonces tarea de esta personas resolver
el conflicto y comunicar esa resolución al sistema de control
de versiones.
bloqueo (lock)
Declaración de un intento exclusivo para cambiar un fichero
o directorio en particular. Por ejemplo, "No puedo enviar
cambios a las paginas web ahora mismo, ya que parece que
Alfredo las tiene bloqueadas mientras arregla sus
imágenes de fondo." No todos los sistemas de control de
versiones ofrecen la posibilidad del bloqueo y aquellos
que sí lo permiten, no es necesario que se utilice. Esto
es porque el desarrollo paralelo y simultaneo es la norma
y bloquear a la gente para que no puedan modificar los
ficheros es contrario a la idea del sistema.
El modelo del sistema de control de versiones que requiere el bloqueo
de ficheros suele ser llamado bloqueo-modificación-desbloqueo
y el modelo que no requiere del bloqueo es llamado
copia-modificación-unión. Una excelente explicación
en profundidad y comparaciones puede ser encontrada en
. En
general, el modelo de copia-modificación-unión es el mejor
para el desarrollo open source y todos los sistemas de control
de versiones discutidos en este libro soportan este modelo.
Escoger un sistema de control de versiones
Utilizando el sistema de control de versiones
Las recomendaciones realizadas en esta sección no están
enfocadas hacia un sistema de control de versiones en particular
y debería ser sencillo implementarlas en cualquiera. La documentación
específica del sistema debe ofrecer los detalles necesarios.
Versiones de todo
No solo hay que mantener el código del proyecto bajo el control
de versiones también las paginas web, documentación, FAQ, notas de
diseño y cualquier cosa que pueda ser necesario editar. Todo esto
hay que mantenerlo cerca del código, en el mismo árbol que el
repositorio. Se deben mantener versiones de cualquier pieza de
información que pueda cambiar y archivar la que no cambie.
Por ejemplo, un correo electrónico,
una vez enviado, no cambia, por lo tanto, mantener versiones de este
no tiene sentido (a menos que se convierta en una parte importante
de la documentación).
La razón de mantener versiones de todo en un mismo sitio, es
para que la gente sólo tenga que aprender un sistema para realizar
cambios. A menudo, un voluntario se iniciara modificando algunas
paginas web o partes de la documentación, para luego pasar a realizar
pequeñas contribuciones al código, por ejemplo. Cuando el proyecto
utiliza el mismo sistema para todo tipo de cambios, las personas sólo
tendrán que aprender THE ROPES una vez. Mantener las versiones juntas
significa que nuevas características pueden ser añadidas junto
a la actualización de la documentación, y que al crear ramas del
código, se crearan ramas de la documentación, etc.
No hace falta mantener los ficheros generados
bajo el sistema de control de versiones ya que no son datos editables
generados por otros programas. Por ejemplo, algunos sistemas de
compilado generan los ficheros configure basandose
en una plantilla configure.in. Para realizar
cambios al fichero configure bastaría con
modificar configure.in y volver a generarlo.
Entonces, sólo el fichero configure.in es
un fichero editable. Sólo es necesario mantener versiones de las
plantillas—si se hace con los ficheros generados, la gente
se olvidará de volver a generarlos cuando realicen algún cambio
en las plantillas y las resultantes inconsistencias crearan una
mayor confusión. Alexey Mathotkin tiene una
opinión diferente sobre el tema de controlar las versiones de los
ficheros configure en un artículo llamado
"configure.in and version control" en
.
La regla de que todos los datos editables deben ser mantenidos
bajo el control de versiones tiene una excepción desafortunada: el
gestor de fallos. La base de datos de fallos almacena una gran cantidad
de datos editables pero generalmente, por razones técnicas, no se puede
mantener bajo el control de versiones principal. (Algunos gestores
tienen características primitivas de control de versiones, pero
independiente de repositorio principal del proyecto.)
Navegabilidad
El repositorio del proyecto debe ser accesible desde Internet.
Esto no solo significa la habilidad de visualizar la ultima revisión
de los ficheros del proyecto, pero permitir volver atrás en el tiempo
y ver en revisiones anteriores, mirar las diferencias entre revisiones,
leer los mensajes de registro para cambios específicos, etc.
La navegabilidad es importante porque es un ligero portal a los
datos del proyecto. Si el repositorio no es accesible desde un navegador
web entonces alguien que desea inspeccionar un fichero en particular (por
ejemplo, para mirar si una mejora ha sido incluida en el código) tendrá
que instalar el mismo programa utilizado por el sistema de control
de versiones, lo cual convierte una simple consulta de dos minutos en
una tarea de medio hora o más.
También implica URLs CANONICAL para visualizar revisiones
específicas de un fichero y para la ultima revisión en cualquier
momento. Esto puede ser muy útil durante discusiones técnicas o para
indicar alguna documentación a la gente. Por ejemplo, en lugar de
decir "Para ayudas sobre como encontrar fallos en el servidor,
mirad el fichero www/hacking.html en vuestra copia funcional" se puede
decir "Para ayudas sobre como encontrar fallos en el servidor,
mirad http://subversion.apache.org/docs/community-guide/,"
dando una URL que siempre lleva a la ultima revisión del fichero
hacking.html. La URL es mejor porque no es nada
ambigua y evita la cuestión de si existe una copia funcional
actualizada.
Algunos sistemas de control de versiones incluyen un mecanismo
que permite la navegación del repositorio, mientras que otros
dependen de herramientas de terceros. Tres de estas herramientas son
ViewCVS (),
CVSWeb (), and
WebSVN ().
La primera trabaja muy bien con CVS y con Subversion, la segunda
sólo con CVS y la tercera sólo con Subversion.
Las ramas para evitar cuellos de botella
Los usuarios inexpertos del control de versiones pueden sentirse
temerosos de crear ramas y uniones. Esto sea probablemente un efecto
colateral de la popularidad de CVS: su interfaz de ramas y uniones puede
ser poco intuitivo, así que muchas personas han aprendido a evitar
estas operaciones por completo.
Si se encuentra entre estas personas, decidase ahora mismo a
conquistar cualquier miedo que pueda tener y tómese el tiempo de aprender
cómo funcionan las ramas y las uniones. No son operaciones muy complicadas
una vez que se acostumbra a ellas y se vuelven muy importantes mientras
el proyecto adquiere más desarrolladores.
Las ramas son muy importantes porque convierten un recurso
escaso—espacio de trabajo en el código del proyecto—en uno
abundante. Normalmente, todos los desarrolladores trabajan juntos
en la misma caja de arena, construyendo el mismo castillo. Cuando alguien
desea añadir un nuevo puente levadizo, pero no puede convencer a los
demás de que sería una mejora, entonces las ramas hacen posible que vaya
a una esquina aislada donde probar su puente. Si el esfuerzo tiene éxito,
puede invitar a otros desarrolladores para que evalúen el resultado. Si
todos están de acuerdo en que el resultado es bueno, pueden hacer que
el sistema de control de versiones mueva ("merge") el puente levadizo
de la rama del castillo a la rama principal del castillo.
Es fácil ver como esta habilidad ayuda al desarrollo colaborativo,
ya que la gente necesita de cierta libertad para probar cosas nuevas
sin sentir que están interfiriendo con el trabajo de otros. Igual
de importante es cuando el código debe ser aislado del CHURN usual
de desarrollo de manera que un fallo sea reparado o un lanzamiento
sea estabilizado (más en y
en en
) sin la preocupación
de seguir un blanco en movimiento.
Hay que utilizar las ramas libremente y fomentar su uso entre
otros. Pero también hay que asegurarse de que una rama en particular
se mantenga activa exactamente durante el tiempo que sea necesaria.
Incluso quienes no trabajan en la rama principal mantienen una visión
periférica de lo que está sucediendo en ésta. Esta visión es deseable,
por supuesto, y los correos con cambios deben salir de estas ramas
como de cualquier otra. Pero las ramas no deben convertirse en un
mecanismo que divida a la comunidad de desarrolladores. Con raras
excepciones, el objetivo eventual de la mayoría de las ramas debe
de ser su unión a la rama principal y desaparecer.
Singularidad de la información
Las uniones tienen un corolario importante: nunca se debe enviar
el mismo cambio dos veces, es decir, un cambio dado sólo debe ser
introducido al sistema de control de versiones solo una vez. La revisión
(o conjunto de revisiones) en la que el cambio es introducido es su
identificador único desde ese momento. Si debe ser aplicado a otras
ramas aparte de la cual en la que ha sido hecho, entonces deberá ser unido
desde su punto de entrada original a sus otros destinos —al
contrario de enviar cambios textualmente idénticos, que tendrían el
mismo efecto en el código, pero harían del mantenimiento eficaz y de
la gestión de lanzamientos una tarea imposible.
Los efectos prácticos de este consejo difieren entre sistemas
de control de versiones. En algunos sistemas, las uniones son eventos
especiales, fundamentalmente distintos de los commits y acarrean sus
meta-datos propios. En otros, el resultado de las uniones son enviadas
de la misma manera que los cambios son enviados así que la mejor manera
de distinguir una unión de un nuevo cambio es leyendo los mensajes de
registro. El mensaje de registro de una unión no repite el mensaje
de registro del cambio original, en cambio, sólo indica que es una
unión y da la identificación de la revisión del cambio original, con
como mucho una línea de sumario del sus efectos. Si alguien desea ver
el mensaje de registro completo, deberá consultar la revisión original.
La razón por la cual es importante evitar la repetición de los
mensajes de registro es que estos pueden ser editados después de que
se hayan enviado. Si un mensaje de registro es repetido en el destino
de cada unión, entonces incluso si alguien edita el mensaje original,
deja todos los otros mensajes sin corregir—lo cual sólo puede
causar confusión a largo plazo.
El mismo principio se aplica al retirar un cambio. Si esto llegara
a suceder, entonces el mensaje de registro para la retirada solo debe
indicar que una revisión en particular está siendo retirada,
no debe describir el cambio en el código resultante, pues la semántica
del cambio se puede intuir al leer el mensaje de registro original del
cambio. Por supuesto, el mensaje de registro del retiro también debe
indicar la razón por la cual ese cambio ha sido retirado, pero no debe
duplicar nada del mensaje de registro del cambio original. Si es posible,
hay que volver y editar el mensaje de registro original para señalar
que ha sido retirado.
Todo lo anterior implica que se debe utilizar una sintaxis
consistente al referirnos a las revisiones. Esto es de gran ayuda
no sólo en los mensajes de registro, sino en los correos electrónicos,
en el gestor de fallos y en todas partes. Si se esta utilizando
CVS, recomiendo "directorio/al/fichero/del/proyecto/rama:REV",
donde REV es un número de revisión en CVS como "1.76". Si se esta
utilizando Subversion, la sintaxis estándar para la revisión
1729 es "r1729" (el directorio de los ficheros no es necesario
porque Subversion utiliza números globales para las revisiones). En
otros sistemas, existe por lo general una sintaxis estándar para
expresar el nombre del conjunto de cambios. Cualquiera que sea
la sintaxis apropiada para el sistema utilizado, hay que animar
a la gente a que lo utilicen al referirse a algún cambio. El
uso consistente en el nombre de los cambios permiten que el
mantenimiento del proyecto sea mucho más sencillo (como ya
veremos en y en
), y dado que mucho de este
mantenimiento será realizado por voluntarios, debe ser lo más
sencillo posible.
Más información en
.
Autorizaciones
Muchos de los sistemas de control de versiones ofrecen la posibilidad
por la cual a ciertas personas se les permite o no, realizar cambios
en áreas específicas del repositorio. Siguiendo el principio de que
cuando a las personas se les entrega un martillo empiezan a buscar
clavos para golpear, muchos proyectos utilizan esta característica
con ABANDON, permitiendo cuidadosamente el acceso solo a las áreas
donde tienen permiso de enviar cambio y asegurándose de que no lo puedan
hacer en ningún otro sitio. (Más información en
sobre como
los proyectos deciden quienes pueden hacer cambios y donde.)
Probablemente hayan pequeños daños implementar un control
así de estricto, pero una política un poco más relajada también
esta bien. Algunos proyectos utilizan un sistema basado en el honor:
cuando a una persona se le permite la posibilidad de realizar cambios,
aunque sea a una pequeña área del repositorio, lo que reciben es una
contraseña que les permite realizar cambios en cualquier otro sitio
del repositorio y sólo se les pide que mantengan sus cambios en su
área. Hay que recordar que no existe ningún peligro aquí: de todas formas,
en un proyecto activo, todos los cambios son revisados. Si alguien hace
un cambio donde no debía, alguien más se dará cuenta y dirá algo. Es muy
sencillo si un cambio debe ser rectificado—todo está bajo el control
de versiones de todas formas, así que sólo hay que volver atras.
Existen varias ventajas en tal aproximación tan relajada.
Primero, mientras los desarrolladores se vayan expandiendo en las
diferentes áreas (lo cual harán a menudo si siguen en el proyecto),
no es necesario un trabajo administrativo extra de tener que dar y
quitar privilegios. Una vez que la decisión es tomada, la persona
puede empezar a enviar sus cambios a la nueva área sin problemas.
Segundo, la expansión se puede filtrar mejor, ya que generalmente,
quienes realizan cambios en el área X y desean expandirse al área Y
sólo tienen que empezar a enviar sus cambios contra Y y solicitar
su revisión. Si alguien con acceso a cambios al área Y recibe alguno
de estos parches y lo aprueba, puede pedir que el cambio sea enviado
directamente (mencionando el nombre de quien ha revisado/aprobado el
cambio en el mensaje de registro). De esta manera, el commit vendrá
de quien ha hecho el cambio, lo cual es preferible desde un punto de
vista administrativo y de credibilidad.
Por último, y quizás la razón más importante, al utilizar
un sistema basado en el honor, se crea una atmósfera de confianza
y respeto mutuo. Al darle a alguien permiso para enviar cambio a
un subdominio se hace una declaración acerca de su preparación
técnica—la cual dice: "Hemos visto que tienes la capacidad
para realizar cambios en cierto dominio, así que a por ello". Pero
imponer controles estrictos en las autorizaciones dice: "No sólo
estamos juzgando tus limitadas capacidades, sino que también
sospechamos de tus intenciones." Este no
es el tipo de declaraciones que se desean hacer si pueden ser
evitadas. Incluir a alguien dentro del grupo de desarrolladores
del proyecto es una oportunidad de iniciarlos en un circulo de
confianza mutua. Una buena manera de hacer esto es dar más
poder del que se supone deben tener e informarles que es su
responsabilidad mantenerse dentro de los límites impuestos.
El proyecto Subversion ha operado bajo este sistema por más
de cuatro años, con 33 desarrolladores con privilegios completos
y 43 con privilegios parciales. La única distinción que el sistema
fuerza esta entre quienes envían cambios y quienes no, otras divisiones
son mantenidas sólo por humanos. Incluso así, nunca hemos tenido
ningún problema con que alguien realice un cambio deliberado fuera
de su dominio. Una que otra vez han habido inocentes mal entendidos
sobre la extensión de los privilegios de alguna persona, pero siempre
es resuelto rápida y amigablemente.
Obviamente, en situaciones donde esto es poco práctico se debe
depender en controles estrictos en las autorizaciones, pero dadas
situaciones son raras. Incluso cuando hay millones de lineas de
código y ciento o miles de desarrolladores, un commit hecho a
cualquier módulo del código sigue siendo revisado por quienes
trabajan en dicho módulo y son quienes pueden reconocer si quien
lo ha intentado hacer puede hacerlo. Si una revisión regular no
está sucediendo entonces el proyecto tiene problemas más importantes
con los cuales lidiar que el sistema de autorizaciones.
Para concluir, no hace falta pasar mucho tiempo con las
autorizaciones del sistema de control de versiones a menos que se
tenga una razón en específico. Usualmente esto no trae beneficios
tangibles y confiar en el control humano tiene sus ventajas.
Por supuesto que nada de esto significa que las restricciones mismas son poco
importantes. Sería malo para un proyecto el animar a las personas
a realizar cambios en áreas para las cuales no están cualificadas. Incluso
en algunos proyectos, el acceso ilimitado tiene un status especial:
implica derecho de voto en cuestiones que atañen al proyecto por
completo. Este aspecto político del acceso es discutido en mayor
profundidad en
en .
Correos de cambios
Cada commit al repositorio debería generar un correo electrónico
mostrando quien ha hecho el cambio, cuando, cuales ficheros y directorios
han cambiado y como. Este correo debe ser dirigido a una lista de correos
separada de las listas a las que envían los humanos. Los desarrolladores
y todos aquellos interesados deben ser animados para suscribirse a las
lista de commits ya que es la manera más efectiva de mantenerse al día con
lo que sucede en el proyecto al nivel del código. Aparte de los obvios
beneficios técnicos de la revisión por la comunidad (),
los correos con los cambios ayudan a crear un sentido de comunidad
porque establecen un ambiente compartido en el que la gente puede
reaccionar ante diferentes eventos (commits) que saben son visibles
a otros tambien.
La configuración específica para habilitar estos correos varia
dependiendo de la versión del sistema de control de versiones pero
a menudo existe un script o paquete que facilita esto. Si se tiene
algún problema para encontrar estos, intente buscar en la documentación
el tema relacionado con los hooks,
específicamente el post-commit hook, también
llamado loginfo hook en CVS. Los
Post-commit hooks son tareas automatizadas que se ejecutan como
respuesta a los cambios enviados (commits). El hook es ejecutado
por un cambio individual, se rellena con la información acerca del
cambio y luego es liberada esa información para ser utilizada como
se desee—por ejemplo, para enviar un correo electrónico.
Con los sistemas de correos con cambios ya listos para usar,
quizás sea necesario modificar alguna de las siguientes conductas:
Algunos de estos sistemas no incluyen el diff en el correo
que envían sino que enlazan con una URL para poder ver el cambio
en la web utilizando el sistema de navegación del repositorio.
Aunque esta bien dar una URL para que se pueda revisar el cambio
luego, también es muy importante que el
correo del commit incluya los diff. Leer el correo electrónico
ya es parte de la rutina de la gente, así que si el contenido es
visible allí mismo en el correo, los desarrolladores podrán
revisar el commit en el mismo sitio sin la necesidad de abandonar
sus clientes de correo. Si tienen que seguir un enlace a una
página de revisiones, muchos no lo pulsarán, ya que esto requiere
de una nueva acción en lugar de una continuación de lo que ya
estaban haciendo. Por si fuera poco, si el lector desea preguntar
algo acerca del cambio, es mucho más fácil responder al mensaje
incluyendo el texto original y simplemente realizar anotaciones
en el diff, en lugar de tener que visitar una página web y
tomarse la molestia de copiar y pegar partes del diff en el
navegador web al cliente de correo.
(Por supuesto que si el diff es gigantesco, como cuando
una gran parte de código nuevo ha sido añadido al repositorio,
entonces tiene sentido omitir la parte del diff y ofrecer
sólo la URL. Muchos de los sistemas permiten hacen esto
automáticamente. Si el utilizado en el proyecto no es capaz
de hacer esto, entonces sigue siendo mejor incluir los diffs
completos. La conveniencia de la revisión y los comentarios
es una piedra angular del desarrollo cooperativo, algo demasiado
importante para olvidar.)
Los correos con los cambios deben tener su cabecera
Reply-To direccionada hacia la lista regular de desarrollo, no
a la lista de los cambios, de esta manera cuando alguien revise
un cambio y escriba una respuesta, esta debe ser dirigida
automáticamente a la lista de desarrolladores, donde los temas
técnicos son discutidos normalmente. Existen varias razones para
esto, primero, se quiere mantener todas las discusiones técnicas
en la lista, porque es allí donde la gente espera que sucedan y
porque así ésta es la única lista que será necesario archivar.
Segundo, puede que existan partes interesadas no suscritas a la
lista de cambios. Tercero, la lista de cambios es publicitada
como una lista para los commits y no como una lista para los
commits y las discusiones técnicas ocasionadas. Quienes se han
suscrito sólo a la lista de cambios, no se han suscrito a nada
más que commits, al enviarles correos con material sin relación
utilizando ésta vía, es una violación del contrato implícito.
Cuarto, algunas personas escriben programas que procesan los
correos con los cambios (para publicarlos en una página web,
por ejemplo). Estos programas están preparados para manejar
correos con un formato consistente y son incapaces de trabajar
con correos escritos por humanos.
Hay que señalar que ésta recomendación no contradice
las recomendaciones anteriores en
.
Siempre esta bien que el remitente del mensaje configure
la cabecera Reply-to. En este caso, el remitente es el
sistema de control de versiones y su Reply-to lo configura
de tal manera que indique que el lugar apropiado para responder
es la lista de desarrollo y no la lista de cambios
Seguimiento de errores
El seguimiento de errores es un tema muy amplio y varios
aspectos de este son discutidos a lo largo de este libro. Aquí
intentare concentrarme principalmente en las consideraciones técnicas
y en la instalación, pero para llegar a esto, debemos empezar con
una política de preguntas: exactamente ¿qué tipo de información
va a ser mantenida en el sistema de seguimiento?.
El término seguimiento de errores puede
generar confusión ya que estos sistemas se utilizan frecuentemente
para seguir solicitudes para nuevas características, tareas que se
efectúan sólo una vez, parches no solicitados—en realidad se
utilizan para cualquier cosa que pueda tener estados distinguibles
de comienzo y final, con estados opcionales de transición entre
estos y que acumulan información a lo largo de su existencia. Por
esta razón, los sistemas de seguimiento de fallos también son
llamados de seguimiento de temas,
de defectos,
de solicitudes, trouble ticket
system, etc. Más información en
donde hay una lista de programas.
En este libro continuare utilizando "gestor de fallos" para la
aplicación que hace el seguimiento, porque es así como la mayoría
de la gente lo llama y utilizare issue al
referirme a un punto en particular en la base de datos del gestor
de fallos. Esto nos permitirá distinguir entre los buenos y malos
comportamientos que el usuario se puede encontrar (el fallo en si
mismo) y el registro en el gestor del
descubrimiento, diagnostico y eventual resolución del fallo. Hay
que recordar que aunque la mayoría de las entradas sean fallos,
también pueden ser otras tareas.
El clásico ciclo de vida se parece al siguiente:
Alguien crea una entrada. Ofrecen un resumen, una descripción
inicial (incluyendo como reproducir el fallo si es posible. En
en hay ejemplos
de como se puede animar la correcta creación de reportes de fallos)
y cualquier otra información que el gestor solicite. Quien crea
la entrada puede ser un desconocido al proyecto—los reportes
de fallos y las solicitudes de características provienen tanto
de los usuarios como de los desarrolladores.
Una vez enviada, la entrada entra en un estado llamado
abierto porque ninguna acción ha sido
tomada aun. Algunos gestores etiquetan las nuevas entradas
como sin verificar o como
sin iniciar. No está asignada a nadie,
o en algunos sistemas, es asignada a un usuario fantasma que
representa la falta de una asignación real. Llegado a este
punto, la entrada se encuentra en el área de espera: ha sido
registrada, pero aun no ha sido integrada en la conciencia
del proyecto.
Otros leen la entrada, añaden comentarios y quizás soliciten
el esclarecimiento de algunos puntos a quien realizo la entrada.
El fallo es reproducido. Este puede que
sea el momento más importante en su ciclo vital, ya que incluso
que el fallo aun no ha sido resuelto, el hecho de que alguien
haya podido reproducirlo además de quien creo la entrada prueba
que es genuino y, no menos importante, confirma al creador
de la entrada que ha contribuido al proyecto reportando un
fallo real.
El fallo es diagnosticado: su causa
es identificada, y si es posible, es estimado el esfuerzo
requerido para repararlo. Hay que asegurarse de que todo esto
es registrado en la entrada, ya que en el case en que quien
haya hecho el diagnostico abandona el proyecto (lo cual
sucede a menudo con desarrolladores voluntarios), alguien más
debe ser capaz de continuar con su trabajo.
Llegados a este punto, o a veces en uno de los anteriores,
puede que algún programador ya se haya "adueñado" de la entrada y se
lo asigne a si mismo (el proceso es examinado
en mayor detalle en en ).
La prioridad de la entrada puede que también
sea fijada en esta etapa. Por ejemplo, si el fallo es tan severo
que debería retrasar el próximo lanzamiento, debe ser identificado
desde el principio y el gestor debe proporcionar un mecanismo
para hacer esto.
La entrada es programada para su resolución. Esto no implica
necesariamente fijar una fecha para cuando debe ser resuelta.
A veces sólo significa decidir para cual próximo lanzamiento (no
necesariamente la siguiente) el fallo debe estar corregido o
decidir si debe o no bloquear un lanzamiento en particular.
Incluso nos podemos olvidar de planificar la reparación del
fallo si es algo que se puede hacer rapidamente.
El fallo es reparado (o la tarea es completada, o el
parche es aplicado o lo que sea). El cambio o conjunto de
cambios que arreglan el fallo deben ser registrados en un
comentario en la entrada, después de lo cual ésta es
cerrada o marcada como
resuelta.
Existen variaciones en este ciclo. A veces el problema es cerrado
seguidamente después de ser archivado, porque resulta que no es un fallo,
sino que es un malentendido por parte del usuario. Mientras el proyecto
vaya ganando usuarios, más y más de estas entradas invalidas aparecerán,
y los desarrolladores las cerraran con respuestas cada vez menos
respetuosas. Hay que intentar protegerse de ésta tendencia, pues no le
hace ningún bien a nadie, porque el usuario en cada caso no es responsable
de las entradas invalidas previas. Esta tendencia estadísticas sólo es
divisada por los desarrolladores, no por los usuarios. (En
más adelante
en este capítulo, examinaremos algunas técnicas para reducir
el número de entradas invalidas.) También puede suceder que varios
usuarios estén experimentando el mismo malentendido una y otra vez,
lo cual significa que algún aspecto de la aplicación necesita volver
a ser diseñada. Este tipo de patrones son los más sencillos de ver
cuando se utiliza un gestor de entradas que monitorice la base de
datos de fallos. Más en
en .
Otra variación muy común de este ciclo de vida es cuando la entrada
es cerrada al ser un duplicado poco después
del paso 1. Un duplicado aparece cuando alguien crea una entrada para
un problema ya conocido por el proyecto. Los duplicados no están
limitados a entradas abiertas: es posible que un fallo haya reaparecido
después de haberlo reparado (esto es conocido como regresión),
por lo cual, la vía preferida es usualmente reabrir la entrada original y
cerrar cualquier nuevo reporte como duplicado de este. El sistema
de gestión de fallo debe mantener un seguimiento de esta relación
bidimensional, de forma que la información en los duplicados este
disponible en la entrada original y vice versa.
Una tercera variación es cuando los desarrolladores cierran la
entrada pensando que ya ha sido resuelta y el usuario que la ha
reportado rechaza esa reparación y es reabierta. Por lo general esto
es porque el desarrollador no tiene la capacidad de reproducir
el fallo o porque no han probado su reparación siguiendo
la misma receta para la reproducción descrita por el usuario.
A parte de estas variaciones existen pequeños detalles de
este ciclo de vida que pueden variar dependiendo de la aplicación
de seguimiento. Pero la forma básica es la misma e incluso cuando
el ciclo de vida no es sólo para el software open source, tiene
implicaciones acerca de cómo los proyectos utilizan sus
sistemas de control de fallos.
Implícito en el paso 1, el sistema es una cara tan publica
del proyecto, como lo pueden ser las listas de correo o las paginas
web. Cualquiera puede crear una entrada, cualquiera puede ver
una entrada y cualquiera puede navegar la lista de entradas
abiertas. De tal manera que nunca se sabe cuantas personas están
interesadas en ver el progreso en una entrada en particular. Aunque
el tamaño y la capacidad de la comunidad de desarrolladores constriñe
la frecuencia con la que los problemas son atacados, el proyecto
debe al menos intentar reconocer cada entrada mientras vayan
llegando. Incluso si el problema persiste por un tiempo, una
repuesta anima al usuario a mantenerse involucrado porque siente
que un humano ha visto lo que ha hecho (recordad que rellenar
una entrada requiere mucho más tiempo que un correo electrónico).
Incluso mejor, una vez que una entrada es vista por un desarrollador,
entra en la conciencia del proyecto, en el sentido en que este
puede mantenerse al acecho de otras instancias del mismo problema,
puede comentarlo con otros desarrolladores, etc.
La necesidad de reacciones oportunas implica dos cosas:
El sistema de seguimiento debe conectarse a la lista de correos
de manera que cada cambio a una entrada, incluyendo su redacción
inicial, genere un correo describiendo lo sucedido. Esta lista
de correos es, a veces, diferente de la lista de desarrollo ya
que quizás, no todos los desarrolladores quieran recibir correos
automáticos con fallos, pero (al igual que con los correos con
cambios) la cabecera Reply-to debe ser fijada a la lista
de desarrollo.
El formulario donde se rellena la entrada debe almacenar la
dirección de correo electrónico de quien la reporta, de forma
que pueda ser contactada para solicitar más información.
(No obstante, no debe requerir la
dirección ya que algunas personas prefieren realizar el
reporte anónimamente. Más información sobre el anonimato
en
a continuación en este capítulo.
Interacción con las Lista de Correo
Hay que asegurarse de que el gestor de fallos no se convierte
en un foro de discusiones. Aunque es importante mantener una presencia
humana en el gestor, no está preparado para discusiones en tiempo
real. Hay que pensar en éste como un archivador, una forma de
organizar hechos y referencias a otras discusiones, principalmente
aquellas que suceden en las listas de correo.
Pre-filtrado del gestor de fallos
Muchas de las bases de datos de fallos sufren eventualmente del mismo
problema: una cantidad devastadora de fallos duplicados o inválidos hechos
por usuarios bien intencionados pero sin experiencia o poco informados. El
primer paso para combatir esta tendencia es, por lo general, colocar un vistoso
aviso en la página principal del gestor de fallos, explicando como saber si
un bug es realmente un bug, como buscar si el bug ya está incluido y finalmente,
como reportar efectivamente si aun se cree que es un nuevo fallo.
Esto reducirá el nivel de ruido por un tiempo, pero mientras el
número de usuarios vaya creciendo, el problema regresara eventualmente.
Ningún individuo puede ser culpado de esto, ya que cada uno está
intentando contribuir en beneficio del proyecto e incluso cuando
su primer reporte no sea de verdadera utilidad, se desea animarlos
para que continúen involucrándose y para que puedan hacer mejores
reportes en el futuro. Mientras tanto, el proyecto necesita mantener
en lo posible la base de datos libre de basura.
Las dos cosas que tendrán el máximo efecto a la hora de prevenir
este problema son: asegurarnos de que hay gente vigilando el gestor de fallos
quienes tienen el conocimiento suficiente para cerrar problemas como
inválidos o duplicados mientras vayan llegando y requiriendo (o fomentando
duramente) a los usuarios que confirme su reporte con otras personas antes
de reportarlos en el gestor.
La primera técnica parece ser utilizada universalmente. Incluso
proyectos con gigantescas bases de datos de fallos (digamos, el gestor
de Debian en
, el cual contenía 315,929 reportes
al momento de escribir este libro) siguen ordenando todo de tal manera
que todos puedan ver los reportes mientras llegan.
Puede que sea una persona diferente dependiendo de la categoría del
problema. Por ejemplo, el proyecto Debian es una colección de paquetes
de software, de manera que el proyecto automáticamente enruta cada
reporte a la persona que mantiene el paquete específico. Por supuesto,
a veces los usuarios no identifican bien la categoría a la que pertenece
el problema, con el resultado de que el reporte es enviado a la persona
equivocada, quien entonces deberá redireccionarlo. No obstante, lo
importante es que la carga sigue siendo distribuida—cada vez que
un usuario crea correcta o incorrectamente al reportar, la vigilancia
de las entradas sigue siendo distribuida más o menos uniformemente entre los
desarrolladores, de manera que cada reporte es respondido en un tiempo
justo.
La segunda técnica esta menos extendida, probablemente sea porque
es más difícil de automatizar. La idea esencial es que cada nuevo
reporte es apadrinado hacia la base de datos. Cuando un usuario cree
haber encontrado un bug, se le pide que lo describa en una de las
listas de correo o en algún canal de IRC para que reciba confirmación
de alguien de que en realidad es un fallo. Al introducir este segundo
par de ojos puede prevenir muchos reportes falsos. A veces esta segunda
persona puede identificar que este comportamiento no es un fallo o que
ha sido resuelto recientemente. O puede que este familiarizado con los
síntomas gracias a problemas anteriores, evitando un duplicado
al señalar al usuario el viejo reporte. A veces es tan sencillo como
preguntar al usuario "¿Has revisado el gestor de fallos para asegurarte
de que no ha sido reportado ya?" Muchas personas no piensan en esto,
pero se contentan con hacer la búsqueda sabiendo que hay alguien
a la expectativa de que lo hagan.
El sistema de apadrinamiento puede mantener la limpieza de
los reportes en la base de datos, pero también tiene algunas
desventajas. Muchas personas harán los reportes sin consultar,
al no buscar o despreocupándose de las instrucciones de buscar a un
padrino para el nuevo reporte. Aun así, es necesario que los
voluntarios sigan vigilando las bases de datos y dado que la
mayoría de los nuevos usuarios que reportan fallos no entienden
la dificultad de mantenerlas, no es justo
reprenderlos duramente por ignorar las directrices. Aun así, los
voluntarios deben ser vigilantes y ejercitar restricciones en como
se rechazan reportes sin apadrinar de vuelta a quien lo haya hecho.
El objetivo es entrenar a cada reportero para que utilice el sistema
de apadrinamiento en el futuro, de tal manera que haya una siempre
creciente fondo de gente quienes entienden el sistema de filtrado
de fallos. Al encontrarnos con un reporte sin padrino, los pasos
ideales a tomar son:
Inmediatamente responder el reporte, agradeciendo al usuario
por hacerlo, pero dirigiéndolo a las directrices de apadrinamiento
(las cuales deberían, por supuesto, estar publicadas en un lugar
prominente del sitio web.)
Si el reportes es claramente valido y no un duplicado, hay que
aprobarlo de todas formas y de esta manera que inicie su
ciclo de vida normal. Después de todo, quien ha realizado el
reporte ya ha sido informado sobre el apadrinamiento, así que
no tiene sentido perder el trabajo ya hecho al cerrarlo como
invalido.
Si el problema no es claramente valido, hay que cerrarlo, pero
solicitando que sea reabierto si reciben la confirmación por
parte de un padrino. Cuando lo hagan, deberán colocar una
referencia al hilo de confirmación (por ejemplo, una URL en
el archivo de la listas de correo).
Hay que recordar que a pesar de que este sistema mejorara la proporción
señal/ruido en la base de datos de problemas a lo largo del tiempo, nunca
pondrá fin a los reportes inválidos. La única manera de evitar esto
por completo es cerrar el gestor de fallos a todos quienes no sean
desarrolladores—una cura que casi siempre es peor que la
enfermedad. Es mejor aceptar que la limpieza de reportes inválidos siempre
será una parte de la rutina de mantenimiento del proyecto e intentar obtener
la mayor cantidad de ayuda para hacerlo.
Más en
en el
.
IRC / Sistemas de Chat en Tiempo Real
Muchos proyectos ofrecen salas de chat utilizando Internet
Relay Chat (IRC), foros donde los
usuarios y desarrolladores pueden hacerse preguntas y obtener respuestas
instantáneas. Mientras que se puede llevar un
servidor de IRC para nuestro sitio web, por lo general no vale la pena. En
cambio podemos hacer lo que todo el mundo: crear canales de IRC en
Freenode (). Freenode proporciona
el control necesario para administrar los canales IRC del proyecto,
No es un requerimiento ni tampoco se espera ninguna donación
a Freenode, pero si usted o el proyecto se lo pueden permitir, por favor
considerelo. Son una caridad exenta de impuestos en EE.UU. y proveen
de un servicio muy valioso.mientras que nos evita
la molestia de tener que mantener un servidor de IRC.
Lo primero que hay que hacer es decidir un nombre para el canal. La
opción más obvia es utilizar el nombre del proyecto—si es que se
encuentra disponible en Freenode. Si no, se puede utilizar algo lo más
parecido al nombre del proyecto y que sea en lo posible, fácil de recordar.
Hay que publicitar la disponibilidad del canal en el sitio web del proyecto,
de manera que un visitante con una duda pueda verlo rápidamente. Por ejemplo,
esto aparece en un contenedor prominente en la parte de arriba de la página
principal de Subversion:
La respuesta a todo esto es publicándolo en el tópico
del canal.Para establecer el tópico del
canal se utiliza el comando "/topic. Todos los comandos
en IRC empiezan con el signo "/". Si no se está familiarizado
con la utilización y administración de IRC id a .
Hay un excelente tutorial en
.
El tópico del canal es un breve mensaje que ven todos los usuarios cuando
entran en el canal. Da una guía rápida para los recién llegados y apunta a información
necesaria. Por ejemplo:
Ha entrado en #svn
El tema para #svn es Foro para usuarios de Subversion. Más información en
http://subversion.tigris.org/. || Las discusiones sobre el desarrollo
están en #svn-dev. || Por favor, no pegue transcripciones muy largas,
para ello utilice un sitio como http://pastebin.ca/ || Noticias:
Subversion 1.1.0 ha salido, más en http://svn110.notlong.com/
Es algo tosco, pero informa a quienes entran al canal lo que necesitan
saber. Dice exactamente para lo que es el canal, muestra la página
web del proyecto (en caso de que alguien entre al canal sin antes haber
visitado el sitio web del proyecto), menciona canales relacionados y
da algunas directivas sobre el pegado.
Sitios de pegado
Un canal de IRC es un espacio compartido: todos pueden ver lo que
todos escriben. Normalmente esto es algo bueno, ya que permite que la
gente entre en una conversación cuando creen que tienen algo para
contribuir y permite a los espectadores aprender leyendo. Pero puede
tornarse problemático cuando alguien suministra una gran cantidad
de información a la vez, como la transcripción de una sesión de
debugging, porque al pegar muchas lineas de texto en el canal
se interrumpen las conversaciones de otros.
La solución a esto es el uso de los llamados sitios de pegado
pastebin o pastebot.
Al requerir una gran cantidad de datos de alguien, pida que no los pegue
en el canal, sino que vayan a (por ejemplo) ,
peguen la información necesaria allí y suministren el nuevo URL resultante
al canal de IRC. Así cualquiera puede visitar la URL y revisar los
datos que allí se encuentran.
Existen muchos sitios gratuitos de pegado disponibles, demasiados
para una lista comprensiva, pero aquí hay algunos que he utilizado:
,
,
,
,
y
.
Bots de IRC
Muchos canales técnicos de IRC tienen un miembro no humano, un tal
llamado bot, el cual es capaz de almacenar y
regurgitar información en respuesta a comandos específicos. El bot
se parece a un miembro más del canal, esto es, los comandos se hacen llegar
"hablándole" al bot. Por ejemplo:"
<kfogel> ayita: learn diff-cmd = http://subversion.tigris.org/faq.html#diff-cmd
<ayita> Thanks!
Esto le ha dicho al bot (el cual está en el canal como ayita)
que recuerde cierto URL como la respuesta a la pregunta "diff-cmd". Ahora
podemos dirigirnos a ayita pidiendole al bot que le diga a otro usuario
acerca de diff-cmd:
<kfogel> ayita: tell jrandom about diff-cmd
<ayita> jrandom: http://subversion.tigris.org/faq.html#diff-cmd
Lo mismo puede ser logrado con un comando más corto:
<kfogel> !a jrandom diff-cmd
<ayita> jrandom: http://subversion.tigris.org/faq.html#diff-cmd
El conjunto exacto de comandos y conductas difieren entre bots. El
ejemplo anterior utiliza ayita
(), del cual
existe una instancia en #svn en Freenode. Otros
bots son Dancer
() y Supybot
(). No son necesarios privilegios
específicos en el servidor para ejecutar un bot. Un bot es un programa
cliente; cualquiera puede fijar y dirigirlo para que escuche en un
servidor/canal en particular.
Si el canal del proyecto tiende a recibir las mismas preguntas
una y otra vez, recomiendo utilizar un bot. Sólo un pequeño porcentaje
de usuarios del canal adquirirán la habilidad necesaria para manejar el
bot, pero serán los que sí lo hagan quienes responderán a una cantidad
desproporcionada de preguntas, porque el bot permite que sean respondidas
con mayor eficiencia.
Archivando IRC
Aunque es posible archivar todo lo que sucede en los canales de
IRC, no es algo necesario. Las conversaciones en IRC pueden ser
públicas, por lo que muchas personas piensan en ellas como conversaciones
informales semi-privadas. Los usuarios puede que no cuiden la gramática
y a veces expresen opiniones (por ejemplo, acerca del software o sobre
otros desarrolladores) que no querrán que sean preservadas eternamente
en un archivo en línea.
Por supuesto que existen extractos que deberían
ser preservados. Muchos de los clientes de IRC pueden registrar conversaciones
a un fichero bajo demanda por el usuario, o si esto falla, se puede
copiar y pegar la conversación del IRC a otro foro permanente
(a menudo, el bug tracker). Pero el registro indiscriminado puede incomodar
a algunos usuarios. Si se archiva todo, hay que declararlo claramente en el
tópico del canal y proporcionar una URL del archivo.
Wikis