En-têtes pour les notifications par e-mail afin que les utilisateurs de Gmail puissent filtrer par balises ?

Contribuer Fonctionnalité
,
1

Le post a été fermé comme doublon Email: mail headers should have tags in them, possiblement en référence à Customs email headers and/or subjects tags, mais ce dernier est plutôt général, et j’aimerais discuter d’un problème spécifique que nous avons :

Nous utilisons les tags comme le remplacement le plus logique pour des dizaines de listes de diffusion sur divers sous-thèmes de projet. Nous avons commencé à utiliser des catégories, mais cela est devenu ingérable — les catégories sont lourdes, ne permettent pas de publications croisées faciles, et pour toute une série d’autres raisons, nous pensons que les tags correspondent mieux.[1]

Cependant… il y a un problème. Bien qu’il soit possible de mettre %{optional_tags} dans le modèle pour les notifications par e-mail, le filtrage très limité de Gmail ne fait rien d’intelligent avec cela — et, même pour l’utilisateur de courrier électronique à l’ancienne, c’est un peu pénible d’écrire une règle procmail qui décompose la ligne d’objet et l’analyse.

Il serait donc agréable d’avoir le tag ailleurs. Pour les personnes utilisant procmail, un en-tête X-Tags personnalisé suffirait, mais Gmail ne s’en souciera pas, nous avons donc besoin d’autre chose.

Une idée serait d’utiliser réellement les tags comme List-ID, mais je ne suis pas sûr que Gmail fasse la bonne chose avec plusieurs tags List-ID plusieurs champs List-ID ne sont pas autorisés [2]. Une autre idée, un peu bancale mais qui, je pense, fonctionnerait : mettre tag@sousdomaine.example.org (et potentiellement aussi tag2@sousdomaine.example.org, tag3@sousdomaine.example.org, …) dans la liste CC. Google peut filtrer sur cela, et la plupart des autres systèmes ont également des fonctionnalités raisonnablement avancées pour traiter le CC comme un champ multi-valeurs. Et, nous redirigerions tout e-mail réellement envoyé à ces adresses vers le néant[3].

En bonus, l’approche CC pourrait être utilisée comme moyen d’ajouter des tags aux e-mails entrants (voir Add tags by email). Encore une fois, un peu bancale, mais bon, tout l’e-mail l’est, en 2022.

  1. Si vous souhaitez en discuter, je peux… dans un autre fil sujet ! ↩︎

  2. Maudit soit RFCE 2919! ↩︎

  3. c’est-à-dire /dev/null ↩︎

2 « J'aime »
2

Je suis ouvert à toute autre suggestion ou idée que vous pourriez avoir. Nous ne pouvons pas raisonnablement suggérer une migration à grande échelle vers Discourse sans cela.

3

De plus, pourquoi n’y a-t-il pas de tags ici ? :slight_smile:

4

Il semble qu’ils pourraient fonctionner, mais vous aurez besoin d’un plugin personnalisé.

5

Quelle est exactement votre étude de cas ?

Je serais intéressé d’apprendre pourquoi vous ressentez le besoin d’aider les gens à filtrer les notifications par e-mail de votre site. L’utilisation prévue de Discourse est que les membres de la communauté utilisent simplement les notifications par e-mail pour être informés lorsqu’il y a une activité qui les intéresse et cliquent sur le lien pour se connecter lorsqu’ils souhaitent participer aux discussions. Pour les sites qui le souhaitent, la réponse par e-mail peut être activée. Mais le membre doit toujours avoir l’habitude de se connecter pour poursuivre la discussion sur le site.

De cette façon, tout le monde bénéficie de l’effort collaboratif d’organisation et de gestion des discussions sur le site et peut y contribuer. Et vous n’obtenez pas un tas de discussions obsolètes cloisonnées dans les dossiers de messagerie de chacun. Lorsque Discourse est utilisé comme prévu, les notifications reçues par e-mail peuvent simplement être supprimées.

L’e-mail est également notoirement difficile à maîtriser, et pas seulement pour Discourse. Plus vous parvenez à faire en sorte que votre communauté se connecte et s’engage sur votre site, plus votre communauté sera prospère (et facile à gérer).

Peut-être que Discourse n’est pas le bon choix pour votre communauté, ou que vous devez maintenir quelques listes de diffusion opérationnelles pendant que vous développez votre site Discourse ? Je sais qu’il peut être difficile de changer les habitudes des communautés de longue date.

Bonne chance ! :sunflower:

2 « J'aime »
6

Je pense que cela pourrait être juste.

