Differenze tra le versioni di "Wikimania 2017/Relazione Giuseppe Profiti"

Da Wikimedia Italia.
Jump to navigation Jump to search
Riga 97: Riga 97:
 
* i problemi principali sono dovuti alla curva di apprendimento sul progetto a cui si vuole collaborare
 
* i problemi principali sono dovuti alla curva di apprendimento sul progetto a cui si vuole collaborare
 
* l'hackaton era previsto per 2 giorni, avendo partecipato solo al secondo ho avuto l'impressione che molte cose fossero già state decise/impostate
 
* l'hackaton era previsto per 2 giorni, avendo partecipato solo al secondo ho avuto l'impressione che molte cose fossero già state decise/impostate
 +
 +
== Giorno 3, primo giorno della conferenza ==
 +
 +
=== Comunicazione ===
 +
 +
Melody Kramer del team di comunicazione della WMF ha presentato un po' di spunti. Trovate i miei appunti [https://wikimania2017.wikimedia.org/wiki/Submissions/How_good_communication_can_help_you_talk_to_reporters,_rule_the_world,_and_do_other_cool_stuff:_An_introductory_guide_to_public_relations/notes qui] (in inglese).
 +
 +
=== Supporto ai volontari ===
 +
 +
Questa attività era inserita all'interno del programma della conferenza Wikimedia del nord America. Sostanzialmente, erano presenti molte persone di Wikimedia Germania, una dell'Austria, il presidente di Wikimedia Norvegia, un ungherese e un componente di Wikimedia Repubblica Ceca.

Versione delle 23:49, 27 ago 2017

Ciao a tutti, sono andato a Wikimania come componente del Direttivo di Wikimedia Italia. Il mio scopo principale era trovare buone pratiche e idee da applicare in associazione, per evitare di dover ripetere gli errori fatti da altri, e stabilire qualche connessione che non fosse solo formale.

I costi per l'associazione sono relativi solo al viaggio, in quanto ho trovato modo di evitare le spese di alloggio.

Giorno 1: preconferenza, "Learning days"

Campaigning for new Editors

Wikimedia Germania ha presentato un progetto per coinvolgere nuovi contributori su Wikipedia. Alcune strategie che hanno provato non hanno funzionato bene: messaggi diversi erano dispersivi, il tour guidato dopo la registrazione non ha portato a differenze. I lor suggerimenti sono stati di utilizzare un solo messaggio per campagna, di usare immagini e di preparare dei compiti iniziali per i nuovi contributori che siano molto facili. Cose che invece non sono facili da gestire sono il tracciamento dei nuovi utenti e la scarsità di informazioni sul comportamento della comunità nei confronti dei nuovi utenti.

