Introduzione

Questo documento è stato scritto da PaoloSammicheli nel periodo di passaggio di consegne al nuovo amministratore del Gruppo Test. Al momento in cui sto scrivendo non ho idea chi sarà, per cui se ci trovate delle cose che sospettate siano state scritte per voi, sappiate che è un puro caso. Se trovate degli errori e typo sentitevi liberi di correggerlo. Non cambiate però il senso di quanto scritto... si tratta di miei punti di vista personalissimi

Principi fondativi

L'idea del gruppo test è nata durante l'UDS Lucid a Dallas. Marjo Mercado mi parlò di una sua idea di far partecipare i LoCo Team ai test per avere una sorta di competizioni, "le olimpiadi dei test". Ai tempi mi occupavo di Marketing con il GruppoPromozione e di Traduzioni ma l'idea mi piacque molto per cui proposi agli altri di realizzarla. In un certo qual modo vedevo il GruppoTest come un valido supporto al GruppoPromozione. Il GruppoPromozione, infatti, era percepito come il gruppo di accoglienza, dove chi voleva iniziare a collaborare con Ubuntu potesse farlo facilmente. Questo però era una percezione errata perché i progetti del gruppo, fatta esclusione di pochissimi già sovrabbondanti di volontari, erano in realtà complessi e richiedevano parecchie conoscenze che difficilmente un giovane ha. Il Gruppo Test nascque quindi con i seguenti principi:

• Attività semplici

  • cercammo di abbassare la soglia minima di partecipazione. Per questo motivo scegliemmo il caso di test Live

• Attività ripetibili
  • basandosi su azioni routinarie si semplificava l'apprendimento e si dava la sensazione anche a chi fosse completamente digiuno d'informatica di "potercela fare"
• Impegno minimo
  • per far parte del gruppo è sufficiente mantenere un impegno minimo, corrispondente all'adozione. Una immagine da testare ogni Milestone, in pratica mediamente un test al mese. In modo da invogliare anche chi avesse poco tempo libero.
• Spirito di squadra

  • dividere l'effort di testing sulle adozioni permetteva di introdurre lo spirito di squadra. È stato introdotto il principio che chi non poteva fare i test era chiamato almeno ad avvertire prima. Questo ha fatto sì che altri si impegnassero a fare il test dichiarato scoperto favorendo lo spirito di squadra.

Il buon amministratore

conoscenza del progetto Ubuntu

Come amministratore occorre che vi teniate informati sull'andamento del progetto Ubuntu in generale. Si raccomanda, quindi, di seguire i Planet Ubuntu e le Newsletter. Non è male leggersi poi i log delle riunioni IRC di qualche gruppo internazionale, ad esempio il QA Team, Bug Squad e Bug Control. Infine qualche mailing list, la lista ubuntu-devel-announce sicuramente, visto che ha anche poco traffico.

dare l'esempio

Il buon amministratore del gruppo test deve dare l'esempio. Occorre che segua le liste internazionali e, quando può, stazioni nei canali internazionali di QA e Testing. È anche opportuno che stabilisca rapporti di conoscenza con chi si occupa di QA a livello internazionale, volontari e dipendenti canonical. Deve anche bloggare ogni tanto, per cercare di attirare nuovi contributori e, se possibile, parlare a qualche conferenza/incontro di sofware libero di quanto sia bello e semplice partecipare alla comunità di Ubuntu.

mentoring

L'amministratore verrà rapidamente individuato come la persona a cui domandare. Questo comporta dover trovare le risposte, e non è sempre semplice. È consigliato essere assolutamente sinceri, dire tranquillamente che una cosa non la sappiamo e che chiediamo informazioni. Inutile dare l'idea di sapere tutto, nessuno sa tutto ed in Ubuntu tutto cambia ogni sei mesi È anche importante dire senza problemi "ho sbagliato", "mi dispiace" oppure "questa cosa non la sapevo". Sdrammatizza il ruolo e semplifica il rapporto con i volontari.

motivazione

Tenere alta la motivazione è uno dei compiti dell'amministratore. Occorre ringraziare chi si impegna, mandare qualche mail che ricorda quanto importante è cio' che facciamo, ma anche occorre riprendere chi sbaglia. Trovare il giusto equilibrio è difficilissimo, sono certo di non riuscirci sempre per cui non mi avvento in consigli, sappiate che occorre trovarlo.