Vous avez encore des utilisateurs de procmail ? Et des utilisateurs de Gmail, et des utilisateurs de Discourse ? Satisfaire tous ces groupes sera très difficile en effet.

Si vous avez un budget de 2000 à 5000 $, vous pourriez obtenir un plugin personnalisé qui fait ce que vous demandez, mais il est difficile d’imaginer que ce sera satisfaisant pour qui que ce soit. Vous ne savez pas quels autres problèmes surviendront une fois que vous aurez résolu ceux que vous connaissez maintenant. Cela me rappelle la gestion des listes de diffusion lorsqu’un grand nombre de personnes utilisaient des passerelles de messagerie basées sur le réseau local qui ne suivaient pas la RFC-822 (c’est à l’époque où j’utilisais procmail et rmail d’emacs). Le problème est tout simplement intenable.

Je recommanderais de vous en tenir aux catégories. Ou, si vous voulez vraiment des listes de diffusion qui suivent les conventions d’il y a quelques décennies, contentez-vous de ce qui fonctionne.

2 « J'aime »
7

Si ces fonctionnalités existent déjà sur d’autres plateformes basées sur le modèle traditionnel des listes de diffusion, vous aurez probablement plus de succès là-bas, au lieu de demander qu’elles soient adaptées à un produit plus tourné vers l’avenir.

Ou, pour le dire autrement, si c’est un point rédhibitoire, pourquoi envisager Discourse en premier lieu ? HyperKitty pourrait-il être étendu pour ajouter la fonctionnalité dont vous avez besoin ?

1 « J'aime »
8

Objectif

Actuellement, Fedora compte des centaines de listes de diffusion, dont environ 90 sont plus ou moins actives, et une poignée sont très actives. Je veux tout consolider en un seul endroit, ce qui inclut d’accompagner notre communauté de contributeurs avec succès. S’il existe une meilleure option que Discourse pour cela, personne ne l’a encore créée.

Version courte

Je travaille activement sur ce sujet depuis trois ans et j’y réfléchis depuis au moins dix ans. En parlant aux membres de ma communauté de ce qui les bloque, ce point spécifique est revenu à plusieurs reprises.

Version longue :

À peu près à la même époque où Discourse a été lancé[^1], nous avons créé une interface graphique pour Mailman3 appelée Hyperkitty, conçue pour être une interface web moderne que les gens pourraient utiliser pour accéder aux listes de diffusion sous-jacentes. Vous pouvez le voir en action pour la Liste Fedora Devel.

Hyperkitty a quelques idées intéressantes, mais n’a pas été financé à l’échelle nécessaire pour réussir, et a fini par être lancé avec la conception initiale et aucune disposition pour l’améliorer et le corriger en utilisation réelle. De plus, il prend l’e-mail comme base sous-jacente, ce qui a vraiment limité les choses[^2] — même si nous avions eu les ressources, s’en tenir à cela comme plus grand dénominateur commun[^3] aurait constitué une limite frustrante.

Je comprends donc où vous en êtes. Si vous faites un voyage dans le temps avec Wayback Machine sur l’historique de discourse.org, vous pouvez voir[^4] que Discourse s’est fortement appuyé sur les leçons apprises des forums et des listes de diffusion et les a remplacés tous les deux…

2013

… et cela a largement survécu jusqu’à aujourd’hui, bien qu’il y ait moins de discussions autres sur les listes de diffusion dans les différentes pages. Vous avez vécu la même chose que nous aurions vécue si nous avions eu les ressources pour investir dans Hyperkitty — le problème de l’e-mail comme base trop basse — et êtes arrivé à la conclusion logique. Je comprends totalement votre démarche actuelle qui consiste à dire explicitement que le fait d’amener les gens sur le site web est l’utilisation appropriée.

Actuellement :

  • Nous avons des dizaines de listes de diffusion actives
    • avec des centaines de participants actifs
    • et des milliers de souscripteurs passifs.
  • Ces listes remontent littéralement à plus de 20 ans.
  • De nombreuses personnes de l’open source à l’ancienne sont très attachées à cette façon de travailler.
    • c’est familier,
    • déjà mis en place, et
    • arrive dans une routine quotidienne sans avoir besoin d’ajouter “vérifier un site web”
  • de nombreuses personnes sont actives dans différentes parties du projet, mais cette “empreinte” est très individuelle

Mais :