In coda a questo intervento, Alex Stinson ha presentato 1lib1ref, l'iniziativa per il coinvolgimento dei bibliotecari. Su questo segnalava che le cose sono andate bene per vari motivi: il pubblico di riferimento era molto specifico (bibliotecari a cui importa di iniziative digitali), il fatto che si siano usati social media e l'utilizzo di hashtag non vincolati a una specifica piattaforma (quindi utilizzabile sia su social network, sia nell'oggetto della modifica su wikipedia ecc). I social media sfruttano in pare un meccanismo psicologico di pressione tra pari, inoltre l'hashtag è tracciabile negli anni, dato che non è limitato nel tempo.

Una nota personale: il fatto che le guide (sia come testo, sia come spazi per ricevere aiuto) sui progetti Wikimedia siano all'interno della piattaforma potrebbe rendere complicato per un nuovo utente chiedere aiuto (se devo fare una cosa complicata per risolvere un altro problema, lascio perdere).

How to plan a pilot

Sati Houston della WMF si occupa, tra l'altro, dell'assegnazione dei fondi (grant) ai volontari che ne facciano richiesta. Nel suo workshop ha spiegato come preparare un pilot, cioé un mini progetto iniziale che verifichi le potenzialità di un eventuale progetto più esteso.

Il pilot deve essere piccolo e semplice, ad esempio un editathon con meno di 20 partecipanti, o una attività che richieda meno di 3 eventi.

Le idee migliori sono complesse e difficili da implementare, mentre un pilot deve essere molto semplice e deve protare a risultati incrementali o a un piccolo impatto.

Per preparare un pilot, sono necessarie delle competenze, ad esempio come fare un bilancio, capacità tecniche ecc. Queste vano identificate per poter capire quanto il pilot sia fattibile e quali risorse aggiuntive siano necessarie.

Quindi i punti principali del pilot sono:

  • verificare la fattibilità dell'idea
  • capire l'impatto
  • minimizzare rischi futuri

Molto importante è mostrare come si progredisce nel progetto, partendo dal pilot e muovendosi verso progetti più complessi. In questo modo si giustifica anche il pilot.

Il pilot è utile anche per chi eroga fondi o contribuisce: permette di mostrare le difficoltà di un pezzo del progetto, in modo che il proponente si possa rendere conto della complessità dell'idea più grande che aveva proposto.

Avendo un risultato, c'è una gratificazione per chi ha portato avanti il piccolo progetto. L'effetto è maggiore quando si sa su chi beneficerà dei risultati.

Come creare un pilot

  1. definire il problema
  2. definire la soluzione, elencare le assunzioni/presupposti fatte in merito (cercando di esplicitarle, perché potrebbero essere non palesi)
  3. elencare i vincoli e le risorse
  4. definire un piano di monitoraggio (opzionale, dipende dalla complessità del pilot)
  5. definire un piano di valutazione (questo invece è critico)
Definire il problema

Il problema deve essere piccolo. Questo perché deve poter essere svolto con le risorse disponibili e deve essere chiaro se ha funzionato o no.

Per rendere un problema piccolo, si può restringere un problema, in passaggi successivi. Ad esempio, mancano voci su donne scienziato. Restringiamo alle ingegnere afroamericane, poi a quelle specializzare in ingegneria elettronica, poi a quelle nate dopo il 1950.

Bisognerà tenere in considerazione anche le risorse necessarie nei passaggi successivi (quando si espanderà il pilot).

testare una soluzione semplice
  • trovare uno scettico o una persona che ha idee diverse per verificare le assunzioni fatte
  • considerando le skill disponibili, bisogna verificare solo una cosa alla volta
  • capire chi parteciperà, per rendere le cose semplici anche a loro
  • capire chi subirà l'effetto, in modo da coinvolgerli dall'inizio
verificare i vincoli e le risorse

Tutto deve essere considerato una risorsa, perché bisogna mettere in conto la possibilità che sia sprecata (es. partecipazione, buona fede ecc)

Nei vincoli possono rientrare anche questioni culturali specifiche.

creare un piano di monitoraggio (opzionale)

Se c'è una sola persona che porta avanti il progetto, non serve. Più grande il progetto, più "disaggregato" sarà il monitoraggio.

creare un piano di valutazione

Raccogliere informazioni "facili" non va bene.

In generale: con un pilot si impara qualcosa che aiuta anche altri se condiviso; se ci si blocca in un pilot, è un progetto piccolo quindi non si rischia molto; anche se va male, si può riutilizzare in seguito "resuscitando" il progetto.

Lighting talks

Sono state presentate molte attività diverse, con presentazioni da 3 minuti + 2 di domande.

Tra le cose interessanti:

  • Daria Cybulska di Wikimedia UK ha preparato un questionario per i partner istituzionali, mirato a valutare come la presenza di un Wikipediano in residenza abbia cambiato il modo di lavorare dell'istituzione. Va somministrato a distanza di tempo, per esempio per un WiR di un anno andrebbe proposto dopo 6 mesi/un anno
  • Wikimedia Ucraina ha un programma di formazione per i candidati al direttivo, in cui presenta questioni legali, formali ecc che possono essere utili a un futuro cosigliere. La cosa è utile a vari livelli (persone che si ricandidano, persone che capiscono quali siano le difficoltà del compito ecc).

Io ho presentato le attività di formazione che abbiamo svolto dal 2015 in poi: le giornata di formazione a Bologna (quella interna e quella su Wiki Loves Monuments con i fotografi), la formazione dei coordinatori, la formazione "peer to peer" e i possibili scenari futuri.

Community health

La sessione non è stata informativa come mi sarebbe piaciuto. Comunque, il risultato è stato che fondamentalmente tutti ritengono che le attività offline siano quelle che migliorano i rapporti nella comunità o aiutano a risolvere i problemi.

Giorno 2: hackaton

Non avevo mai partecipato a un hackaton, volevo farmi un'idea soprattutto nell'ottica di eventi simili che sono stati proposti da soci. Mi sono unito al gruppo di Aaron Halfaker, dato che si occupa di cose più vicine a quelle che tratto per lavoro e quindi sarebbe stato, nella mia ipotesi, meno complicato da seguire.

Le mie impressioni sono le seguenti:

  • chi va a un hackaton, sa già molto bene su cosa vuole lavorare
  • persone che, come me, arrivino per dare una mano senza avere un obiettivo (personale) specifico, hanno difficoltà a inserirsi
  • i problemi principali sono dovuti alla curva di apprendimento sul progetto a cui si vuole collaborare
  • l'hackaton era previsto per 2 giorni, avendo partecipato solo al secondo ho avuto l'impressione che molte cose fossero già state decise/impostate

Giorno 3, primo giorno della conferenza

Comunicazione

Melody Kramer del team di comunicazione della WMF ha presentato un po' di spunti. Trovate i miei appunti qui (in inglese).

Supporto ai volontari

Questa attività era inserita all'interno del programma della conferenza Wikimedia del nord America. Sostanzialmente, erano presenti molte persone di Wikimedia Germania, una dell'Austria, il presidente di Wikimedia Norvegia, un ungherese e un componente di Wikimedia Repubblica Ceca.