Demande de fonctionnalité : étendre automatiquement un sujet lorsqu'un objet d'e-mail correspond à son titre

Contribuer Fonctionnalité
1

Actuellement, si deux e-mails ayant le même objet sont envoyés vers une catégorie Discourse donnée, chacun crée son propre sujet avec l’objet comme titre. Cela finit par générer plusieurs sujets portant le même titre, indépendamment du fait que l’option de configuration « Autoriser les sujets avec des titres identiques ou dupliqués… » soit cochée ou non, ce qui peut entraîner une multitude de sujets ayant le même titre.

Voici ce que je demande : que les messages générés par e-mail soient automatiquement fusionnés dans un sujet existant lorsqu’ils partagent son objet, si l’option « Autoriser les sujets avec des titres identiques ou dupliqués si la catégorie est différente » est décochée (ou en ajoutant une nouvelle option « Fusionner les messages envoyés par e-mail dans un sujet existant lorsque son objet correspond au titre du sujet »). Cela permettrait d’éviter les titres dupliqués au sein d’une catégorie tout en autorisant l’accumulation de plusieurs e-mails dans un seul sujet lorsqu’ils partagent un même objet (que ce soit intentionnellement ou par accident).

En pratique, cela se pose pour nous lorsque nous utilisons des scripts qui génèrent des messages destinés à être liés les uns aux autres sous un seul sujet, comme « telle configuration de test a échoué » ou « quelqu’un a mentionné xyz sur Reddit ». Il serait idéal que tous les e-mails partageant un tel objet soient regroupés sous un seul sujet plutôt que de créer un nouveau sujet par e-mail, chacun avec un titre identique. Cela permettrait également à quelqu’un d’ajouter un nouveau message à un sujet donné par e-mail, sans nécessairement devoir répondre à un e-mail le notifiant d’un message précédent dans ce sujet, pour les personnes qui pourraient avoir besoin d’écrire par e-mail plutôt que via l’interface web pour une raison ou une autre.

Je pense que le risque d’inconvénients dans les cas où des humains envoient accidentellement des e-mails dont l’objet correspond par hasard à un sujet existant dont ils n’ont pas connaissance est faible. Principalement parce que je suppose que si leur ligne d’objet correspond au titre d’un sujet préexistant, c’est en raison d’une similitude de contenu, il ne semble donc pas problématique de prolonger le sujet existant plutôt que de créer un nouveau sujet avec un titre dupliqué. De plus, un administrateur de site pourrait toujours cocher la case « autoriser les sujets avec le même titre… » s’il souhaitait le comportement actuel où chaque nouvel e-mail crée un nouveau sujet.

Cette fonctionnalité serait extrêmement utile pour notre site Discourse, et je suppose probablement pour d’autres aussi. Merci de votre considération, et pour tout le travail d’ingénierie remarquable qui a évidemment été investi dans Discourse.

Topics with same title, generated from mail
2

Je pense que cela dépend fortement de la communauté ; comme vous l’avez admis vous-même, des collisions non intentionnelles se produiraient. Quel intérêt y a-t-il à avoir un nombre plus restreint de sujets beaucoup plus longs ?

Pour des communautés comme Meta, cela signifierait que tout utilisateur qui envoie un e-mail avec le sujet « problèmes de configuration de Mailgun » continuerait à être notifié des mises à jour des mois, voire des années, après avoir résolu son problème. Cela ne semble pas pratique.

L’objectif est d’éviter les titres dupliqués, ce que le paramètre actuel impose pour les sujets créés directement sur le site, car l’utilisateur peut recevoir un retour d’information au moment de la création du sujet. Ce paramètre n’est pas respecté pour les utilisateurs qui envoient des e-mails, car il n’y a pas cette opportunité de retour immédiat.

3

Merci de t’être engagé avec moi à ce sujet, @Stephen.

Je pense que cela dépend beaucoup de la communauté

Je suis d’accord. C’est pourquoi je propose que cela soit contrôlé par une case à cocher dans les paramètres (soit en réutilisant l’une des cases existantes relatives à l’interdiction des titres en double, soit en en ajoutant une nouvelle).

Quel est l’intérêt d’avoir un nombre plus faible de sujets beaucoup plus longs ?

