Intestazioni per le notifiche email in modo che gli utenti Gmail possano filtrare per tag?

Contribuisci Funzionalità
,
1

Il post è stato chiuso come duplicato Email: i messaggi di posta elettronica dovrebbero avere dei tag, possibilmente in riferimento a Customs email headers and/or subjects tags, ma quest’ultimo è piuttosto generico e vorrei discutere un problema specifico che abbiamo:

Stiamo usando i tag come la sostituzione più logica per decine di mailing list su vari sotto-argomenti del progetto. Abbiamo iniziato a usare le categorie, ma è diventato ingestibile: le categorie sono pesanti, non consentono facili cross-posting e, per una serie di altre ragioni, pensiamo che i tag siano più adatti.[1]

Tuttavia… c’è un problema. Sebbene sia possibile inserire %{optional_tags} nel modello per le notifiche via email, il filtraggio molto limitato di Gmail non fa nulla di intelligente con questo e, anche per l’utente di posta elettronica della vecchia scuola, è un po’ una seccatura scrivere una regola procmail che scomponga la riga dell’oggetto e la analizzi.

Quindi, sarebbe bello avere il tag da qualche altra parte. Per le persone di procmail, un’intestazione X-Tags personalizzata andrebbe bene, ma Gmail non se ne curerà, quindi abbiamo bisogno di qualcos’altro.

Un’idea sarebbe quella di utilizzare effettivamente i tag come List-ID, ma non sono sicuro che Gmail faccia la cosa giusta con più tag List-ID non sono ammessi campi List-ID multipli [2]. Un’altra idea, che è un po’ goffa ma penso che funzionerebbe: inserire tag@subdomain.example.org (e potenzialmente anche tag2@subdomain.example.org, tag3@subdomain.example.org, …) nell’elenco CC. Google può filtrare su questo, e la maggior parte degli altri sistemi ha anche funzionalità ragionevolmente avanzate per gestire il CC come un campo multivalore. E, reindirizzeremmo qualsiasi posta inviata effettivamente a questi indirizzi nel nulla[3].

Come bonus, l’approccio CC potrebbe essere utilizzato come modo per aggiungere tag alla posta in arrivo (vedi Add tags by email). Di nuovo, un po’ goffo, ma allora, lo è tutta la posta elettronica, nel 2022.

  1. Se desideri discuterne, posso… in un altro thread argomento! ↩︎

  2. maledizione a te, RFCE 2919! ↩︎

  3. cioè /dev/null ↩︎

2 Mi Piace
2

Sono aperto a qualsiasi altro suggerimento o idea che qualcuno abbia. Non possiamo ragionevolmente suggerire una migrazione su larga scala a Discourse senza questo.

3

Inoltre, perché qui non ci sono #tag? :slight_smile:

4

Sembra che potrebbero funzionare, ma avrai bisogno di un plugin personalizzato.

5

Qual è esattamente il tuo caso d’uso?

Sarei interessato a sapere perché senti il bisogno di aiutare le persone a filtrare le notifiche via email dal tuo sito. L’uso previsto di Discourse è che i membri della community utilizzino le notifiche via email per essere informati quando c’è attività che li riguarda e clicchino sul link per accedere quando desiderano partecipare alle discussioni. Per i siti che lo desiderano, è possibile abilitare la risposta via email. Ma il membro dovrebbe comunque avere l’abitudine di accedere per continuare la discussione sul sito.

In questo modo tutti beneficiano e possono contribuire allo sforzo collaborativo di organizzare e gestire le discussioni sul sito. E non ti ritrovi con un mucchio di discussioni obsolete archiviate nelle cartelle email di tutti. Quando Discourse viene utilizzato come previsto, le notifiche ricevute via email possono semplicemente essere eliminate.

Inoltre, è notoriamente difficile gestire correttamente le email, e non solo per Discourse. Più riesci a far accedere e interagire la tua community sul tuo sito, più la tua community avrà successo (e sarà facile da gestire).

Forse Discourse non è la scelta giusta per la tua community, o devi mantenere operative alcune mailing list mentre sviluppi il tuo sito Discourse? So che può essere difficile cambiare le abitudini di community di lunga data.

Buona fortuna! :sunflower:

2 Mi Piace
6

Penso che potrebbe essere giusto.

