¿Encabezados para notificaciones por correo electrónico para que los usuarios de Gmail puedan filtrar por etiquetas?

Contribuir Característica
,
1

La publicación se cerró como duplicada Email: mail headers should have tags in them, posiblemente en referencia a Customs email headers and/or subjects tags, pero este último es bastante general y me gustaría hablar sobre un problema específico que tenemos:

Estamos usando etiquetas como el reemplazo más lógico para docenas de listas de correo sobre varios subtemas del proyecto. Comenzamos a usar categorías, pero eso se volvió difícil de manejar: las categorías son pesadas, no permiten la publicación cruzada fácil y, por una serie de otras razones, creemos que las etiquetas son una mejor opción.[1]

Sin embargo… hay un problema. Si bien es posible poner %{optional_tags} en la plantilla para las notificaciones por correo electrónico, el filtrado muy limitado de Gmail no hace nada inteligente con esto, e incluso para el usuario de correo de la vieja escuela, es un poco molesto escribir una regla de procmail que descomponga la línea de asunto y la analice.

Por lo tanto, sería bueno tener la etiqueta en otro lugar. Para la gente de procmail, un encabezado X-Tags personalizado serviría, pero a Gmail no le importará, así que necesitamos algo más.

Una idea sería usar las etiquetas como List-ID, pero no estoy seguro de que Gmail haga lo correcto con múltiples etiquetas List-ID no se permiten múltiples campos List-ID [2]. Otra idea, que es un poco chapucera pero creo que funcionaría: poner tag@subdominio.ejemplo.org (y potencialmente también tag2@subdominio.ejemplo.org, tag3@subdominio.ejemplo.org, …) en la lista CC. Google puede filtrar esto, y la mayoría de los otros sistemas también tienen características razonablemente avanzadas para tratar con CC como un campo multivalor. Y, redirigiríamos cualquier correo enviado a estas direcciones al vacío[3].

Como beneficio adicional, el enfoque CC podría usarse como una forma de agregar etiquetas al correo entrante (ver Add tags by email). De nuevo, un poco chapucero, pero bueno, todo el correo lo es, en 2022.

  1. Si desea discutir esto, puedo… ¡en otro hilo tema! ↩︎

  2. maldición, RFCE 2919! ↩︎

  3. es decir, /dev/null ↩︎

2 Me gusta
2

Estoy abierto a cualquier otra sugerencia o idea que tengan. No podemos sugerir razonablemente una mudanza a gran escala a Discourse sin esto.

3

Además, ¿por qué no hay #etiquetas aquí? :slight_smile:

4

Suena como que podrían funcionar, pero necesitarás un plugin personalizado.

5

¿Cuál es exactamente tu caso de uso?

Me interesaría saber por qué sientes la necesidad de ayudar a las personas a filtrar las notificaciones por correo electrónico de tu sitio. El uso previsto de Discourse es que los miembros de la comunidad simplemente utilicen las notificaciones por correo electrónico para ser informados cuando hay actividad que les interesa y hagan clic en el enlace para iniciar sesión cuando quieran participar en las discusiones. Para los sitios que lo desean, se puede habilitar la respuesta por correo electrónico. Pero el miembro aún debe tener el hábito de iniciar sesión para continuar la discusión en el sitio.

De esa manera, todos se benefician y pueden contribuir al esfuerzo colaborativo de organizar y gestionar las discusiones en el sitio. Y no terminas con un montón de discusiones desactualizadas aisladas en las carpetas de correo electrónico de todos. Cuando Discourse se usa según lo previsto, las notificaciones recibidas por correo electrónico simplemente se pueden eliminar.

El correo electrónico también es notoriamente difícil de hacer bien, y no solo para Discourse. Cuanto más consigas que tu comunidad inicie sesión y participe en tu sitio, más exitosa (y fácil de gestionar) será tu comunidad.

Tal vez Discourse no sea la opción correcta para tu comunidad, o necesites mantener operativas algunas listas de correo mientras desarrollas tu sitio de Discourse. Sé que puede ser difícil cambiar los hábitos de comunidades de larga data.

¡Buena suerte! :girasol:

2 Me gusta
6

Creo que eso podría ser correcto.

¿Todavía tienes gente de procmail? ¿Y gente de Gmail, y gente de Discourse? Mantener contentos a esos tres grupos será muy difícil.

