Guida tecnica alla moderazione: quello che i Moderatori devono sapere 
----
IMPORTANTE:
***********

Nella fase corrente di stesura, le informazioni contenute in questo 
documento sono da considerarsi *non attendibili* e *non ufficiali* .

In particolare le policy attribuite al GCN sono riportate solo
per comodità nella compilazione del testo e possono essere oggetto
di cancellazione, variazioni o aggiunte.

L'editor di questo testo non ha e non intende assumere altro ruolo
che - appunto - quello di editor, né assume posizioni o giudizi 
pro o contro qualsiasi moderatore.

 14/07/2003

-- M/

----
per il mio 1/7 di GCN non vendo problemi nel testo presentato. Magari aspettiamo un altro po'
e poi possiamo togliere questa nota

-- CarloFusco

Indice

  1. Premessa
  2. Teoria e background tecnico
    1. Percorso articoli
      1. Il servizio di Forward
    2. I demoni o Robot di moderazione
    3. Header
      1. Approved:
      2. Newsgroups:
      3. Followup-To:
      4. Message-ID:
      5. Date:
      6. Subject:
      7. Path: e altro
  3. Sul campo
    1. Policy per i gruppi moderati di ''it.*''
    2. Routine: moderazione e operazioni quotidiane
      1. Lettura articoli
      2. Lettura del gruppo via newsreader
      3. Manutenzione liste per automatismi
        1. La funzione della whitelist: quando e come utilizzarla
    3. Controlli periodici
      1. Controllo code
      2. Statistiche
  4. Altri aspetti della moderazione
    1. Domande e risposte frequenti
    2. Startup di un nuovo newsgroup moderato
  5. Bibliografia

1. Premessa

Questo documento viene creato con lo scopo di rendere maggiormente organica e facilmente aggiornabile la documentazione relativa alla moderazione Usenet.

Il materiale utilizzato in parte è (C) GCN. Altri testi di riferimento sono citati volta per volta ed elencati nella Bibliografia.

2. Teoria e background tecnico

Quando un articolo viene inviato ad un gruppo moderato, il server news lo spedisce via email ad un servizio di forward1 (vedi Fig. 1 nota (1)) che si occuperà eventualmente di inviarlo, sempre per email, o ad un secondo servizio di forward che poi a sua volta lo invierà al demone di moderazione, oppure direttamente al moderatore.

Sostanzialmente, quindi, gli articoli instradati verso un gruppo moderato "escono" da Usenet e giungono via email al moderatore. Se questi ritiene che l'articolo sia adatto al gruppo, lo "approva" e lo fa rientrare su Usenet. Per fare ciò deve cambiare alcune righe dell'header, e rispedire l'articolo così modificato al suo news server che quindi lo propagherà su tutta Usenet. In pratica il moderatore fa il lavoro di un gateway mail-to-news.

Tutto questo può essere fatto a mano dal moderatore, poiché l'operazione è di per sé banale anche se insidiosa (si possono fare degli sbagli dalle conseguenze abbastanza antipatiche). Nel paragrafo Header vengono illustrate le modifiche necessarie agli header ed il loro significato. Certo però che se questa operazione deve essere ripetuta decine di volte al giorno, essa può diventare quanto meno tediosa. Per ovviare sia a questo problema che a quello della sicurezza sono stati creati dei programmi automatici, chiamati robot (bot in breve) o demoni di moderazione. I bot consistono in pratica in uno strato software che gli articoli devono passare prima di giungere al moderatore, in modo che il suo lavoro venga da loro considerevolmente ridotto e automatizzato. Ci sono vari programmi disponibili in rete che fanno da bot, quasi tutti in ambiente Unix, anche se vi sono un paio di eccezioni di cui parleremo in seguito.

2.1. Percorso articoli

Se osserviamo la figura 1, essa rappresenta una sinossi abbastanza completa di tutte le fasi della distribuzione di un articolo di un gruppo moderato su Usenet.