Hai ancora persone che usano procmail? E persone che usano Gmail, e persone che usano Discourse? Mantenere felici tutti e tre questi gruppi sarà molto difficile.

Se hai un budget di $2000-5000, potresti ottenere un plugin personalizzato che faccia quello che chiedi, ma è difficile immaginare che sarà soddisfacente per chiunque. Non sai quali altri problemi sorgeranno una volta risolti quelli che conosci ora. Mi viene in mente la gestione delle mailing list quando un sacco di persone usavano gateway di posta elettronica basati su LAN che non seguivano RFC-822 (è stato allora che usavo procmail e rmail di emacs). Il problema è semplicemente insostenibile.

Consiglierei semplicemente di usare le categorie. Oppure, se vuoi davvero delle mailing list che seguano le convenzioni di un paio di decenni fa, attieniti a ciò che funziona.

2 Mi Piace
7

Se queste funzionalità esistono già su altre piattaforme radicate nel modello tradizionale delle mailing list, probabilmente avrai più successo lì, invece di chiedere che vengano adattate a un prodotto più orientato al futuro.

O, per dirla in altro modo, se questo è un punto critico, perché considerare Discourse in primo luogo? HyperKitty potrebbe essere esteso per aggiungere la funzionalità di cui hai bisogno?

1 Mi Piace
8

Obiettivo

Attualmente, Fedora ha centinaia di mailing list, con circa 90 con un certo grado di attività e una manciata che sono molto attive. Voglio consolidare tutto in un unico posto, il che include portare con successo la nostra community di contributori. Se esiste un’opzione migliore di Discourse per questo, nessuno l’ha ancora creata.

Versione breve

Ci sto lavorando attivamente da tre anni e ci penso da almeno dieci. Nel parlare con le persone della mia community di ciò che le blocca, questa specifica cosa è emersa ripetutamente.

Versione lunga:

Circa nello stesso periodo in cui è nato Discourse[1], abbiamo creato un frontend GUI per Mailman3 chiamato Hyperkitty, pensato per essere un’interfaccia web moderna che le persone potessero usare per accedere alle mailing list sottostanti. Puoi vederlo in azione per la Fedora Devel List.

Hyperkitty ha alcune idee interessanti, ma non è stato finanziato su una scala necessaria per avere successo, ed è stato lanciato con il design iniziale e nessuna previsione per migliorarlo e correggerlo nell’uso reale. E, prende l’email come base sottostante, e questo ha davvero legato le cose[2] — anche se avessimo avuto le risorse, mantenerlo come il più grande fattore comune[3] sarebbe stato un limite frustrante.

Quindi capisco dove ti trovi con questo. Se fai un viaggio su Wayback Machine attraverso la storia di discourse.org puoi vedere[4] che Discourse ha imparato molto dalle lezioni apprese sia dai forum che dalle mailing list e li ha sostituiti entrambi…

2013

… e questo è in gran parte sopravvissuto fino ad oggi, anche se c’è meno altra discussione sulle mailing list nelle varie pagine. Hai attraversato la stessa cosa che avremmo attraversato noi se avessimo avuto le risorse per investire in Hyperkitty — il problema dell’email come base troppo bassa — e sei giunto alla conclusione logica. Capisco perfettamente da dove vieni nel dire ora esplicitamente che portare le persone sul sito web è l’uso corretto.

Attualmente:

  • Abbiamo decine di mailing list attive
    • con centinaia di partecipanti attivi
    • e molte migliaia di abbonati passivi.
  • Queste liste risalgono letteralmente a oltre 20 anni fa.
  • Molte persone open source della vecchia scuola sono davvero attaccate a questo modo di lavorare.
    • è familiare,
    • già impostato, e
    • arriva in una routine quotidiana senza bisogno di aggiungere “controlla qualche sito web”
  • molte persone sono attive in diverse parti del progetto, ma quell’“impronta” è molto individuale

Ma:

I. Queste liste sono meno funzionali di quanto molte persone pensino:

  • la moderazione è quasi impossibile (al massimo un grosso bastone tutto o niente)
    • nonostante gli sforzi, le persone non sempre rispettano gli standard che ci aspettiamo
  • i mega-thread non sono buone discussioni
  • le molestie fuori lista sono facili da avviare e fuori dal nostro controllo
  • il cross-posting è un disastro, poiché gli abbonamenti non sono coerenti
  • impossibile stare al passo a meno che tu non sia impegnato
  • le persone che dovrebbero partecipare non lo fanno per vari motivi tra quelli sopra elencati