Si tienes un presupuesto de $2000-5000, podrías conseguir un plugin personalizado que haga lo que pides, pero es difícil imaginar que sea satisfactorio para alguien. No sabes qué otros problemas surgirán una vez que resuelvas los que conoces ahora. Me recuerda a la gestión de listas de correo cuando un montón de gente usaba pasarelas de correo electrónico basadas en LAN que no seguían el RFC-822 (eso fue cuando usaba procmail y rmail de emacs). El problema es simplemente insostenible.

Recomendaría simplemente usar categorías. O, si realmente quieres listas de correo que sigan las convenciones de hace un par de décadas, quédate con lo que funciona.

2 Me gusta
7

Si estas características ya existen en otras plataformas que están basadas en el modelo tradicional de listas de correo, probablemente tendrás más éxito allí, en lugar de pedir que se adapten a un producto que está más orientado al futuro.

O, dicho de otra manera, si esto es un factor decisivo, ¿por qué considerar Discourse en primer lugar? ¿Podría HyperKitty extenderse para agregar la funcionalidad que necesitas?

1 me gusta
8

Objetivo

Actualmente, Fedora tiene cientos de listas de correo, con unas 90 con cierto grado de actividad, y un puñado que son muy activas. Quiero consolidar todo eso en un solo lugar, lo que incluye llevar a nuestra comunidad de colaboradores con éxito. Si hay una opción mejor que Discourse para esto, nadie la ha creado todavía.

Versión corta

He estado trabajando activamente en esto durante tres años y pensando en ello durante al menos diez. Al hablar con la gente de mi comunidad sobre lo que les bloquea, este tema específico ha surgido repetidamente.

Versión larga:

Aproximadamente al mismo tiempo que se lanzó Discourse[1], creamos una interfaz gráfica para Mailman3 llamada Hyperkitty, pensada como una interfaz web moderna que la gente pudiera usar para acceder a las listas de correo subyacentes. Puedes ver esto en acción en la Lista de Desarrollo de Fedora.

Hyperkitty tiene algunas ideas interesantes, pero no recibió financiación a la escala necesaria para tener éxito, y acabó lanzándose con el diseño inicial y sin previsión para mejorarlo y arreglarlo en uso real. Y, toma el correo electrónico como base subyacente, y eso realmente ató las cosas[2] — incluso si hubiéramos tenido los recursos, mantenerlo como el factor común más grande[3] habría sido un límite frustrante.

Así que entiendo dónde estás con esto. Si haces un viaje por la Wayback Machine a través del historial de discourse.org puedes ver[4] que Discourse se basó bastante en las lecciones aprendidas de los foros y las listas de correo y en reemplazar ambos…

2013

… y eso ha sobrevivido en gran medida hasta hoy, aunque hay menos otras conversaciones sobre listas de correo en las diversas páginas. Has pasado por lo mismo que nosotros habríamos pasado si hubiéramos tenido los recursos para invertir en Hyperkitty — el problema del correo electrónico como base demasiado baja — y has llegado a la conclusión lógica. Entiendo totalmente de dónde vienes al decir ahora explícitamente que llevar a la gente al sitio web es el uso correcto.

Actualmente:

  • Tenemos docenas de listas de correo activas
    • con cientos de participantes activos
    • y miles de suscriptores pasivos.
  • Estas listas se remontan literalmente a más de 20 años.
  • Mucha gente del mundo del código abierto está realmente apegada a esta forma de trabajar.
    • es familiar,
    • ya está configurado, y
    • llega a una rutina diaria sin necesidad de añadir “consultar algún sitio web”
  • mucha gente está activa en diferentes partes del proyecto, pero esa “huella” es muy individual

Pero:

I. Estas listas son menos funcionales de lo que mucha gente cree:

  • la moderación es casi imposible (un gran garrote de todo o nada en el mejor de los casos)
    • a pesar de los esfuerzos, la gente no siempre se adhiere a los estándares que esperamos
  • las mega-hilos no son una buena discusión
  • el acoso fuera de la lista es fácil de iniciar y está fuera de nuestro control
  • el posting cruzado es un desastre, ya que las suscripciones no son consistentes
  • imposible de seguir a menos que estés comprometido
  • la gente que debería participar no lo hace por diversas razones de las anteriores

