Differenze tra le versioni di "Linee guida scrittura email"

Da Wikimedia Italia.
Jump to navigation Jump to search
(metto ancora più in evidenza)
 
(2 versioni intermedie di uno stesso utente non sono mostrate)
Riga 1: Riga 1:
 
Questa pagina tenta di raccogliere '''linee guida per la scrittura di una email''' soprattutto coprendo aspetti socio-tecnici ed etici ❤️
 
Questa pagina tenta di raccogliere '''linee guida per la scrittura di una email''' soprattutto coprendo aspetti socio-tecnici ed etici ❤️
  
Pagina utile soprattutto in comunicazioni via email da Wikimedia Italia verso il pubblico.
+
Pagina utile soprattutto in comunicazioni via email da Wikimedia Italia verso il pubblico. Questo comprende anche newsletter via email, ecc.
  
 
== Preferire il formato testo (evitare HTML) ==
 
== Preferire il formato testo (evitare HTML) ==
 +
La direzione è di preferire il formato testo ed evitare il formato HTML.
 +
 
Il formato testo è un formato che si riconosce perché contiene letteralmente soltanto testo. Si riconosce quando la mail contiene solo testo, senza alcun layout avanzato luccicante da pagina di giornale.
 
Il formato testo è un formato che si riconosce perché contiene letteralmente soltanto testo. Si riconosce quando la mail contiene solo testo, senza alcun layout avanzato luccicante da pagina di giornale.
  
Riga 28: Riga 30:
 
*: ...
 
*: ...
  
== Evitare servizi short URL ==
+
== Disattivare il tracciamento nelle newsletter ==
Esempi:
+
{{Vedi anche|Linee guida sui link}}
* OK: usare "w.wiki" per accorciare le query di Wikidata o gli url dei progetti Wikimedia con la funzione [[:meta:Special:UrlShortener|Special:UrlShortener]] va benissimo, siccome questo sito rimanda a siti affidabili del mondo Wikimedia
+
La direzione è di evitare il più possibile link di tracciamento, anche nelle email.
* NO: usare "bit.ly" e qualsiasi altro servizio esterno non Wikimedia e non elencato in [[domini]]
 
* NO: condividere notizie di altre persone che usano link brevi. Non è necessario contattarli per farglielo togliere: è sufficiente pubblicare un nuovo messaggio correggendo l'URL.
 
  
Motivi:
 
* Minimizzazione dei dati personali:
 
*:Le aziende e le persone che gestiscono il servizio di short URL (e.g. "bit.ly") intercettano il traffico in arrivo e i metadati di navigazione (indirizzo IP, lingua del browser, sistema operativo, ecc.). Evitare di cedere i dati personali a terzi è in linea con il principio di minimizzazione GDPR.
 
* Rallentamento nell'accesso:
 
*: Un servizio di short URL rallenta l'accesso all'URL di destinazione. A volte si tratta di pochi istanti in più ma a volte anche diversi secondi.<ref>https://web.archive.org/web/20121112030704/http://blog.watchmouse.com/2010/03/url-shorteners-make-the-web-substantially-slower-facebooks-fb-me-is-slowest/</ref>
 
* Sicurezza:
 
*:Le persone non dovrebbero aprire un link solo per sapere qual è la destinazione finale, questa è una cattiva pratica di sicurezza informatica e facilita il social engineering. Avere un pubblico di persone informate ad aprire soltanto link ufficiali aumenta la sicurezza dell'associazione. Evitare di aprire link esterni a caso è importante per tutelare un'associazione che ha potenzialmente un milione di euro di donazioni nel conto corrente da proteggere.
 
 
== Eliminare parametri di tracciamento social ==
 
Esempi:
 
