¿Por qué los programadores siguen utilizando las listas de correo? [duplicar]

Además de los argumentos "porque están acostumbrados", el correo electrónico tiene algunas otras grandes ventajas:

1. Ya tienes una dirección de correo electrónico, no es necesario que te registres en otra cuenta de tablón de mensajes para cada proyecto.
2. Con un panel de mensajes, debe visitar activamente la página y actualizarla para ver los nuevos mensajes. Por otro lado, la mayoría de las personas tienen su cliente de correo electrónico (Outlook, Mail, Gmail) abierto todo el día y se actualiza automáticamente tan pronto como llega un nuevo mensaje.

En resumen, usar un panel de mensajes me obliga a cambiar mis hábitos de manera significativa. Por otro lado, las listas de correo encajan simplemente & fácilmente en mi rutina existente, por lo que la adopción es mucho más fácil.

El Real Edge (tm) que tienen las listas de correo tiene proyectos menos ocupados. Para que un foro basado en la web sea exitoso, se necesita un núcleo de personas presentes constantemente que puedan responder a las preguntas, brindar sugerencias y moderarlo. Pero si un tablero solo tiene un par de publicaciones por semana o por mes, muchas personas interesadas en el tema (ya sea un proyecto de código abierto, un proyecto comercial, un pasatiempo o cualquier otra cosa) no visitarán regularmente el tablero porque rara vez hay algo nuevo allí.

Lo que termina sucediendo entonces, es que la placa se convierte en lo que podríamos llamar una sesión de b-tch. Las personas solo van allí para publicar un informe de error o cuando tienen un problema / queja. Pero como no hay muchas personas que visitan con regularidad, terminas con muchas quejas / problemas sin respuestas, y muy poco desarrollo de la comunidad .

Si tiene una lista de correo, esas preguntas, en lugar de ser vistas solo por el pequeño subconjunto de miembros que piensan visitar el foro web esa semana, se envían a todos en la lista. Es mucho más probable que los vea alguien que realmente pueda responder la pregunta.

Una vez que el proyecto es lo suficientemente grande, mudarse a una pizarra a menudo tiene sentido, ya que en ese momento las personas se saturan con el correo electrónico.

imo, mi forma favorita de organizar estas cosas es a través de grupos de noticias, pero han caído en desgracia. Los grupos le permitieron, con un lector de noticias, ver todos los temas nuevos en todos los grupos que sigue (beneficio de la lista de correo electrónico), pero con la capacidad de discusión de un foro web. Desafortunadamente, especialmente entre las personas no técnicas, exigir que los usuarios tengan un lector de noticias y configurar los grupos es un total no a la vista.

  

Es difícil hacer referencia a los mensajes antiguos. Debe esperar hasta que un sitio de archivado capte el mensaje que desea vincular y luego búsquelo.

Suponiendo que su servidor de listas esté funcionando correctamente, esto no es un problema, ya que estamos hablando de mensajes antiguos (hacer referencia a los mensajes nuevos puede ser problemático).

  

Es difícil responder a los mensajes que no ha recibido de la suscripción, ya que tiene que copiar manualmente el contenido del remitente y el mensaje.

Si solo alguien diseñara una función, tal vez incluso una integrada en el propio shell del SO, para seleccionar y duplicar texto fácilmente. Tal vez podría modelarse después de una actividad del mundo real cada vez más anacrónica, como scrapbooking.

(No estoy realmente seguro de a qué te refieres aquí; continuar los hilos privados en público tiende a ser una operación manual, independientemente del software involucrado)

  

Es imposible moderar los hilos de discusión. Las publicaciones no se pueden eliminar ni modificar sin poderes sobrenaturales.

El argumento inverso es que es mucho más difícil para un propietario de una lista deshonesta volver a escribir el historial al eliminar partes de la conversación que no están de acuerdo con él, ya que uno o más usuarios probablemente tendrán sus propias copias.

  