II. El correo electrónico no es el futuro

  • Las listas de correo son en gran medida opacas para los motores de búsqueda y no parecen “actividad real” para la mayor parte del mundo
  • La gente nueva no quiere suscribirse a listas de correo.[5]
  • La “cultura” de las listas de correo ya no es realmente una cosa.[6]
    • Y la interfaz web de Gmail es activamente hostil a las convenciones tradicionales como las respuestas en línea.

III. El correo electrónico en general está condenado

  • Los grandes proveedores tienen la escala para “resolver” el spam por sí mismos, y ahora tienen un desincentivo para resolverlo a nivel mundial.
  • Los pequeños proveedores tienen cada vez menos posibilidades de entregar de forma fiable.
  • Las listas de correo publican inherentemente de nuevo, y toda la infraestructura de suscripción y verificación realmente no se preocupa.
  • Las empresas están cambiando a Slack y similares para la comunicación funcional, dejando el correo electrónico para anuncios y difusiones.
    • y Jira y github y demás para interacciones enfocadas en el flujo de trabajo.
  • De nuevo, la gente “normal” no lo usa para nada más que para recibir avisos de varias empresas de las que son clientes. Ya no es realmente para la comunicación personal.

Pero todavía hay una necesidad

Tenemos cubierta la conversación en tiempo real[7], pero todavía necesitamos las conversaciones largas y asíncronas que han proporcionado las listas de correo. El chat no lo cubre todo, no funciona bien a nivel mundial y con voluntarios con compromisos de tiempo variables. Y las herramientas de flujo de trabajo son demasiado estrechas.

Discourse es realmente la mejor opción

  • Las listas de correo no son un futuro viable.

  • Hyperkitty está atascado en 2014.

  • Tenemos demasiado para usar solo Github / Gitlab.

  • Otras posibilidades no sirven:

    • Ponymail sufre el mismo problema de correo electrónico como GCF
    • Vanilla no es genial. Lo dejaré ahí. :slight_smile:
    • Google Groups es lo peor de todo.

  • En el lado positivo para Discourse: muchas otras comunidades de código abierto se están consolidando a su alrededor. Notablemente: Python, GNOME…

Entra Casandra

No la base de datos — quiero decir, contar a la gente el fin del mundo pero que nadie crea. Escucho mucho “El correo electrónico funciona bien”, y “No veo ningún problema con las listas de correo”, y, por supuesto, “Odio los foros”, o incluso específicamente “No me gusta Discourse”.

Pero, realmente necesitamos un cambio.

Así que…

Necesito que una comunidad de código abierto grande, activa e importante mueva su plataforma principal de comunicaciones del proyecto a Discourse, y mucha gente es escéptica. Es un gran cambio. Quiero hacerlo lo más fácil posible, tanto para hacerlo más fácil y agradable para las personas escépticas pero dispuestas a intentarlo, como para hacerlo posible de intentar para las personas que tienen la interacción por correo electrónico — incluyendo el filtrado — como un bloqueo personal.

Creo que una vez que estén allí, mucha gente ajustará su comportamiento — conseguiremos que más gente descubra que interactuar directamente con el sitio no está tan mal.[8] Y tenemos nuestro propio sistema de notificación a nivel de proyecto que planeo vincular, y espero que eso eventualmente pueda dar a la gente más de lo que realmente necesitan.

Pero mientras tanto, yo necesito dar a la gente lo que está pidiendo.

  1. De hecho, intenté sugerir Discourse como un enfoque alternativo en ese momento, en lugar de desarrollar el nuestro propio. Si tuviera una máquina del tiempo, podría volver y presionarlo aún más. Pero no estaba en mi puesto actual en ese momento y la suerte estaba echada… ↩︎

  2. Lección similar de LUGNET, creo que el software de foro más increíble y sensato de los 90 — pero atado a NNTP como backend. ↩︎

  3. Sé que la expresión es “mínimo común denominador”, pero eso no tiene sentido. Como “me importa menos”, pero ahora también con matemáticas. ↩︎

  4. Quiero decir, si no lo recuerdas ya, ¡por supuesto! ↩︎

  5. En Corea, el correo electrónico es para gente mayor ¡ha llegado para todos nosotros! ↩︎

  6. No recuerdo la última vez que oí a alguien decir “netiqueta”. ↩︎

  7. usando Matrix, en https://chat.fedoraproject.org/… ↩︎

  8. Aunque, definitivamente tenemos esta persona, así que no será todo el mundo. ↩︎

5 Me gusta
10

¡Buena redacción! :ok_hand:

¿Puedes describir el filtrado del que hablas con un poco más de detalle que la gente utiliza en su correo electrónico? Yo también llevo tiempo en esto y he administrado listas de correo yo mismo y he participado (y sigo haciéndolo) en muchas listas de correo, pero nunca me he encontrado con filtrado automático usando encabezados. Me parece que si alguien se suscribe a una lista y quiere filtrarla en una carpeta de su correo, lo configuraría por sí mismo lista por lista. ¿Puedes hacer eso también con Discourse?

Creo que las categorías funcionan bastante bien como reemplazo de las listas de correo, con el modo de lista de correo habilitado por el usuario o el usuario siguiendo ciertas categorías para que reciba correos electrónicos por cada publicación. Quizás también necesitemos aprender un poco más sobre por qué crees que organizar las discusiones en etiquetas es mejor y vale la pena el esfuerzo para lograr la paridad con cómo funciona ya con las categorías.

Editar: ¡Me acuerdo de mi antigua publicación sobre esto, de 2014! :scream:

1 me gusta
11

Claro. Los encabezados que Discourse establece actualmente se ven así (de una notificación real de este hilo):

List-Unsubscribe: <https://meta.discourse.org/email/unsubscribe/efed8ca1777379c660afc031464b98eb4e6fa2323a71fa12fa2269eeca5b0905>
X-Discourse-Post-Id: 1216779
X-Discourse-Topic-Id: 249982
X-Auto-Response-Suppress: All
Auto-Submitted: auto-generated
Precedence: list
List-ID: Discourse Meta | feature <feature.meta.discourse.org>
List-Archive: https://meta.discourse.org/t/headers-for-email-notifications-so-that-gmail-users-can-filter-on-tags/249982
Feedback-ID: meta:user_replied:discoursemail

Si no fuera por Gmail, añadir algo como:

X-Discourse-Tags: some-tag, another-tag

Ver Customs email headers and/or subjects tags - #6 by mattdm — si la configuración email custom headers se pasara a través de la expansión de plantillas para que X-Discourse-Tags: %{optional_tags} funcionara, esta parte ya funcionaría.

Y, para los usuarios de procmail y otros clientes de correo electrónico de la vieja escuela, esto sería suficiente. Desafortunadamente, por las razones inescrutables de Google, Gmail no puede filtrar por etiquetas arbitrarias y está (hasta donde yo sé) limitado a To:, From:, Cc: y… afortunadamente al menos, List-ID. Dado que ese es el elefante en la habitación, para acomodar a esos usuarios, establecer List-ID por etiqueta en lugar de categoría (¿o en combinación?) es lo mejor que se me ocurre.

Sin embargo, RFC 2919 dice que solo se permite un List-ID por mensaje. Así que eso deja::

  1. Elegir una etiqueta arbitrariamente[1]
  2. Generar algo que incluya todas las etiquetas, como List-ID: firsttag_secondtag.discourse.example.org y dejar que los usuarios lo descubran. [2]
  3. Generar múltiples correos electrónicos por notificación, uno por cada etiqueta y que solo difiera en este encabezado[3]
  4. Dejar que List-ID se refiera a la categoría, y en su lugar usar la idea de CC… [4]

Realmente no me gusta ninguna de esas opciones. Así que, como primer paso, X-Discourse-Tags: al menos cubriría a los usuarios que no usan Gmail. (Lo que probablemente es una buena superposición con los usuarios resistentes a la web, así que creo que vale la pena hacerlo para ver hasta dónde llegamos).

  1. ¡confuso! ↩︎

  2. no es genial ↩︎

  3. tampoco es genial ↩︎

  4. Muy chapucero. Simplemente añadir Cc: %{optional_tags}[4] no serviría, porque necesitaría ser expandido para que cada etiqueta correspondiera a una dirección de correo electrónico real (agujero negro). ↩︎

3 Me gusta
12

¡Sí, mucho! ¡Tu último párrafo resume las cosas muy bien!

2 Me gusta
13

Muy a favor de añadir X-Discourse-Tags y X-Discourse-Category (para paridad).

Supongo que a largo plazo para Gmail podríamos añadir una opción de usuario:

  • Por favor, añade todas las etiquetas a las que pertenece este tema en los títulos de los temas enviados por correo electrónico.

Por ejemplo, algo así:

[Discourse Meta] [feature] [email] [notifications] Encabezado para notificaciones por correo electrónico

