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 [26], 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 enusers@. Si debe ser una discusión sobre el desarrollo, alguien le sugerirá movierlo haciadev@.)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 [...]
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:
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).
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.
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.
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 “Identificación y Administración de cabeceras” más adelante en este capítulo para más información sobre esto.
Todos los mensajes enviados a las listas son almacenados y hechos públicos en la web. (Ver “Sobresaliente uso de los archivos” en Capítulo 6, Comunicaciones 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.
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.
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.
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.
Al interactuar con el foro por correo electrónico, los suscriptores de las listas mueven estos correos a una carpeta específica para el proyecto, separados de su otro correo personal. Sus clientes de correo hacen esto automáticamente al examinar las cabeceras de los mensajes. La cabecera son los campos que se encuentran en la parte superior de los correos, los cuales indican el remitente, destinatario, asunto, fecha e información variada sobre el mensaje. Ciertas cabeceras son bien conocidas y son efectivamente obligatorias:
From: ... To: ... Subject: ... Date: ...
Otras son opcionales, aunque de cierta manera estándar. Por ejemplo, no es estrictamente requerido que un correo electrónico tenga la cabecera
Reply-to: sender@email.address.here
pero muchas lo tienen, porque da al destinatario una manera a prueba de errores de responder al remitente (es especialmente útil cuando el remitente ha tenido que enviar un correo desde una dirección diferente a la cual las respuestas deben ser dirigídas).
Algunos clientes de correo ofrecen una interfaz fácil de usar para rellenar correos basados en patrones en la cabecera Asunto. Esto lleva a que la gente pida que la lista de correo añada automáticamente un prefijo a todos los Asuntos, de forma que puedan configurar sus clientes para que busquen esos prefijos y archivar los correos en el directorio correcto. La idea es que el autor original escribiría:
Asunto: Trabajando en la versión 2.5
pero el correo aparecería en la lista así:
Asunto: [Scanley Discuss] Trabajando en la versión 2.5
Aunque la mayoría de las aplicaciones de administración de listas ofrecen la opción de hacer esto, usted puede decirdir si lo activa. El problema que resuelve puede a menudo ser resuelto de otras formas menos intrusivas (vea abajo) y hay un costo de utilizar espacio en el campo del Asunto. Los usuarios experimentados de las listas de correos revisan el asunto de los correos entrantes del día para decidir acerca de qué van a leer y qué van a responder. Fijar el nombre de la lista al Asunto puede mover hacia la derecha el verdadero Asunto y fuera de la pantalla, haciéndolo invisible. Esto oculta información necesaria para aquellos quienes dependen en la decisión de cuales correos van a abrir, reduciendo la funcionalidad conjunta de la lista para todos.
En lugar de sobrecargar el Asunto, su proyecto podría sacar ventajas de otras cabeceras estándar, empezando con el campo "Para", el cual debería contener la dirección de la lista de correos:
To: <discuss@lists.example.org>
Cualquier cliente de correo capaz de filtrar los mensajes basándose en el Asunto debe ser capaz de filtrar utilizando el campo Para facilmente.
Existen otras cabeceras opcionales pero estándar para las listas de correo; que a veces no son mostradas por la mayoría del software lector de correo, pero sin embargo, están presentes. Filtrar utilizándolos es incluso más fiable que utilizar las cabeceras "Para" o "Cc" dado que estas cabeceras son añadidas a todos los mensajes por el programa de administración de la lista, así que algunos usuarios están contando con su presencia:
list-help: <mailto:discuss-help@lists.example.org> list-unsubscribe: <mailto:discuss-unsubscribe@lists.example.org> list-post: <mailto:discuss@lists.example.org> Delivered-To: mailing list discuss@lists.example.org Mailing-List: contact discuss-help@lists.example.org; run by ezmlm
La mayoría se explican en si mismos. En nisto.com/listspec/list-manager-intro.html se explican mejor o en faqs.org/rfcs/rfc2369.html para una especificación formal más detallada.
Habiendo dicho todo eso, estos días me parece que la mayoría de los suscriptores sólo solicitan que el encabezado Asunto incluya un prefijo de identificación de la lista. Eso es cada vez más cómo la gente está acostumbrada a filtrar el correo electrónico: el filtro basados en el asunto es lo que muchos de los principales servicios de correo electrónico en línea (como Gmail) ofrecen a los usuarios de forma predeterminada, y esos servicios tienden a no hacer fácil de ver la presencia cabeceras de menor uso común como las que he mencionado anteriormente — por lo que es difícil para la gente darse cuenta de que ellos incluso tienen la opción de filtrar a través de aquellas otras cabeceras.
Por lo tanto, a regañadientes, yo recomiendo usar un prefijo en el Asunto (manteniéndolo tan corto como sea posible), si eso es lo que su comunidad quiere. Pero si su proyecto es altamente técnico y la mayoría de sus participantes se sienten cómodos usando las otras cabeceras, entonces esa opción siempre está ahí como una alternativa más eficiente del espacio.
También suele suceder que si usted tiene una lista de correo llamada "foo", entonces también tiene direcciones administrativas disponibles como "foo-help" y "foo-unsubscribe". Además de éstas, era tradicional tener "foo-subscribe" para unirse, y "foo-propietario", para llegar a los administradores de la lista. Cada vez más, sin embargo, los suscriptores gestionan su pertenencia a listas a través de interfaces basadas en la web, por lo que incluso si el software de gestión de listas que usted utiliza configura estas direcciones administrativas, pueden ser en gran medida no utilizadas.
Algunas aplicaciones para listas de correos ofrecen la opción de agregar al final de cada mensaje las instrucciones para eliminar la suscripción. Si ésta opción está disponible, usela. Solo causa algunas lineas extra por mensaje en un sitio inofensivo y puede ahorrar mucho tiempo al reducir el número de gente que escriba —o peor aún, que escriban a la lista—preguntando cómo eliminar la suscripción.
Antes en “Evitar discusiones privadas” 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 esto[27], 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
Set Reply-to to list, por Simon Hill
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.
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.[28])
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.[29]
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:
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.
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 ( “Seguimiento de errores” 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).
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.
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 “Sobresaliente uso de los archivos”.
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 — http://www.groupserver.org/
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.
[26] 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.
[27] En 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.
[28] 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)."
[29] 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 http://www.perl.com/pub/a/2004/02/05/siesta.html