Es difícil mantener los hilos juntos (es decir, para garantizar que todos los participantes en la conversación sean copiados / respondidos).

El software de cliente adecuado debería manejar esto fácilmente, así como proporcionar una visualización y orden de hilos más flexible de lo que la mayoría del software de foros web permite.

  

Es complicado para los usuarios participar en múltiples listas de correo de gran volumen, ya que tienen que suscribirse y configurar filtros (o simplemente participar).

Los foros de gran volumen no son más fáciles. En todo caso, es más difícil (si no imposible) configurar los filtros en los paquetes del foro web. O estás "realmente involucrado", o probablemente te estás perdiendo algo.

  

¿Qué ventaja real tienen las listas de correo que no se me ocurrió?

Privacidad por defecto, sin "otra cuenta de sitio web". Rápido de configurar. Una progresión natural de las cadenas informales de correo electrónico a medida que el grupo crece. No hay contexto de ruptura para pasar del correo electrónico a la web al procesar las respuestas. Familiarizados con casi todos (sí, sí, niños coreanos / la generación de Facebook no usa el correo electrónico ...)

Prefiero las listas de correo sobre los foros porque es más fácil. Los foros me obligan a salir activamente y hacer algo adicional (es decir, visitar otro sitio web) repetidamente. Mientras que una lista de correo envía los mensajes directamente a algún lugar, siempre tengo que tenerlos abiertos de todos modos. Punto de contacto único (lista de correo) frente a puntos múltiples (foros). Impulsado por interrupción (lista de correo) frente a sondeo (foros).

Parece que aquí está ocurriendo algo generacional, pero no sé que sea tanto "con lo que has crecido" como en "la etapa de la vida en la que te encuentras". Ahora que soy mayor, tengo muchas más obligaciones (fuera de tierras informáticas) que ya no tengo tiempo para buscar y buscar foros. Sin embargo, si solo llega a mi buzón, se maneja.

De enlace

Mi experiencia: GitHub (y Bitbucket) son geniales. Los motores de búsqueda encuentran discusiones relevantes, o puedes navegar por el repositorio para ver todo. Los comentarios de todos están en una página, y es obvio cómo agregar los suyos (hay un botón verde gigante de "comentar"). Es muy fácil hacer una cuenta (la mayoría de las personas de la comunidad ya tienen una), pero si no es así, es un proceso familiar. Por lo tanto, GitHub es muy acogedor y nivelador también.

Las listas de correo, por otro lado, son terribles, y creo que excluyen a casi toda la comunidad. Desde un motor de búsqueda, irá a una sola publicación desde la mitad de la discusión. Es posible que vea extractos de publicaciones anteriores en orden cronológico inverso. Es desorientador. Para leer todos los comentarios, debe hacer clic alrededor de una estructura de árbol (que se muestra en una página diferente). Eso es ridículamente hostil. La mayoría de la gente seguramente se rendirá. Quizás la experiencia sea mejor si usted es un miembro de la lista de correo y recibe los mensajes en su bandeja de entrada. Sin embargo, entienda que nueva la gente siempre leerá las publicaciones de la lista de correo en la web.

Peor aún, no hay instrucciones en la página sobre cómo comentar. Por ejemplo, enlace , no hay un botón verde grande para comentarios. Si hace clic alrededor, puede registrarse para recibir futuras publicaciones en su bandeja de entrada (no estoy seguro de que quiera eso) pero eso todavía no explica cómo responder a la publicación que está leyendo. . Sospecho que las comunidades mayores no son conscientes de este problema, porque crecieron en las listas de correo. Comprenda, la mayoría de los jóvenes no saben cómo usar una lista de correo, nunca la han visto. Según los estándares modernos, el proceso para hacerlo es ridículamente lento. (Estoy leyendo un post en la web. Debería poder escribir un comentario desde la misma página). Es prohibitivo para muchos.