I. Ces listes sont moins fonctionnelles que beaucoup de gens ne le pensent :

  • la modération est quasi impossible (au mieux un gros bâton tout ou rien)
    • malgré les efforts, les gens ne respectent pas toujours les normes que nous attendons
  • les méga-fils ne sont pas de bonnes discussions
  • le harcèlement hors liste est facile à lancer et hors de notre contrôle
  • le cross-posting est un désordre, car les abonnements ne sont pas cohérents
  • impossible de suivre sauf si on est engagé
  • les personnes qui devraient participer ne le font pas pour diverses raisons parmi celles ci-dessus

II. L’e-mail n’est pas l’avenir

  • Les listes de diffusion sont largement opaques pour les moteurs de recherche et ne ressemblent pas à une “activité réelle” pour la plupart du monde
  • Les nouvelles personnes ne veulent pas s’inscrire à des listes de diffusion.[^5]
  • La “culture” des listes de diffusion n’est plus vraiment une chose.[^6]
    • Et l’interface web de Gmail est activement hostile aux conventions traditionnelles comme les réponses en ligne.

III. L’e-mail en général est condamné

  • Les grands fournisseurs ont l’échelle nécessaire pour “résoudre” le spam pour eux-mêmes, et ont maintenant une anti-incitation à le résoudre globalement.
  • Les petits fournisseurs ont de moins en moins de chances de délivrer de manière fiable.
  • Les listes de diffusion republient intrinsèquement, et toute l’infrastructure de signature et de vérification ne s’en soucie pas vraiment.
  • Les entreprises passent à Slack et autres pour la communication fonctionnelle, laissant l’e-mail pour les annonces et les diffusions.
    • et Jira et github et autres pour les interactions axées sur le flux de travail.
  • Encore une fois, les gens “normaux” ne l’utilisent que pour recevoir des notifications de diverses entreprises dont ils sont clients. Ce n’est plus vraiment pour la communication personnelle.

Mais il y a toujours un besoin

Nous avons couvert la conversation en temps réel[^7], mais nous avons toujours besoin des conversations longues et asynchrones que les listes de diffusion ont fournies. Le chat ne couvre pas tout, ne fonctionne pas bien à l’échelle mondiale et avec des bénévoles aux engagements variés. Et les outils de flux de travail sont trop étroits.

Discourse est vraiment la meilleure option

  • Les listes de diffusion ne sont pas un avenir viable.

  • Hyperkitty est bloqué en 2014.

  • Nous avons trop pour utiliser simplement Github / Gitlab.

  • Les autres possibilités ne conviennent pas :

    • Ponymail souffre du même problème d’e-mail comme plus grand dénominateur commun
    • Vanilla n’est pas génial. Je m’arrêterai là. :slight_smile:
    • Google Groups est le pire de tout.

  • Du côté positif pour Discourse : de nombreuses autres communautés open source se consolident autour de lui. Notamment : Python, GNOME…

Entrez Cassandre

Pas la base de données — je veux dire, dire aux gens le malheur mais que personne ne croit. J’entends beaucoup de “L’e-mail fonctionne bien”, et “Je ne vois pas de problème avec les listes de diffusion”, et, bien sûr, “Je déteste les forums”, ou même spécifiquement “Je n’aime pas Discourse”.

Mais, nous avons vraiment besoin de changement.

Alors…

Je dois faire en sorte qu’une grande communauté open source active et importante déplace sa plateforme de communication principale vers Discourse, et beaucoup de gens sont sceptiques. C’est un grand changement. Je veux rendre cela aussi facile que possible, à la fois pour rendre les choses plus faciles et plus agréables pour les personnes sceptiques mais disposées à essayer, et pour rendre possible l’essai pour les personnes pour qui l’interaction par e-mail — y compris le filtrage — est un blocage personnel.

Je pense que une fois qu’ils seront là, beaucoup de gens ajusteront leurs comportements — nous aurons plus de personnes qui découvriront qu’interagir directement avec le site n’est pas si mal.[^8] Et nous avons notre propre système de notification à l’échelle du projet que j’ai l’intention de lier, et j’espère que cela pourra éventuellement donner aux gens ce dont ils ont vraiment besoin.

Mais en attendant, je dois donner aux gens ce qu’ils demandent.