Noteremo che pur nella sua apparente complessità, tra il mittente e il moderatore ci sono (nella maggior parte dei casi) solo due strati da attraversare, il primo è un servizio di mail forward e l'altro è un Robot, o bot o demone (come preferite chiamarlo) di moderazione. Nei prossimi due paragrafi li descriveremo in dettaglio, cosa necessaria per capire bene lo schema complessivo, prima di fare una sintesi finale ed informativa del meccanismo. 

               Indirizzo ufficiale    (1)
         +-->  per la moderazione     --+
         |    (moderators.news.nic.it)  |
         |                              |
         |                    va al bot | va direttamente al moderatore
         +------------+       +---------+-----------------------------+
                      |       |                                       |
                   (1)|       |                                       | 
 +------------+       |       |                                       |
 |tuo computer|-->tuo server  +-->demone  di  ------>  email  del <---+
 +------------+      news         moderazione          moderatore
                                      |                     |
                                      |                     |
                                      |                 Approvato?
                                +-----+-----+              / \
                                |           |         Si  /   \  No
                             (3)|           |(2)     +---#     #---+
                                |           |        |             |
                             Tua email      |      Demone     (Demone)
                                            |        |             |
                                            +--->server news       |(4)
                                                 del  demone       |
                                                     |        Tua email
                                                     |
                                        +------------------------+
                                        | ng moderato distribuito|
                                        | su tutti i news server |
                                        +------------------------+


   (1) Trasmesso via email dal news server all'indirizzo ufficiale per
       la moderazione e da qui o al bot o direttamente al moderatore.
       L'indirizzo email dal news server viene ricavato così:
       la parte a sinistra della  chiocciola è composta dal nome del
       gruppo, con i "." trasformati in "-"; per la parte a destra quella 
       impostata nel file di configurazione del server.
   (2) Solo se l'autore dell'articolo è nella white list oppure se il
       newsgroup è robomoderato, cioè impostato in modo che una volta
       configurato non richieda più l'intervento umano
       (es. it.test.moderato).
   (3) Ti viene comunicato che il gruppo è moderato (opzionale: solo
       se il bot per il gruppo è configurato in questo modo).
   (4) Ti viene comunicato che il tuo articolo è stato rifiutato
       (opzionale: può essere fatto attraverso il bot oppure 
       direttamente dal moderatore).

   Fig. 1: Rappresentazione del percorso compiuto da un articolo quando
           viene indirizzato ad un gruppo moderato nella gerarchia it.*

2.1.1. Il servizio di Forward