II. L’email non è il futuro

  • Le mailing list sono in gran parte opache ai motori di ricerca e non sembrano “attività reale” alla maggior parte del mondo
  • Le nuove persone non vogliono iscriversi alle mailing list.[5]
  • La “cultura” delle mailing list non è più una cosa.[6]
    • E l’interfaccia web di Gmail è attivamente ostile alle convenzioni tradizionali come le risposte inline.

III. L’email in generale è condannata

  • I grandi provider hanno la scala per “risolvere” lo spam per sé stessi, e ora hanno un anti-incentivo a risolverlo a livello globale.
  • I piccoli provider hanno una possibilità decrescente di consegnare in modo affidabile.
  • Le mailing list ripubblicano intrinsecamente, e tutta l’infrastruttura di firma e verifica non se ne cura davvero.
  • Le aziende stanno passando a Slack e simili per la comunicazione funzionale, lasciando l’email per annunci e trasmissioni.
    • e Jira e github e così via per interazioni focalizzate sul flusso di lavoro.
  • Di nuovo, le persone “normali” non la usano per altro che per ricevere avvisi da varie aziende di cui sono clienti. Non è più per la comunicazione personale.

Ma c’è ancora un bisogno

Abbiamo coperto la conversazione in tempo reale[7], ma abbiamo ancora bisogno delle conversazioni lunghe e asincrone che le mailing list hanno fornito. La chat non copre tutto, non funziona bene a livello globale e con volontari con diversi impegni di tempo. E gli strumenti di flusso di lavoro sono troppo limitati.

Discourse è davvero l’opzione migliore

  • Le mailing list non sono un futuro praticabile.

  • Hyperkitty è bloccato al 2014.

  • Abbiamo troppo per usare solo Github / Gitlab.

  • Altre possibilità non ce la fanno:

    • Ponymail soffre dello stesso problema dell’email come GCF
    • Vanilla non è eccezionale. Lo lascio lì. :slight_smile:
    • Google Groups è il peggio di tutto.

  • Sul lato positivo per Discourse: molte altre community open source si stanno consolidando attorno ad esso. In particolare: Python, GNOME…

Entra Cassandra

Non il database — voglio dire, dire alle persone la sventura ma nessuno ci crede. Sento molti dire “L’email funziona bene”, e “Non vedo problemi con le mailing list”, e, naturalmente, “Odio i forum”, o anche specificamente “Non mi piace Discourse”.

Ma, abbiamo davvero bisogno di un cambiamento.

Quindi…

Devo convincere una community open source ampia, attiva e importante a spostare la sua piattaforma di comunicazione principale del progetto su Discourse, e molte persone sono scettiche. È un grande cambiamento. Voglio renderlo il più facile possibile, sia per renderlo più facile e piacevole per le persone scettiche ma disposte a provare, sia per renderlo possibile da provare per le persone che hanno l’interazione via email — compreso il filtraggio — come un blocco personale.

Penso che una volta che ci saranno, molte persone adegueranno i loro comportamenti — avremo più persone che scopriranno che interagire direttamente con il sito non è poi così male.[8] E abbiamo il nostro sistema di notifica a livello di progetto che ho in programma di integrare, e spero che alla fine possa dare alle persone di più di ciò di cui hanno veramente bisogno.

Ma nel frattempo, io devo dare alle persone ciò che chiedono.

  1. Ho effettivamente provato a suggerire Discourse come approccio alternativo in quel momento, piuttosto che svilupparne uno nostro. Se avessi una macchina del tempo, potrei tornare indietro e spingere ancora di più. Ma a quel punto non ero nel mio ruolo attuale e la decisione era stata presa… ↩︎

  2. Lezione simile da LUGNET, credo il software per forum più incredibile e sensato degli anni '90 — ma legato a NNTP come backend. ↩︎

  3. Conosco l’idioma “least common denominator” (minimo comune denominatore) ma non ha senso. Come “I could care less” (potrei interessarmi meno), ma ora anche con la matematica. ↩︎

  4. Voglio dire, se non te lo ricordi già, ovviamente! ↩︎

  5. In Corea, l’email è per i vecchi è arrivato per tutti noi! ↩︎

  6. Non riesco a ricordare l’ultima volta che ho sentito qualcuno dire “netiquette”. ↩︎

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

  8. Anche se, abbiamo decisamente questa persona, quindi non saranno tutti. ↩︎