* NO: condividere una notizia di questo tipo: [https://example.com/news/abc/?fbid=12314324123123123123 https://example.com/news/abc/''?fbclid=12314324123123123123'']
 
* OK: condividere l'indirizzo minimo necessario alla navigazione (senza <code>?fbclid=...</code> che è un parametro di tracciamento Facebook Pixel o altri parametri di tracciamento)
 
 
Motivi:
 
* Minimizzazione dei dati personali:
 
*:Se una persona condivide un link di questo tipo, ogni altra persona che accede a questo indirizzo può aiutare a fornire ad almeno una entità esterna (social network in primis) la possibilità di tracciare una relazione sociale fra le persone coinvolte, permettendo attività di arricchimento dei dati personali. Questa pratica è da scoraggiare nell'ottica di minimizzazione GDPR.
 
* Brand reputation:
 
*: Molte società di comunicazione "tradizionali" che lavorano per aziende che spingono alla vendita di un prodotto, spingono ad adottare comunicazioni con link di tracciamento di questo tipo, per identificare maggiormente le relazioni fra gli utenti. Non essendo Wikimedia Italia un'azienda, e avendo intenzioni opposte al tracciamento, il rischio è che questi parametri ci affianchino a queste pratiche, peggiorando la reputazione etica del capitolo.
 
 
Suggerimenti:
 
* Per rimuovere questi parametri inutili da ogni link prima dell'invio della mail ci sono strumenti automatici. Esempio per Firefox:
 
*: https://addons.mozilla.org/en-US/firefox/addon/neat-url/
 
 
== Disattivare il tracciamento nelle newsletter ==
 
 
Esempi:
 
Esempi:
 
* NO: avere una newsletter che manipola ogni link per sostituire la destinazione con un altro indirizzo esterno
 
* NO: avere una newsletter che manipola ogni link per sostituire la destinazione con un altro indirizzo esterno
Riga 79: Riga 55:
  
 
In caso di dubbi sulle buone pratiche e le potenziali ripercussioni tecniche consulta pure la [[commissione Tech]].
 
In caso di dubbi sulle buone pratiche e le potenziali ripercussioni tecniche consulta pure la [[commissione Tech]].
 
== Note ==
 
<references />
 
  
 
== Pagine correlate ==
 
== Pagine correlate ==
  
* [[Codice di condotta]]
+
* [[Linee guida sui link]]
  
 
[[Categoria:Documentazione utente]]
 
[[Categoria:Documentazione utente]]

Versione attuale delle 15:10, 6 mar 2023

Questa pagina tenta di raccogliere linee guida per la scrittura di una email soprattutto coprendo aspetti socio-tecnici ed etici ❤️

Pagina utile soprattutto in comunicazioni via email da Wikimedia Italia verso il pubblico. Questo comprende anche newsletter via email, ecc.

Preferire il formato testo (evitare HTML)

La direzione è di preferire il formato testo ed evitare il formato HTML.

Il formato testo è un formato che si riconosce perché contiene letteralmente soltanto testo. Si riconosce quando la mail contiene solo testo, senza alcun layout avanzato luccicante da pagina di giornale.

Esempi:

  • OK: quando si invia una mail, preferire il formato testo
  • OK: quando si risponde una mail, preferire il formato testo
  • NO: inviare mail in formato HTML senza fornire alcun supporto al formato testo

Motivi:

  • Accessibilità:
    Una mail in formato testo è più accessibile per la maggior parte degli screen reader, in aiuto alle persone con cecità o ipovedenti.
  • Inclusione:
    Una mail testuale è più accessibile su un terminale. È così che si leggevano le mail quando sono nate ed è così che le persone dovrebbero poter interagire tutt'oggi se lo desiderano.
  • Sostenibilità:
    Una mail HTML occupa più spazio di una mail testuale, più tempo per essere trasmessa, più risorse computazionali per farne il render e visualizzarla. Quando si invia una mail, il suo peso viene moltiplicato per le centinaia di riceventi, che spesso archiviano questa email per molto tempo. Inoltre, chi risponde ad una mail HTML, spesso risponde nello stesso formato. Il formato testuale è da preferire per una gestione più attenta delle risorse finite, sia energetiche che tecnologiche.
  • Reputazione mailserver:
    È più difficile per i sistemi anti-spam valutare il contenuto una mail in formato HTML. Questo formato può innalzare il livello di segnalazione spam.

Suggerimenti:

Disattivare il tracciamento nelle newsletter

Nuvola apps xmag.png Per approfondire, vedi anche Linee guida sui link

La direzione è di evitare il più possibile link di tracciamento, anche nelle email.

Esempi:

  • NO: avere una newsletter che manipola ogni link per sostituire la destinazione con un altro indirizzo esterno
  • OK: avere una newsletter in cui ogni link è rimasto come l'autore l'aveva originariamente scritto

Altri esempi correlati:

  • NO: avere un software sul proprio computer (spesso "antivirus") che manipola ogni link per sostituire la destinazione con un altro indirizzo esterno (e.g. mandando allo specifico antivirus) e manipolando quindi ogni link in ogni propria risposta.

Motivi:

  • Sicurezza:
    Non permettere facilmente di esaminare qual è la vera destinazione di un link è una pratica che favorisce un ampio spettro di attacchi informatici e social engineering.
  • Brand reputation:
    Wikimedia Italia è un'associazione che promuove la cultura libera. Avere una newsletter che applica tracciamento degli utenti per scoprire quando aprono una notizia, un link in una notizia, quando lo fanno, ecc., non è mai stato parte di questa visione e mai dovrebbe esserlo. Non curare questo particolare, e lasciare un sistema di tracciamento interno in una propria newsletter, e non riconoscere il problema, peggiora la reputazione etica del capitolo
  • Minimizzazione dei dati personali:
    Quando una newsletter converte ogni link in altri link di tracciamento, significa che ogni persona che apre un link, invia alla newsletter tutta una serie di informazioni, fra cui l'ora esatta in cui il link è stato aperto, quale link è stato aperto, da quale indirizzo IP, ecc. Questo tracciamento è da evitare per essere maggiormente in linea con il principio di minimizzazione dei dati personali del GDPR.

Problemi noti:

Contatti

In caso di dubbi sulle buone pratiche e le potenziali ripercussioni tecniche consulta pure la commissione Tech.

Pagine correlate