[^1] : J’ai en fait essayé de suggérer Discourse comme approche alternative à l’époque, plutôt que de développer notre propre solution. Si j’avais une machine à remonter le temps, je pourrais y retourner et insister encore plus. Mais je n’étais pas dans mon rôle actuel à ce moment-là et le sort en était jeté…
[^2] : Leçon similaire de LUGNET, je pense le logiciel de forum le plus incroyable et le plus sensé des années 90 — mais lié à NNTP comme backend.
[^3] : Je connais l’expression “plus petit dénominateur commun” mais cela n’a aucun sens. Comme “je pourrais moins m’en soucier”, mais maintenant aussi avec des mathématiques.
[^4] : Je veux dire, si vous ne vous en souvenez pas déjà, bien sûr !
[^5] : En Corée, l’e-mail est pour les personnes âgées est venu pour nous tous !
[^6] : Je ne me souviens pas de la dernière fois que j’ai entendu quelqu’un dire “netiquette”.
[^7] : en utilisant Matrix, à https://chat.fedoraproject.org/…
[^8] : Bien que, nous ayons certainement cette personne, donc ce ne sera pas tout le monde.

5 « J'aime »
10

Belle rédaction ! :ok_hand:

Pouvez-vous décrire plus en détail le filtrage dont vous parlez et sur lequel les gens s’appuient dans leurs e-mails ? J’ai aussi une longue expérience et j’ai géré moi-même des listes Mailman et participé (et je participe toujours) à de nombreuses listes de diffusion, mais je n’ai jamais rencontré de filtrage automatique utilisant les en-têtes. Il me semble que si quelqu’un s’abonne à une liste et souhaite la filtrer dans un dossier de sa messagerie, il le configurerait lui-même, liste par liste. Vous pouvez faire cela aussi avec Discourse, n’est-ce pas ?

Je pense que les catégories fonctionnent très bien en remplacement des listes de diffusion, avec le mode liste de diffusion activé par l’utilisateur ou l’utilisateur suivant certaines catégories afin de recevoir un e-mail pour chaque publication. Peut-être devons-nous également en apprendre davantage sur les raisons pour lesquelles vous pensez que l’organisation des discussions en tags est meilleure et vaut la peine d’être mise en œuvre pour être à parité avec le fonctionnement actuel des catégories.

Edit : Je me souviens de mon ancien post à ce sujet, datant de 2014 ! :scream:

1 « J'aime »
11

Bien sûr. Les en-têtes que Discourse définit actuellement ressemblent à ceci (provenant d’une notification réelle de ce fil de discussion) :

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 ce n’était pas pour Gmail, ajouter quelque chose comme :

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

Voir Customs email headers and/or subjects tags - #6 by mattdm — si le paramètre email custom headers était passé par expansion de modèle afin que X-Discourse-Tags: %{optional_tags} fonctionne, cette partie fonctionnerait déjà.

Et, pour les utilisateurs de Procmail et d’autres clients de messagerie à l’ancienne, ce serait suffisant. Malheureusement, pour des raisons obscures de Google, Gmail ne peut pas filtrer sur des balises arbitraires et est (à ma connaissance) limité à To:, From:, Cc: et… heureusement au moins, List-ID. Comme c’est le gorille de 800 livres, pour satisfaire ces utilisateurs, définir List-ID par balise au lieu de catégorie (ou, en combinaison ?) est le mieux que je puisse imaginer.

Cependant, RFC 2919 stipule qu’un seul List-ID est autorisé par message. Il reste donc :

  1. Choisir une balise arbitrairement[1]
  2. Générer quelque chose incluant toutes les balises, comme List-ID: firsttag_secondtag.discourse.example.org et laisser les utilisateurs le découvrir. [2]
  3. Générer plusieurs e-mails par notification, un pour chaque balise et ne différant que par cet en-tête[3]
  4. Laisser List-ID se référer à la catégorie, et utiliser plutôt l’idée du CC… [4]

Je n’aime vraiment aucune de ces options. Donc, dans un premier temps, X-Discourse-Tags: couvrirait au moins les utilisateurs non-Gmail. (Ce qui est probablement un bon chevauchement avec les utilisateurs résistants au web, donc je pense que cela vaut la peine d’essayer pour voir jusqu’où cela nous mène.)

  1. confus ! ↩︎

  2. pas terrible ↩︎

  3. pas terrible non plus ↩︎

  4. Très bancal. Le simple ajout de Cc: %{optional_tags}[4] ne suffirait pas, car il faudrait l’étendre pour que chaque balise corresponde à une véritable adresse e-mail (trou noir). ↩︎

3 « J'aime »
12

Oui, tout à fait ! Votre dernier paragraphe résume bien les choses !

2 « J'aime »
13

Très favorable à l’ajout de X-Discourse-Tags et X-Discourse-Category (pour la parité)

Je suppose qu’à long terme pour Gmail, nous pourrions ajouter une option utilisateur :

  • Veuillez ajouter toutes les balises auxquelles ce sujet appartient dans les titres des sujets envoyés par e-mail.

Par exemple, quelque chose comme :

[Discourse Meta] [feature] [email] [notifications] Header for email notifications