Pour donner un contexte, sur notre site Discourse, nous avons une catégorie « Notifications », dont chaque sous-catégorie reçoit des courriels envoyés par des scripts lors de certains événements (par exemple, des échecs de test, de nouveaux tickets signalés, de nouvelles questions publiées sur Stack Overflow, de nouvelles mentions de notre projet sur des sites de discussion, etc.). Ces catégories sont conçues pour permettre aux membres de la communauté de suivre et de discuter de types d’événements particuliers qui peuvent les intéresser.

Dans certains cas, les courriels générés par nos scripts ont des lignes d’objet prévisibles et déterministes par conception, comme « linux64 testing ». Par exemple, si nous avons un nouvel échec dans nos tests linux64 le 15 août, cela génère un courriel. Si d’autres échecs surviennent le 16 août, cela génère un deuxième courriel avec la même ligne d’objet. Ensuite, si tous les échecs sont résolus le 17 août, un troisième courriel avec la même ligne d’objet est généré pour indiquer la résolution. Puis, si de nouveaux échecs surviennent le 31 août, nous générons un quatrième courriel avec la même ligne d’objet, et un cinquième lorsque l’échec est résolu.

Avec le comportement actuel du site, chacun de ces courriels génère un tout nouveau sujet nommé « linux64 testing », sans aucun lien ni relation entre eux, ce qui rend difficile pour les humains de corréler les événements ou de décider de l’un des cinq sujets à utiliser pour un suivi de discussion sur les échecs. Alors que ce que nous souhaitons, c’est que les cinq courriels (et toute discussion utilisateur qui s’y déroule) apparaissent comme des messages au sein d’un seul et même sujet, afin qu’un développeur puisse examiner tous les échecs de test d’une configuration donnée dans un seul sujet, organisé chronologiquement.

Un autre impact du comportement actuel de Discourse est qu’une personne recevant des notifications par courriel pour la catégorie ou le sujet en question voit cinq fils de discussion non liés dans sa boîte de réception, tous nommés « linux64 testing ». Alors que si Discourse fusionnait ces éléments en un seul sujet, cette personne verrait tous les messages « linux64 testing » associés comme un seul fil dans son lecteur de courriels, ce qui rendrait la navigation beaucoup plus facile et plus proche d’une conversation traditionnelle.

Nous exécutons plusieurs dizaines de configurations de test chaque nuit, chacune ayant une ligne d’objet unique en cas d’échec. La situation actuelle résulte donc en un désordre étendu et difficile à naviguer, avec un sujet distinct et superficiel par courriel, tous entremêlés chronologiquement. Alors que notre idéal serait que la catégorie « Notifications.Tests » affiche un seul sujet par configuration, stockant tous les messages (humains ou générés par script) relatifs à cette configuration, de manière chronologique, déterminée par cette ligne d’objet unique.

[Cette catégorie de test n’est actuellement pas visible publiquement sur notre site, @Stephen, mais si tu veux voir à quoi elle ressemble et ressentir la difficulté de première main, je serais heureux de t’accorder temporairement un accès en lecture… fais-le-moi savoir.]

Pour des communautés comme meta, cela signifierait que tout utilisateur qui envoie un courriel avec « problèmes de configuration de Mailgun » continuerait d’être notifié des mises à jour des mois ou des années après avoir résolu son problème.

Je suis d’accord pour dire que ce choix peut ne pas être aussi pertinent pour une communauté aussi vaste et pérenne que meta, qui n’a pas besoin d’agréger les messages générés par courriel en un seul sujet comme nous le faisons. Vous ne voudriez probablement pas activer une telle fonctionnalité si elle existait. (Et peut-être qu’avec le temps, un site comme le nôtre n’en voudrait pas non plus pour les mêmes raisons, auquel cas l’idéal serait de pouvoir appliquer la case à cocher au niveau de chaque catégorie, mais je ne voulais pas demander trop de choses alors que je pense qu’un seul paramètre au niveau du site suffira pour nous pour le moment).

Cela dit, même si un site comme le nôtre activait une telle fonctionnalité, et que l’auteur original du sujet « problèmes de configuration de Mailgun » était gêné par les messages suivants partageant la même ligne d’objet, il pourrait probablement se désabonner du sujet pour éviter de continuer à recevoir des mises à jour si quelqu’un d’autre utilise la même ligne d’objet (ou simplement ajoute un autre message au sujet donné via l’interface web) ?

[Ce dit, je m’attends à ce que la plupart des utilisateurs humains publient via le site web, donc imaginez que cette fonctionnalité ait un impact plus important sur les messages générés par script que sur ceux générés par des humains]