O quizás cuando esté habilitado:

[Discourse Meta] Encabezado para notificaciones por correo electrónico … [feature] [email] [notifications]

5 Me gusta
14

Sí, eso sería interesante como una opción para el usuario. Actualmente tenemos esto en todo el sitio:

%{optional_re}%{topic_title} [Fedora] %{optional_pm}%{optional_tags}

Recibimos comentarios fuertes de que poner las etiquetas en cualquier lugar que no fuera al final era molesto. Y algunos comentarios de que Google no es muy inteligente al filtrar de manera útil en líneas de asunto parciales.

No estoy seguro de cuánto podemos “arreglar” Google (O más bien, estoy bastante seguro, y es “no mucho”). Así que puede haber un grado de “bueno, qué se le va a hacer” que tendré que convencer a la gente para que acepte.

4 Me gusta
15

Hay algunas cosas menores que podemos hacer para mejorar la situación.

En este momento estamos

  1. Limitando a 3 (orden arbitrario)
  2. No envolviendo las etiquetas en [ ]

Estoy indeciso, pero creo que el límite arbitrario de 3 no es bueno, deberíamos simplemente eliminarlo.

Además, tags.map{|t| "[#{t}]"}.join(" ") sería mejor porque entonces el filtro puede ser en [tagname] en lugar de tagname, que es mucho más probable que aparezca en el título del MP.

@martin ¿opiniones?

5 Me gusta
16

Eso tiene más sentido conociendo la historia. Parece que tienes un presupuesto para hacer que las cosas sucedan, y algunas buenas ideas para acercarte un poco al principio. Creo que será difícil, y importar todos los datos será un desafío. Aún así será difícil hacer felices a todas esas personas y Sam está de acuerdo con al menos algunas de tus ideas, por lo que entrarán en el núcleo y no se romperán en el futuro, como probablemente sucedería con un plugin.

3 Me gusta
17

Estoy de acuerdo contigo aquí, aunque creo que en lugar de eliminar el límite por completo, ¿podríamos simplemente usar la configuración max_tags_per_topic? Creo que sería más seguro.

Desafortunadamente, agregar [] alrededor de las etiquetas no ayudará mucho con la búsqueda de Gmail, solo visualmente, ya que por lo que puedo ver (por ejemplo, mira https://webapps.stackexchange.com/questions/52828/create-gmail-filter-that-contains-a-special-character, la documentación enlazada ya no está pero sigue siendo válida) Gmail elimina los caracteres especiales al buscar en el asunto y en otros lugares. Intenta buscar subject:("[support]") en Gmail, obtendrás todo lo que tenga “support” en el asunto, no solo los que tengan corchetes. Esto es un poco absurdo por parte de Google, ya que son una empresa de búsqueda (bueno, de búsqueda y publicidad), pero no hay nada que podamos hacer al respecto.

También deberíamos poder agregar fácilmente X-Discourse-Tags y X-Discourse-Category al mismo tiempo en MessageBuilder, ya que ya tenemos esas opciones en este momento, y como dices @mattdm, esto cubre bien a los usuarios resistentes a la web:

¿Puedo encargarme de esto si quieres?

5 Me gusta
21

Acabo de fusionar esto @mattdm:

No ayuda mucho con Gmail, pero al menos esto debería ayudar a los usuarios de correo electrónico basados en terminal para que puedan filtrarlos más fácilmente.

6 Me gusta
22

Nota @mattdm, realmente lo intentamos, pero Gmail es simplemente muy difícil. Elimina mucho del texto al tokenizar, tus manos están bastante atadas.

La única solución que se me ocurre es hacer que los nombres de las etiquetas sean súper feos en los correos electrónicos:

“Este es un asunto de demostración. [Temail, Tnotifications]” (prefijo T o alguna otra secuencia alfa que a Gmail le “guste”)

Pero es una solución bastante fea y poco intuitiva.

3 Me gusta
23

Gracias Sam (¡y a todos!).

Aprecio todo el esfuerzo invertido en esto. Al final, solo podemos luchar contra las inescrutables decisiones de Google hasta cierto punto.

Sí, en serio. Lo único que se me ocurre hacer más sería añadir una opción por usuario:

Hacer que las líneas de asunto de las notificaciones por correo electrónico contengan nombres de etiquetas en un formato súper feo en el que Gmail pueda filtrar.

:-/

5 Me gusta