Los PEP son por lo tanto problemáticos. Por ejemplo, enlace . No hay comentarios de la comunidad en la página en sí. Hay enlaces a cinco páginas diferentes de listas de correo donde puede leer lo que otras personas han dicho en el pasado, pero no hay instrucciones sobre cómo expresar su opinión. Es una pena. (Compare con las solicitudes de funciones de Ruby que se discuten en un hilo de comentarios ordinario en la misma página enlace )

bugs.python.org también es poco acogedor, en mi experiencia. Informé de un error una vez, se cerró de inmediato, con una respuesta

  

No puedes comentar aquí, estás en el lugar equivocado. Este tema ha sido discutido en la lista de correo varias veces antes de [sin enlace]. Si desea comentar, debe unirse a la lista de correo, retroceder en el tiempo, esperar la publicación correcta y responder allí.

El mensaje fue educado, pero completamente inútil. Me sentí mal recibido. Renuncié a tratar de contribuir a (lo que asumí que era) la comunidad y empecé a escribir discursos sobre Stack Overflow. Resultaron ser extremadamente populares, lo que me animó a intentar participar de nuevo. Estoy feliz de haber encontrado tu grupo GitHub: tienes cosas interesantes que decir y aceptaste mis contribuciones. Gracias. Incluso he enviado solicitudes de extracción: me encanta la nivelación de GitHub.

Para aclarar, no creo que el cartel en bugs.python.org intentara excluirme, probablemente pensaron que estaban siendo útiles. Pero la actitud percibida de "hacemos las cosas a nuestra manera" me hizo sentir ignorada e inoportuna. Estoy seguro de que otros contribuyentes potenciales han regresado a los mismos obstáculos o anteriores. enlace

Bare email en sí mismo ya tiene todo lo que deseas. Respondiendo a un mensaje específico, citando un pasaje específico, reenviando una publicación interesante a un amigo tuyo. Además de eso, puedes agregar todo lo que quieras desees.

Todos los programadores tienen correo electrónico. Y la mayoría de ellos usan un cliente de correo decente. Un cliente que eligieron y les gusta. Un cliente que agrega sus fuentes de noticias, su correo personal, su correo de trabajo. Y su lista de correo de correo. El uso de un foro solo introduce una fragmentación innecesaria.

Los clientes de correo electrónico adecuados le brindan todas las funciones que desea (marcadores, filtrado, etiquetado, marcado leído / no leído (algo que no puede hacer en los foros)). Funcionan igual para cualquier tipo de correo electrónico.

Así que una lista de correo deja el control a sus usuarios, mientras que un foro los bloquea en las funciones limitadas que proporciona. A los programadores les gusta mantener el control. Por lo tanto, tienen una tendencia a preferir las listas de correo.

Más que nada por su flexibilidad: es fácil proporcionar un archivo basado en la web de una lista de correo, al tiempo que permite a los usuarios utilizar el cliente de correo electrónico de su elección para interactuar.

En su lugar, ir a un foro no solo elige una vista basada en web para mensajes históricos (¡fácil de proporcionar con cualquier tecnología!), sino que bloquea a los usuarios para que usen una herramienta basada en web para interactuar con el foro.

Dicho de otra manera, usar la web para interactuar con un foro basado en correo electrónico es un problema resuelto; ¿Usar el correo electrónico para interactuar con un foro basado en la web? No tanto.

Ahora considere que muchos desarrolladores pueden seguir una docena o dos foros de forma rutinaria, y considere cuál es más atractivo: configurar un inicio de sesión y una contraseña únicos para cada uno, y aprender una interfaz de usuario independiente para cada uno, o interactuar con todos de ellos a través de una identidad que ya tiene establecida (su dirección de correo electrónico), ¿utiliza una herramienta para verlos (y archivarlos y buscarlos)?

Tenga en cuenta que los proyectos de voluntarios tienden a ser más orientados a desarrolladores / contribuyentes que a usuarios en cierta medida. Esto tiene sentido ya que los primeros tienden a tener un tiempo limitado, mientras que los últimos obtienen algo "gratis".

