Migliori pratiche: separatori ascii nelle email?

Supporto
1

Ciao comunità Discourse,

Innanzitutto, grazie per aver creato uno strumento che sto trovando ottimo, prezioso, flessibile e (per lo più) intuitivo. Stiamo lavorando per spostare diverse modalità di comunicazione del nostro progetto su Discourse, dalle mailing list per discussioni della comunità basate sugli utenti alle email generate da script che ci notificano eventi chiave (nuovi problemi, fallimenti dei test, ecc.), e siamo entusiasti di questi cambiamenti.

Uno degli intoppi che ho incontrato nella configurazione è la rimozione automatica del contenuto dopo righe come ----- nelle email inviate a Discourse. Se ho capito bene, questo viene fatto per evitare che i post inviati via email portino con sé l’intera catena di risposte, e sono rimasto generalmente colpito dalla pulizia con cui le risposte via email vengono visualizzate in Discourse, quindi non sto criticando affatto questa scelta in questa domanda.

Tradizionalmente abbiamo usato spesso tali separatori nelle email di notifica generate da script (che ora stiamo reindirizzando a Discourse) per renderle facili da leggere sia con tecnologie vecchie che nuove. Sto rimuovendole e sostituendole con tecniche come “proviamo semplicemente a usare più spazio verticale”, ma prima di andare troppo avanti in questo sforzo, volevo verificare se esiste un’altra best practice consigliata per creare tali separatori nelle email inviate a Discourse, o un modo per evitarli / aggirare il filtro attuale che non ho ancora trovato (il mio miglior tentativo finora è stato usare una riga di trattini n-dash invece di trattini/hyphen o meno ASCII, ma non mi va di passare a caratteri non ASCII, per semplicità).

Molti di noi tendono anche ad usare abitualmente piccoli separatori --- nelle email per separare un blocco di codice o qualcosa di simile, quindi temo che, anche una volta convertiti tutti i nostri messaggi generati da script, questo darà problemi agli utenti che si affidano all’opzione “rispondi” per rispondere ai temi di Discourse riflessi nelle loro caselle di posta (ma forse è solo una curva di apprendimento che dovremo superare?).

Grazie per eventuali consigli o suggerimenti qui,
-Brad

2

Aha… qualcosa che ho appena scoperto io stesso e che potrebbe aiutare altri che capitano in questa discussione: mescolare simboli ASCII non separatori/punteggiatura in una riga che altrimenti agirebbe come separatore fa sì che superi il filtro di Discourse. Quindi, trasformare una riga come:

Header
--------------------------------

in:

--- Header ---------------------

è un modo per preservare una certa forma di linea di separazione senza che Discourse la rimuova. Naturalmente, questo non aiuta ancora gli utenti abituati a fare affidamento su piccole linee di separazione ---- per mettere in risalto qualcosa in un’email, quindi sono ancora curioso di sapere se altri hanno raccomandato delle migliori pratiche in proposito.

3

A rischio di continuare a parlare da solo, ecco un esempio motivante specifico che abbiamo incontrato oggi:

Uno dei casi in cui utilizziamo script per notificare le persone di eventi è inviare email agli sviluppatori quando nuove PR vengono unite al nostro repository GitHub. Abbiamo ora modificato questi script per inviare email a una categoria specifica del nostro sito Discourse. Tuttavia, poiché GitHub utilizza Markdown per descrivere le PR, spesso troviamo intestazioni di sezione come la seguente nelle descrizioni delle PR:

Dettagli di questa PR
------------------

che vengono renderizzate come intestazioni di sezione su GitHub. Ma quando inviate via email a Discourse, questa riga di trattini causa il taglio del resto del messaggio.

Potremmo ovviamente istruire tutti i nostri sviluppatori a utilizzare altri stili di intestazione che non verrebbero tagliati (come ## Dettagli di questa PR), ma se esistesse un modo per modificare il nostro script in modo da elaborare il messaggio di unione e proteggere o escapare tali pattern, in modo che vengano preservati fino a Discourse, ciò sembrerebbe più attraente.