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