Ou peut-être lorsque l’option est activée :

[Discourse Meta] Header for email notifications … [feature] [email] [notifications]

5 « J'aime »
14

Oui, ce serait intéressant comme option utilisateur. Nous avons actuellement ceci sur l’ensemble du site :

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

Nous avons reçu des retours forts indiquant que placer les balises ailleurs qu’à la fin était agaçant. Et quelques retours indiquant que Google n’est pas très intelligent pour filtrer utilement sur des lignes d’objet partielles.

Je ne suis pas sûr de ce que nous pouvons « corriger » chez Google, (Ou plutôt, je suis assez sûr, et c’est « pas grand-chose »). Il se peut donc qu’il y ait un certain degré de « tant pis » que je devrai convaincre les gens d’accepter.

4 « J'aime »
15

Il y a quelques petites choses que nous pouvons faire pour améliorer la situation.

Pour le moment, nous :

  1. Limitons à 3 (ordre arbitraire)
  2. N’encadrons pas les balises par [ ]

Je suis indécis, mais je pense que la limite arbitraire de 3 n’est pas idéale, nous devrions simplement la supprimer.

De plus, tags.map{|t| \"[#{t}]\"}.join(\" \") serait mieux car le filtre pourrait alors porter sur [tagname] plutôt que sur tagname, qui est beaucoup plus susceptible d’apparaître dans le titre du MP.

@martin, qu’en penses-tu ?

5 « J'aime »
16

Cela a plus de sens en connaissant l’histoire. Il semble que vous ayez un budget pour que les choses se fassent, et de bonnes idées pour commencer. Je pense que ce sera difficile, et l’importation de toutes les données sera un défi. Il sera toujours difficile de satisfaire tout le monde et Sam est d’accord avec au moins quelques-unes de vos idées, donc elles feront partie du cœur et ne seront pas cassées à l’avenir comme ce serait probablement le cas pour un plugin.

3 « J'aime »
17

Je suis d’accord avec vous ici, bien que je pense que plutôt que de supprimer complètement la limite, nous puissions simplement nous appuyer sur le réglage max_tags_per_topic ? Je pense que ce serait plus sûr.

Malheureusement, ajouter des [] autour des tags n’aidera pas beaucoup la recherche Gmail, seulement visuellement, car d’après ce que je peux voir (par exemple, regardez https://webapps.stackexchange.com/questions/52828/create-gmail-filter-that-contains-a-special-character, la documentation liée n’est plus là mais elle est toujours valide), Gmail supprime les caractères spéciaux lors de la recherche dans le sujet et d’autres endroits. Essayez de rechercher subject:(\"[support]\") dans Gmail, vous obtiendrez tout ce qui contient support dans le sujet, pas seulement ceux avec des crochets. C’est un peu absurde de la part de Google de faire cela, ils sont une entreprise de recherche après tout (enfin, recherche et publicité), mais il n’y a rien que nous puissions faire à ce sujet.

Nous devrions également pouvoir ajouter facilement X-Discourse-Tags et X-Discourse-Category en même temps dans MessageBuilder puisque nous avons déjà ces options à l’heure actuelle, et comme vous le dites @mattdm, cela couvre bien les utilisateurs résistants au web :

Je peux m’en charger si vous voulez ?

5 « J'aime »
21

J’ai juste fusionné ceci @mattdm :

Cela n’aide pas énormément avec Gmail, mais cela devrait au moins aider les utilisateurs d’e-mails basés sur le terminal afin qu’ils puissent les filtrer plus facilement.

6 « J'aime »
22

Note @mattdm nous avons vraiment essayé, mais Gmail est tout simplement si difficile. Il supprime tellement de choses du texte lors de la tokenisation, vos mains sont liées très durement.

La seule solution de contournement à laquelle je puisse penser est de rendre les noms de balises très laids dans les e-mails :

« Ceci est un sujet de démonstration. [Temail, Tnotifications] » (préfixe T ou une autre séquence alpha que Gmail « aime »)

Mais c’est une solution plutôt laide et peu intuitive.

3 « J'aime »
23

Merci Sam (et à tous !).

J’apprécie tous les efforts déployés. Au final, il n’y a pas grand-chose que nous puissions faire contre les choix impénétrables de Google.

Ouais, sérieusement. La seule chose que je puisse imaginer faire de plus serait d’ajouter une option par utilisateur :

Faire en sorte que les lignes d’objet des notifications par e-mail contiennent les noms de balises dans un format très laid sur lequel Gmail peut filtrer.

:-/

5 « J'aime »