5 Mi Piace
10

Bella spiegazione! :ok_hand:

Puoi descrivere il filtraggio di cui parli in modo un po’ più dettagliato che le persone utilizzano nelle loro email? Sono qui da un po’ anch’io e ho gestito liste mailman, oltre ad aver partecipato (e ancora partecipo) a molte mailing list, ma non ho mai incontrato filtri automatici che utilizzano gli header. Mi sembra che se qualcuno si iscrive a una lista e vuole filtrarla in una cartella nella propria email, lo imposterà da solo su base lista per lista. Puoi farlo anche con Discourse, giusto?

Penso che le categorie funzionino abbastanza bene come sostituto delle mailing list, con la modalità mailing list abilitata dall’utente o l’utente che segue determinate categorie in modo da ricevere email per ogni post. Forse dobbiamo anche imparare di più sul perché pensi che organizzare le discussioni in tag sia meglio e valga lo sforzo per ottenere la parità con come funziona già con le categorie.

Modifica: Mi ricordo del mio vecchio post a riguardo, risalente al 2014! :scream:

1 Mi Piace
11

Certo. Gli header che Discourse imposta attualmente sono simili a questi (da una notifica effettiva di questo thread):

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

Se non fosse per Gmail, aggiungere qualcosa come:

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

Vedi Customs email headers and/or subjects tags - #6 by mattdm — se l’impostazione email custom headers venisse passata attraverso l’espansione del template in modo che X-Discourse-Tags: %{optional_tags} funzionasse, questa parte funzionerebbe già.

E, per gli utenti di procmail e altri client di posta elettronica “vecchia scuola”, questo sarebbe sufficiente. Sfortunatamente, per ragioni incomprensibili di Google, Gmail non può filtrare su tag arbitrari, ed è (per quanto ne so) limitato a To:, From:, Cc: e… fortunatamente almeno, List-ID. Poiché quello è il problema principale, per accomodare quegli utenti, impostare List-ID per tag invece che per categoria (o, in combinazione?) è la cosa migliore a cui riesco a pensare.

Tuttavia, RFC 2919 afferma che è consentito un solo List-ID per messaggio. Quindi rimangono:

  1. Scegliere un tag arbitrariamente[1]
  2. Generare qualcosa che includa tutti i tag, come List-ID: firsttag_secondtag.discourse.example.org e lasciare che gli utenti lo scoprano. [2]
  3. Generare email multiple per notifica, una per ogni tag e differendo solo in questo header[3]
  4. Lasciare List-ID riferito alla categoria, e invece usare l’idea del CC… [4]

Non mi piace molto nessuna di queste opzioni. Quindi, come primo tentativo, X-Discourse-Tags: coprirebbe almeno gli utenti non Gmail. (Che probabilmente è una buona sovrapposizione con gli utenti resistenti al web, quindi penso che valga la pena farlo per vedere fin dove ci porta.)

  1. confuso! ↩︎

  2. non è il massimo ↩︎

  3. anche non è il massimo ↩︎

  4. Molto macchinoso. Semplicemente aggiungere Cc: %{optional_tags}[4] non funzionerebbe, perché dovrebbe essere espanso in modo che ogni tag corrispondesse a un indirizzo email reale (black hole). ↩︎

3 Mi Piace
12

Sì, moltissimo! Il tuo ultimo paragrafo riassume bene le cose!

2 Mi Piace
13

Molto favorevole all’aggiunta di X-Discourse-Tags e X-Discourse-Category (per parità)

Immagino che a lungo termine per Gmail potremmo aggiungere un’opzione utente:

  • Aggiungi tutti i tag a cui appartiene questo argomento nei titoli degli argomenti inviati via email.

Ad esempio, qualcosa del tipo:

[Discourse Meta] [feature] [email] [notifications] Header per le notifiche email

Oppure, quando abilitato:

[Discourse Meta] Header per le notifiche email … [feature] [email] [notifications]

5 Mi Piace
14

Sì, sarebbe interessante come opzione utente. Attualmente abbiamo questo a livello di sito:

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

Abbiamo ricevuto un forte feedback sul fatto che mettere i tag altrove che alla fine fosse fastidioso. E alcuni feedback sul fatto che Google non è molto intelligente nel filtrare in modo utile le righe dell’oggetto parziali.

Non sono sicuro di quanto possiamo “correggere” Google, (O meglio, sono abbastanza sicuro, e la risposta è “non molto”). Quindi potrebbe esserci un certo grado di “pazienza” che dovrò convincere le persone ad accettare.

4 Mi Piace
15

Ci sono alcune piccole cose che possiamo fare per migliorare la situazione.

Al momento stiamo

  1. Limitando a 3 (ordine arbitrario)
  2. Non racchiudendo i tag in [ ]

Sono indeciso ma penso che il limite arbitrario di 3 non sia ottimale, dovremmo semplicemente rimuoverlo.

Inoltre tags.map{|t| "[#{t}]"}.join(" ") sarebbe meglio perché il filtro potrebbe essere su [tagname] invece che su tagname, che è molto più probabile che appaia nel titolo del PM.

@martin cosa ne pensi?

5 Mi Piace
16

Questo ha più senso conoscendo la storia. Sembra che tu abbia un budget per realizzare le cose e alcune buone idee per iniziare. Penso che sarà difficile e l’importazione di tutti i dati sarà una sfida. Sarà comunque difficile rendere felici tutte quelle persone e Sam è d’accordo con almeno alcune delle tue idee, quindi entreranno nel nucleo e non verranno interrotte in futuro come probabilmente accadrebbe per un plugin.

3 Mi Piace
17

Concordo com você aqui, embora eu pense que, em vez de remover o limite completamente, podemos apenas usar a configuração max_tags_per_topic? Acho que seria mais seguro.

Infelizmente, adicionar [] em torno das tags não ajudará muito na pesquisa do Gmail, apenas visualmente, pois, pelo que posso ver (por exemplo, veja https://webapps.stackexchange.com/questions/52828/create-gmail-filter-that-contains-a-special-character, a documentação vinculada não está mais lá, mas ainda é válida), o Gmail remove caracteres especiais ao pesquisar no assunto e em outros lugares. Tente pesquisar subject:("[support]") no Gmail, você obterá tudo com suporte no assunto, não apenas aqueles com colchetes. Isso é meio sem sentido do Google fazer isso, eles são uma empresa de pesquisa, afinal (bem, pesquisa e anúncios), mas não há nada que possamos fazer a respeito.

Também devemos ser capazes de adicionar facilmente X-Discourse-Tags e X-Discourse-Category ao mesmo tempo em MessageBuilder, pois já temos essas opções neste momento, e como você diz @mattdm isso cobre bem os usuários resistentes à web:

Posso cuidar disso se você quiser?

5 Mi Piace
21

Ho appena unito questo @mattdm:

Non aiuta molto con Gmail, ma almeno dovrebbe aiutare gli utenti di email basate su terminale in modo che possano filtrarle più facilmente.

6 Mi Piace
22

Nota @mattdm ci abbiamo davvero provato, ma Gmail è semplicemente così difficile. Rimuove così tanto dal testo durante la tokenizzazione che le tue mani sono legate molto strette.

L’unica soluzione che mi viene in mente è rendere i nomi dei tag super brutti nelle email:

“Questo è un oggetto demo. [Temail, Tnotifications]” (prefisso T o un’altra sequenza alfa che a Gmail “piace”)

Ma è una soluzione piuttosto brutta e poco intuitiva.

3 Mi Piace
23

Grazie Sam (e a tutti!).

Apprezzo tutto l’impegno profuso in questo. Alla fine, c’è solo tanto che possiamo fare per combattere le scelte imperscrutabili di Google.

Sì, seriamente. L’unica altra cosa che mi viene in mente di fare sarebbe aggiungere un’opzione per utente:

Fai in modo che le righe dell’oggetto delle notifiche email contengano i nomi dei tag in un formato super brutto su cui Gmail possa filtrare.

:-/

5 Mi Piace