Los proyectos con los que trabajé (principalmente relacionados con GNOME) tienden a tener una escasez real de mano de obra, por lo que cualquier cosa que ahorre tiempo o facilite la participación de los desarrolladores es una ventaja. Así que desde la perspectiva del desarrollador (en orden aleatorio):

• Los correos permiten el filtrado altamente personalizado que las personas usan ampliamente. Por ejemplo, todos los correos de ML para el proyecto que mantengo van directamente a mi bandeja de entrada y están etiquetados como tales. Para el ML menos importante van a una carpeta separada y saltan la información. Para otros solo uso NNTP + Gmane.
• Los correos electrónicos permiten MUA altamente personalizable desde interfaces web a programas muy complicados que permiten el filtrado, el resaltado de correos electrónicos importantes, la creación de tareas, etc. Permiten escribir partes de respuestas y automatizar ciertas partes.
• El acceso a ML tiene 0 fricciones para (por ejemplo) yo. No necesito crear una cuenta adicional. En la mayoría de los casos, solo me suscribo a través de NNTP en Gmane y, en muchos ML, solo envío un correo electrónico. Por otro lado, necesito crear una cuenta en el foro, crear una contraseña que sea a) segura, b) única [porque quién sabe si el foro no 'cifra' la contraseña mediante rot13] yc) cumple todos los requisitos [en menos 8 caracteres, incluidas mayúsculas y minúsculas y algunos caracteres especiales, pero no demasiado especiales como el punto, a menos que hoy sea martes cuando permitamos el punto ... y luego empecemos a dudar de que soy humano mientras intento resolver el CAPATCHA ;)
• Los correos electrónicos permiten agregar participantes a la secuencia cuando se necesitan. Por ejemplo, para la revisión de parches, puede agregar alguien al campo Para y preguntarle si no interferirá con su trabajo, etc. La mayoría de los foros no permiten tales cosas, al menos no con pocos clics como la mayoría de los MUA. Los correos también permiten eliminar a las personas de la discusión (haciendo una primera reverencia al enviarlas a BCC) para evitar el spamming.
• Argumentaría que, en algunos casos, la discusión con hilos puede tener ventajas. Sí, es complicado, etc., pero la revisión de parches puede dividirse en varias partes con respecto a diferentes problemas.
• La mayoría de las MUA tienen sistemas de notificación integrados que permiten juzgar como importante / spam / tratar con eso más adelante. Por otro lado, los foros, si tienen un sistema de notificación / suscripción, te obligan a ir al sitio web.
• SMTP / NNTP son estándares, tienen RFC y todo. Ya hay herramientas que se ejecutan contra ellos, por ejemplo, git puede enviar parches a ML pero no puede enviar a foros. Lo más cercano que escuché es el soporte ad-hoc para bugzilla.

... y no creo que la lista sea exhaustiva. Puedo ver por qué / cómo el flujo de trabajo podría no ser acogedor para los nuevos usuarios, sin mencionar los menos técnicos. Gnome tiene diferentes canales para que participen (G +, Fb y sí, foros) pero AFAIK rara vez tiene tiempo para que los desarrolladores participen en la comunidad allí, vuelvan a aprender las herramientas, etc.

Porque nadie ha creado una mejor manera de hacerlo. Por mejor me refiero adecuado y capaz de integrarse en los entornos de desarrollo actuales.

Tal vez Google Wave fue de alguna manera una herramienta más adecuada pero no despegó.

Hábito : varias personas publican preguntas sobre cómo generar interés en proyectos de código abierto. A veces empiezas con una lista de correo de personas que conoces y nunca cambias a otra cosa.

Para los usuarios:

• es más fácil quemar errores con el corrector ortográfico (gotcha)
• es más fácil quejarse de la lista de administradores
• Han memorizado los sitios 'alt' que recomiendan

Puede encontrar el chiste aquí: enlace