lavori manuali

Ci sono dei lavoretti manuali da fare, ogni tanto:

• Aggiornare l'header delle pagine wiki mettendo la prossima scadenza.
• Manutenere la tabella dei casi svolti spostando i casi delle milestone via via che si completano
• Rivedere i test degli altri e i bug segnalati dai nuovi; spesso sono pieni di errori e imprecisioni.

riunioni su IRC

È provato che le riunioni su IRC aiutano lo spirito di gruppo. È importante mantenere questa pratica dopo ogni rilascio Milestone. In esse viene di solito valutato il lavoro svolto, ad esempio con tabelle come questa. Al nuovo amministratore consiglio di leggersi i verbali delle vecchie riunioni, almeno si fa un'idea

uso dell'Inglese

Trattandosi di un gruppo le cui attività sono a cavallo tra la nostra comunità e quella internazionale, è frequente dover comunicare in Inglese. Inoltre tutti i bug vanno segnalati in Inglese. Se non siete molto ferrati con la lingua sappiate che nemmeno io lo ero quando ho iniziato. Ma il realizzare che il mio Inglese non era sufficiente per divertirmi con Ubuntu mi ha dato lo slancio per migliorarlo sufficientemente tanto che al momento in cui vi scrivo non lo considero più un ostacolo limitante. Come ho fatto? Ho studiato Anche nella vostra città troverete qualche corso da seguire, gratis o a pagamento. Inoltre ho iniziato a guardare telefilm in lingua originale con i sottotitoli. Quando vedevo una parola che non conoscevo mettevo in pausa e la cercavo nel dizionario. Se non la trovate probabilmente è in gergo, provate Urban Dictionary (molto utile anche quando parlate nelle chat). Magari ci sono delle serie in lingua inglese molto divertenti che non sono state importate in Italia. Provate a chiedere agli altri della comunità se hanno titoli da consigliarvi, imparerete l'Inglese guardando dei telefilm che vi divertono e che non avreste visto altrimenti. Come risorsa molto utile segnalo poi il sito della BBC.

scadenze dal gruppo

Per diventare membri del gruppo occorre svolgere con successo 2 test consecutivi. Decadono dal gruppo coloro che saltano 2 test consecutivi. Cercate di trasmettere questo concetto ai componenti del gruppo in maniera semplice. La scadenza dal gruppo non deve essere niente di drammatico e non significa un allontanamento dallo stesso. È possibile far parte del gruppo anche testando saltuariamente; ma la membership è il riconoscimento di una presenza stabile. Inoltre è la via a cui si accede ad altre gratifiche, come la membership ubuntu-it, per cui occorre che sia una cosa seria. Inoltre è un modo per verificare le lacune di qualcuno. I membri che richiedono la membership su Launchpad senza averne i requisiti declinateli subito. È capitato che non rispondendo a quel clic, persone rimanessero in attesa di una risposta per mesi (salvo farsi vivi solo dopo la mail di declined). Una volta mi è capitato nel Gruppo Promo di persone che avevano premuto Join su Launchpad senza nemmeno iscriversi alla lista. Di solito rispondiamo ai membri declinati con la frase "Per partecipare al gruppo consultate la pagina.... Ti aspettiamo in Mailing List!". Quindi nel messaggio, insieme al declined, inseriamo un incoraggiamento a partecipare.

supporto tecnico

Potrà capitare che vi scrivano per chiedere assistenza tecnica. A me capita continuamente sia all'indirizzo personale che a quello del gruppo. Ho preparato una risposta standard, altrimenti passerei la giornata a risolvere i problemi dei singoli anziché contribuire ad Ubuntu.

Grazie di aver contattato Ubuntu-it.

Per ricevere supporto tecnico dalla nostra comunità potete consultare il nostro sito web 
alla seguente pagina:

http://www.ubuntu-it.org/index.php?page=supporto-della-comunita

In particolare nel nostro forum potrete trovare decine di migliaia di appassionati che 
sapranno aiutarvi.

Cordiali Saluti

CategoryHomepage