Per comprendere bene come nel processo di moderazione il percorso di un articolo viene ad essere determinato, occorre partire dal primo anello della catena, ovvero il server news dell'autore dell'articolo. Infatti questo ha il compito di riconoscere che il post non è stato approvato (vedremo poi nella spiegazione sull' Header Approved come fa) e inviarlo via email al moderatore. Vediamo ora come il server News riconosce l'indirizzo email del moderatore a cui spedire il post per la sua attenzione.

Tutto dipende da un file di configurazione, che tradizionalmente viene chiamato mailpath dal nome del file specifico di B News e C News, due tra i Server storici di Usenet.2 Questi file di configurazione dicono al server come comportarsi, gruppo per gruppo, riguardo all'indirizzo a cui inviare l'articolo da moderare. Se guardiamo in figura 2 osserveremo che abbiamo una linea per ogni voce che inizia col nome del gruppo moderato (definito anche tramite il carattere jolly per rappresentare una generica parte oppure l'intera gerarchia). Questo è seguito dai due punti, e da %s che rappresenta una variabile che verrà sostituita dal nome del gruppo con i punti rimpiazzati dalle lineette "-". Così per esempio "it.test" diverrà "it-test". Di seguito poi abbiamo la "chiocciola" o carattere "at" che divide le due parti di un indirizzo email e infine il nome del server che gestirà gli alias. 

gnu.*:%s@prep.ai.mit.edu
*:%s@moderators.isc.org

   Fig. 2 File di configurazione per gestire la casella di posta della moderazione,  viene 
          chiamato Mailpath in C News, moderators in INN e moderators.conf in Dnews.

Il file della figura 2 si interpreta quindi come: "Per tutti i gruppi moderati della gerarchia gnu invia l'articolo all'indirizzo composto nella parte sinistra dal nome del gruppo, con i trattini al posto dei punti e nella parte destra da prep.ai.mit.edu, per tutti gli altri gruppi invece la parte sinistra rimane quella del newsgroup modificato dai trattini e quella destra diventa moderators.isc.org". Notare che nella definizione del mailpath si va dalla voce più specifica (che può essere anche un singolo gruppo), a quella più generica.

Adesso però anche se abbiamo visto come i server fanno a calcolarsi dove inviare gli articoli da moderare, resta ancora un importante punto da risolvere, ovvero come gestire il database degli indirizzi.

Ormai esistono svariate decine di migliaia di newsgroup e, tra questi, svariate migliaia saranno moderati. Distribuire tra tutti i server news un simile database e mantenerlo aggiornato risulterebbe quindi un compito pressoché impossibile. Il problema è stato quindi risolto organizzando un database distribuito (piuttosto primitivo per la verità) mediante l'uso di servizi centralizzati di forward.

Nell'esempio della figura 2 noterete che nell'ultima voce c'è questo indirizzo "moderators.isc.org". Se andiamo a chiedere ad un DNS3 a quale indirizzo questo corrisponde, avremo una risposta rappresentata dalla figura 3. 

moderators.isc.org.     3600    IN      MX      10 mail.uu.net.
moderators.isc.org.     3600    IN      MX      10 chx400.switch.ch.
moderators.isc.org.     3600    IN      MX      10 mailbox.ucsd.edu.
moderators.isc.org.     3600    IN      MX      10 mod-forw.isnic.is.
moderators.isc.org.     3600    IN      MX      10 moderators.supernews.net.

   Fig. 3 Il DNS associa al nome di dominio "moderators.isc.org"  
          un certo numero di altri server mail tra cui distribuire  
          il carico delle richieste degli indirizzi di moderazione.

Ovvero ci saranno associati al nome di dominio una serie di altri domini che sono tutti accomunati dal condividere la stessa tabella di indirizzi di forward. Quello che accade quindi è che "moderators.isc.org" mantiene una tabella di alias che associa ad ogni nome di gruppo (con i punti cambiati in trattini) l'indirizzo email della moderazione. Quindi mandando una mail a it-test@moderators.isc.org questa verrà reindirizzata alla casella della moderazione di it.test. Il carico di richieste verrà quindi ripartito equamente tra tutti i domini associati nel DNS a "moderators.isc.org", per dare robustezza al sistema.

Questo sistema è quello tradizionalmente usato dalle Big8, ma con la crescita di Usenet e il fiorire delle gerarchie regionali, si è aggiunto un nuovo strato di decentralizzazione. Per esempio nel caso di it.* tutti gli indirizzi di forward presenti su moderators.isc.org puntano ad un gruppo dallo stesso nome (sempre il nome del gruppo con i trattini al posto dei punti), ma che ha come mail server di scambio moderators.news.nic.it. Su quest'ultimo risiederanno gli indirizzi finali dei moderatori. Questo permette di cambiare tali indirizzi in maniera rapida e flessibile senza dover richiedere ai postmaster di isc.org di aggiornare la loro tabella (procedimento che dato il numero delle richieste prevede numerosi giorni per essere espletato). Il GCN poi divulga un documento tra tutti i newsmaster che chiede loro di configurare il mailpath così:

it.*:%s@moderators.news.nic.it

Se quindi il server news sarà configurato bene, il tragitto passerà solo per un unico indirizzo di forward, se invece il server non ha una voce specifica per it.* invierà l'articolo in base alla voce più generica:

*:%s@moderators.isc.org

ovvero ad isc.org, che provvederà a fare un forward presso "moderators.news.nic.it", determinando quindi due strati di forward tra il server che ha immesso l'articolo nel sistema e l'indirizzo del demone, di cui parleremo nel prossimo paragrafo.

2.2. I demoni o Robot di moderazione

I programmi che svolgono compiti inerenti la moderazione, girano spesso sui server news. Ne esistono di varia natura, alcuni sono costantemente attivi, altri vengono richiamati dall'orologio interno ad intervalli prestabiliti. Esistono infine procedure richiamabili on-demand, quali gli script CGI.

L'installazione e la manutenzione di questo tipo di programmi riguarda tipicamente l'amministratore del server.

Generalmente viene fornita una guida per i comandi che riguardano le operazioni di competenza del moderatore: il recupero degli articoli, l'approvazione, l'inserimento dei [TAG], il rifiuto degli articoli e l'invio delle notifiche agli autori.

Nel seguito di questa breve guida cercheremo di dare consigli e suggerimenti di validità generale, anche se in particolare il tipo di moderazione utilizzata incide molto sulle diverse operazioni che il moderatore effettua quotidianamente.

La [Self]GuidaModerazioneRisorse (al momento ancora da pubblicare) fornisce dettagli tecnici su come si utilizzano e come si preparano per un nuovo newsgroup due tra gli strumenti più diffusi per la moderazione automatizzata in Italia: il programma moderatore di Marco d'Itri e DMod della NetWin. I riferimenti ai siti dove reperire i due software sono reperibili anche nella Bibliografia.

Come già detto un programma o uno script presente sul server di moderazione esamina gli articoli che arrivano all'indirizzo di moderazione sono esaminate e confrontate con alcune indicazioni comuni e con dei criteri determinati dal moderatore.

Alcuni criteri comunemente adottati dal software di moderazione per l'approvazione automatica:

Viceversa ecco alcuni criteri negativi che provocano il rifiuto o l'esame manuale dell'articolo:

Se l'articolo supera i controlli formali e viene postato automaticamente dal software di moderazione automatica i tempi di processamento dell'articolo sono tipicamente brevi, dell'ordine di qualche minuto, tra l'invio dell'articolo e la pubblicazione sul newsgroup. Inoltre il carico di lavoro del moderatore diminuisce in maniera sensibile. Per funzionare al meglio la moderazione assistita dal software di robomoderazione ha però bisogno di una costante manutenzione delle liste (vedi il paragrafo Manutenzione liste per automatismi).

Se un articolo arriva da un Autore precedentemente ignoto (o, piuttosto, da indirizzo di e-mail sconosciuto), il moderatore può leggere l'articolo e approvarlo, spedire al mittente il manifesto o le FAQ del newsgroup; inoltre ha a disposizione una serie di comunicazioni prestabilite per risparmiare tempo nelle situazioni che più comunemente portano al rifiuto di un articolo.

2.3. Header

Occorre tenere presente che gli articoli che arrivano nei gruppi moderati possono contenere gli header specifici dei messaggi email e Usenet. Il moderatore (o il suo software di moderazione assistita) deve a questo proposito rimuovere correttamente molti di questi header, modificarne altri e lasciarne altri ancora invariati. Occorre quindi sapere bene dove mettere le mani oppure utilizzare un demone di moderazione scritto come si deve e ben sperimentato sul campo. Questa introduzione serva da monito quindi a chi volesse scriversi il proprio software di moderazione oppure fare le cose totalmente a mano. Per i dettagli su come comportarsi con gli header si rimanda alla lettura attenta del Moderator's Handbook. Qui di seguito si offre una guida sintetica ai principali header rilevanti per il lavoro di moderatore.

2.3.1. Approved:

L'header fondamentale che contraddistingue a prima vista un articolo postato su un newsgroup moderato è Approved:.

I server news attuali sono realizzati per non permettere ad un client generico di postare un articolo su un gruppo moderato contenente l'header Approved:, dal momento che se questo accade l'articolo non perviene al moderatore, ma salta il percorso indicato nella figura 1 del paragrafo Percorso articoli e viene direttamente pubblicato sul newsgroup.

Un server news correttamente configurato dovrebbe anche gettar via gli articoli appartenenti a newsgroup moderati che provengono dai propri peer senza l'header Approved:.

Compito del moderatore, o del software di robomoderazione, è di inserire l'header Approved: nell'articolo. Il contenuto del campo è libero.

2.3.2. Newsgroups:

Questo header deve essere esaminato attentamente dal moderatore (o dal software di robomoderazione) per non incorrere nell'errore di approvare articoli che non possono esserlo. Se l'articolo è in crosspost, ossia postato su più di un newsgroup, valgono infatti le policy generali che limitano il numero dei gruppi4 ed è vietato il crosspost su più di un gruppo moderato, a meno che non ci sia l'assenso preventivo dei relativi moderatori.

2.3.3. Followup-To:

In alcuni casi è opportuno impostare questo campo, soprattutto se si fa passare un articolo e si prevede che le eventuali risposte (i followup, appunto) debbano andare altrove. Oltre a poter indicare un newsgroup, è possibile indicare un paio di pseudogruppi: junk è utilizzato per indicare che non è opportuna una risposta all'articolo, poster per indicare che la risposta dovrebbe essere indirizzata per email al mittente dell'articolo.

2.3.4. Message-ID:

Il Message-ID è per l'articolo come il numero della Carta d'Identità per i cittadini: può essere utilizzato per fare una ricerca, ad esempio su un archivio Usenet come [WWW]Google Groups e sicuramente il server news utilizza il Message-ID per controllare se un certo articolo è già presente sul server o meno ed evitare così i duplicati. Esistono anche altri accorgimenti sul server che permettono di filtrare articoli molto simili e - a volte - può capitare che qualcosa non vada come dovrebbe e il server respinga un articolo.

In questi casi, se il moderatore reinvia l'articolo senza cambiare il Message-ID, continuerà a ricevere l'errore "NNTP: 441 435 Duplicate" o un equivalente che significa che quel Message-ID è già nell'history del server. Il moderatore, dopo aver controllato l'effettiva assenza dell'articolo dal newsgroup può cambiare il Message-ID dell'articolo, conservando il contenuto del campo rinominandolo, ad esempio in X-Original-Posting-Message-ID:.

2.3.5. Date:

Innanzitutto occorre che l'header "Date:" sia rimosso se questo è già presente nel post che arriva al moderatore. Nell'aggiungere questo campo dell'intestazione occorre anche che il moderatore faccia attenzione ad una cosa abbastanza importante. Capita infatti in alcuni casi che l'Autore di un articolo abbia la batteria scarica (quella che tiene aggiornata la data del computer) o di proposito abbia alterato la data nell'orologio interno del proprio PC. In tal caso, se non ce ne siamo accorti prima, il server rifiuterà l'articolo con un messaggio simile a questo: NNTP: 441 437 Too old -- "Sat, 31 Feb 1980 25:50:75 +0100"

Se per caso volessimo rimettere a posto le cose non dimentichiamo che il server ha già "visto" l'articolo e quindi ne ha letto il Message-ID: Ciò significa che oltre a mettere a posto la data dovremo seguire anche le indicazioni date nel paragrafo precedente.

2.3.6. Subject:

Il campo che riporta l'oggetto del messaggio non dovrebbe essere cambiato, se non per aggiungere un [TAG].

Se i [TAG] sono obbligatori, è bene che il manifesto ne riporti elenco e significato, o almeno rimandi ad una FAQ o al regolamento di moderazione.

Il manifesto dei newsgroup binari può contenere particolari prescrizioni circa l'identificazione e la numerazione delle parti di un post, in questo caso il moderatore può, se lo ritiene opportuno, modificare il Subject:.

2.3.7. Path: e altro

La riga contenente il Path: dovrebbe essere rimossa in quanto i server news ne generano automaticamente una appropriata.

Lo stesso vale per i campi lines, nntp-posting-host, x-complaints-to, x-trace, nntp-posting-date, x-server-date e gli eventuali received, delivered-to, return-path.

X-Trace è opportuno che sia rinominato, di solito in X-Original-X-Trace, per poter risalire con facilità all'origine dell'articolo, così come NNTP-Posting-Host.

3. Sul campo

3.1. Policy per i gruppi moderati di ''it.*''

Il moderatore nella gerarchia it.* ha la più ampia fiducia da parte del GCN; questa fiducia consiste nel lasciare che egli gestisca il newsgroup come meglio ritiene opportuno, senza entrare nel merito delle singole scelte, a meno che il manifesto del gruppo stesso non preveda la funzione di arbitrato da parte del GCN stesso.

Il moderatore ha degli obblighi verso il GCN e degli impegni morali verso i frequentatori del gruppo.

Nella prima categoria, tra gli obblighi (e qualche divieto), rientrano:

Nella seconda categoria, tra gli impegni morali verso i frequentatori del gruppo, elenchiamo:

3.2. Routine: moderazione e operazioni quotidiane

Come già visto nel paragrafo dedicato ai robot e ai demoni di moderazione, la maggior parte dei gruppi moderati si affida alla moderazione assistita da un software che è in grado di fare da primo filtro agli articoli, recapitarli al moderatore (o suddividerli tra i moderatori), recepirne i comandi, svolgere le necessarie trasformazioni degli header dell'articolo e pubblicarlo sul newsgroup.

Alcuni moderatori si avvalgono di liste, chiamate whitelist e blacklist, che sono utilizzate dal software di moderazione assistita per permettere a talune persone di pubblicare i propri articoli con un assenso implicito e preventivo del moderatore, mentre evitano che gli articoli di disturbatori o spammer arrivino alla casella di moderazione. Per funzionare correttamente anche questo meccanismo ha bisogno di frequenti interventi di messa a punto e di una sorveglianza attiva.

3.2.1. Lettura articoli

Gli articoli Usenet destinati al gruppo moderato vengono inviati come mail al moderatore del newsgroup. La lettura e la valutazione del contenuto dovrebbe basarsi sulla rispondenza dell'articolo al topic stabilito dal manifesto.

Sono da scartare articoli che possono provocare delle flame, che contengono dati personali soggetti alla Legge sulla Privacy e - in generale - tutto quanto può creare problemi al moderatore. Non esiste al momento giurisprudenza circa responsabilità civile o penale del moderatore, che dovrebbe essere sempre dell'Autore dell'articolo; tuttavia esiste il rischio che se si verificano dei problemi seri il moderatore possa essere comunque indagato o sentito come persona informata sui fatti.

3.2.2. Lettura del gruppo via newsreader

È molto importante seguire con regolarità il gruppo moderato con l'ausilio del newsreader e non limitarsi a visualizzare gli articoli che arrivano da moderare. Oltre a ricavare una visione d'insieme dell'andamento delle discussioni in corso, avremo modo di assicurarci che non siano presenti articoli autoapprovati e che nessuno dei poster abituali che eventualmente fossero in white-list stia abusando della pubblicazione automatizzata degli articoli.

3.2.3. Manutenzione liste per automatismi

Esistono diversi tipi di liste, la cui funzione e denominazione dipendono dal programma di robomoderazione utilizzato.

Le più comuni sono:

3.2.3.1. La funzione della whitelist: quando e come utilizzarla

(Contributo di Rocco Papaleo)

La whitelist (wl) non è un premio che distingue i buoni dai cattivi, ma uno strumento tecnico per tentare di semplificare, e soprattutto diminuire, il lavoro del moderatore. Solo in questa ottica è bene utilizzarla se non si vuole far diventare faticoso il proprio lavoro di moderazione. Inoltre l'utilizzo della wl non è obbligatorio da parte dei moderatori ed è dubbio che sia una buona scelta in caso di newsgroup a traffico molto basso.

Anche nel caso la si voglia utilizzare bisogna ricordarsi che solo quando le acque sono tranquille può andare tutto in automatico; quando c'è burrasca, o si intravede che ci sarà, è necessario fare a mano.

Per queste ragioni è bene non pubblicizzare i particolari del proprio modo di utilizzo di queste tecniche, e forse neanche il fatto stesso che le si utilizza. L'inevitabile conseguenza, in caso contrario, è inizio di lunghi, stancanti e inutili guerre tra gruppi di articolisti.

È buona prassi inserire i nuovi arrivati in white list non appena è chiaro che partecipano alla discussione e hanno il newsreader a posto. Tenendo conto che dalla wl come si entra si esce, e si rientra (con un pò più di calma).

Essere in wl serve a chi discute. Dunque, viene messo in wl chi risponde a articolo altrui più che chi si mette in "write only mode".

Nei thread suscettibile di flame o in bilico sull'fuori tema, è bene togliere dalla wl tutti i partecipanti al thread.

È chiaro che potete mettere in wl chi volete con le regole (anche extra-usenet) che credete più appropriate. Tutto ciò a patto di ricordarsi che questi articolisti, una volta divenuti attivi, e doveroso che siano trattati esattamente come tutti gli altri.

Relativamente alle blacklist si potrebbe fare più o meno lo stesso discorso -capovolgendolo. In merito aggiungerei che il blacklistaggio è bene che non sia "a vita".

3.3. Controlli periodici

3.3.1. Controllo code

Tutti i programmi, quasi invariabilmente, sono soggetti ad errore, soprattutto se ricevono dei dati non correttamente formattati o corrotti. Anche il software di moderazione non fa eccezione e a volte può accadere che non arrivino più articoli, o che alcuni di essi arrivino più volte, subiscano un ritardo o che vadano persi.

Esistono di solito dei comandi, che vanno ripetuti periodicamente, per verificare se tutto procede correttamente e, in particolare, se tutti gli articoli che sono giunti al moderatore sono stati processati.

Può anche accadere, soprattutto nei newsgroup dove opera un team di moderazione, che un articolo venga accantonato per decidere se approvarlo o meno e può succedere che una delle mailbox dei moderatori sia piena o non funzionante.

Il controllo delle code di moderazione andrebbe effettuato almeno una volta ogni due giorni, soprattutto per i gruppi che hanno un traffico consistente.

Ogni settimana si dovrebbe aver cura di pulire la coda dagli articoli rimasti inevasi (spam, reject con indirizzo fasullo etc) con il comando per cancellare l'articolo. Lasciare articoli inutili in coda occupa spazio sui server e fa perdere tempo al moderatore in quanto diminuisce il colpo sull'elenco degli articoli da moderare.

Inoltre è buona norma ogni tanto controllare il newsgroup da un altro server, magari anche un gateway, per accertarsi che non ci siano problemi inattesi, non visibili dalla vostra prospettiva locale, come quelli dovuti alla propagazione.

3.3.2. Statistiche

Effettuare nell'ambito dei controlli su un newsgroup moderato, alcune analisi su statistiche può evidenziare alcuni problemi e mettere in risalto lo stato di salute del newsgroup stesso.

I dati necessari, già aggregati, possono essere ottenuti con alcuni script o ricavati da uno dei servizi gratuiti disponibili sul web, ad esempio quello di [WWW]Microsoft.

Le prime statistiche in Italia sui newsgroup comparvero nel Marzo del 1998 a cura di Vittorio Bertola che scrisse un software per estrarre e pubblicare dei dati statistici sui newsgroup it.*. Il suo lavoro è tuttora visibile all'indirizzo [WWW]http://bertola.eu.org/usenet/newsstat/.

Una prima analisi è quella di tipo comparativo, per periodi omogenei. Ha senso confrontare il traffico sui newsgroup, ovviamente tenendo conto della stagione e di eventuali fattori episodici che possono aver influenzato il ritmo degli articoli.

Altra analisi riguarda il numero di mittenti, anche in questo caso sono possibili confronti.5

Dal servizio citato di Microsoft è inoltre possibile ottenere con facilità la suddivisione e i grafici relativi agli articoli, agli autori, agli autori delle repliche e - dato importante per un newsgroup - agli articoli senza repliche.

A livello di moderazione, può essere interessante quantificare la percentuale di articoli approvati, e categorizzare i rifiuti per motivazione, ma per questa parte è necessario elaborare i log del software di robomoderazione.

4. Altri aspetti della moderazione

4.1. Domande e risposte frequenti

Posso nominare un comoderatore?

Sì. Devi accertarti che sappia cosa fare e cosa non fare, dal momento che il moderatore di riferimento risponde al GCN di eventuali violazioni delle policy stabilite. Vedi, in particolare il paragrafo Policy.

Posso nominare un sostituto temporaneamente?

Sì, vale sempre quanto scritto sopra; possibilmente comunicandolo almeno al GCN.

Posso lasciare la moderazione a persona di mio gradimento?

Sì, comunicalo al GCN; da quel momento sarà il nuovo moderatore di riferimento per il newsgroup. È comunque opportuno che per un po' di tempo svolga il ruolo di comoderatore: puoi vedere se hai fatto la scelta giusta e il nuovo moderatore ha tempo di abituarsi.

Posso cambiare il manifesto?

Sì, senza stravolgere il topic originario del newsgroup. Abbi cura di inviarlo alla casella di posta del GCN, in modo che si possa aggiornare quello riportato sul sito ufficiale, insieme agli altri [WWW]manifesti. Se il manifesto prevede delle limitazioni, quelle non possono essere cambiate.

Posso stabilire un arbitrato o inserire dei vincoli per il moderatore nel manifesto?

Sì, tieni però presente che queste limitazioni non possono essere rimosse.

Si può inviare il manifesto periodicamente sul ng?

Sì, basta chiederlo e verrà inviato ogni mese sul newsgroup.

Si può avere un po' di spazio gratis per mettere le FAQ del ng?

Sì, è previsto uno spazio per questo all'indirizzo [WWW]http://faq.news.nic.it/, contatta il GCN.

Ho sbagliato comando e ho rifiutato un articolo che era da approvare; che faccio?

Scrivi all'Autore e chiedi a lui di reinviare l'articolo.

Ho sbagliato comando e ho approvato un articolo che era da rifiutare; che faccio?

Se non è passato molto tempo, puoi inviare un Cancel, magari dopo aver letto [Self]AiutoCanc. Se pensi si tratti di qualcosa che può creare flame o disturbare, puoi fare un breve post di scuse con Followup-To: poster nel thread e specificare che il thread si intende chiuso.

Posso cancellare un articolo autoapprovato sul ng moderato?

Sì, ma è bene che leggi prima [Self]AiutoCanc. Se si tratta di SPAM, probabilmente sarà cancellato dai Cancelbot; viceversa se si tratta di un articolo provocatorio, magari postato da qualcuno recidivo, puoi proporre un reclamo al servizio abuse del provider da cui proviene l'articolo e segnalarlo al GCN.

Posso cancellare un articolo che parla male della mia moderazione su un altro ng?

No, se lo chiedi, vuol dire che non hai letto [Self]AiutoCanc.

Posso aggiungere una [TAG] al Subject: di un articolo?

Sì, vedi anche le altre informazioni su come trattare l'header Subject:.

Posso correggere un "erorre" in un articolo?

No, già che ci sei vedi anche le altre cose da non fare.

4.2. Startup di un nuovo newsgroup moderato

Quando il nuovo gruppo moderato viene approvato, oppure viene proclamato il risultato per la trasformazione in moderato di uno già esistente, il gestore del server contatterà il moderatore di riferimento per comunicare quali sono gli indirizzi di moderazione e per fare qualche test in attesa che il control message per la creazione o la trasformazione del newsgroup vengano effettivamente inviati. Di solito passano 7-10 giorni, ma è inutile lamentarsi se viene impiegato qualche giorno in più.

La fase iniziale è molto importante e anche piuttosto delicata.

Molto spesso ci sono problemi, sia tecnici, sia di adattamento. Non tutti i server si allineano immediatamente e gli alias spesso vengono creati dopo un po' di tempo. Nel caso di cambio di status, le cose si complicano ancora: su alcuni server il gruppo può rimanere "non moderato" addirittura per mesi.

Pensando ad una "casa nuova" che si apre agli ospiti, la figura che mi viene in mente è quella del domestico (attenzione, non del proprietario) che sulla soglia li riceve e gli dà il benvenuto.

Corretto, IMHO, aprire da parte del moderatore un thread di mini presentazione magari con un richiamo al Manifesto e la prescrizione che eventuali auguri o "sono il primo" e roba del genere siano solo dei reply. In ogni caso la cosa dovrebbe esaurirsi "in giornata" o giù di lì.

Se qualcuno vi scrive per lamentare qualcosa, rispondete sempre "serenamente" ma con estrema determinazione. Alla fine, ricordate al frequentatore che per le "proteste" c'è [NEWS]it.news.moderazione (INM), magari preavvisando la moderazione. Ricordate anche che su INM non siete obbligati ad intervenire e comunque spesso un post di replica è più che sufficiente. Non mettetevi mai a flammare o trolleggiare su INM col frequentatore che protesta.

Leggete sempre con attenzione eventuali "inserimenti" di componenti del GCN. Spesso, tra le righe, saranno anche loro ad indirizzarvi al meglio sul cosa è più giusto fare. E comunque sarà utilissimo per voi apprendere come la pensano ed eventualmente aggiustare il tiro.

5. Bibliografia

Un'ottima faq in inglese che abbraccia vari aspetti della moderazione;

Il Moderator's Handbook di Kent Landfield, una vera miniera di informazioni, ma piuttosto tecnico (e ovviamente in inglese), oggi anche un pochetto datato;

Una faq curata da Russ Allbery, l'attuale leader dello steering group che gestisce le Big8. Descrive gli inconvenienti della moderazione ed è stata scritta pensando alla realtà delle Big8, ma i principi generali si applicano anche alla realtà italiana;

Una raccolta completa di software per unix ed altre informazioni, sempre di Kent Landfield;

Visto che alla fine un robomoderatore non è altro che un gateway mail::news questo modulo in Perl si occupa di tutti i dettagli a basso livello, come la trasformazione degli Header. Se volete scrivervi il vostro robomoderatore in perl, questo è il software che fa per voi. Di Russ Allbery;

Questo è il bot scritto da Marco D'Itri in perl che utilizza il modulo di Russ Allbery, in uso su moltissimi gruppi moderati di it.*;

Ormai di interesse esclusivamente storico, il bot di Maurizio Codogno che veniva usato una volta su it.*. È uno script in ksh (una delle tante shell unix, con funzioni simili al C). Oggi è superato;

STUMP è il software di moderazione più diffuso. Permette eventualmente anche di interagire col bot tramite interfaccia web;

DMod è un software freeware che può essere utilizzato per moderare un newsgroup direttamente da un Personal Computer con Win95/98/NT/2000/XP.

PyModerator è una valida alternativa (free e opensource il che vuol dire che può essere adattata facilmente ale proprie esigenze) a Dmod (che invece è closed source) con interfaccia grafica scritta in Pyton, che è un eccellente linguaggio di scripting portabile. In effetti il programma gira su tutte le piattaforme, tra cui Linuxe le varie versioni di Windows.

Versione e data Commento
V. 1.0 07/03 Prima stesura di Carlo Fusco e Mario Benvenuti, con contributi sparsi di Draco Roboter e Fred® "daytrader"