Chi utilizza una qualsiasi distribuzione linux si sarà trovato prima o poi di fronte ad un comportamento errato o indesiderato di una certa applicazione. Oppure si sarà trovato nella condizione di pensare ad una piccola modifica o all’aggiunta di una nuova feature che gioverebbe magari all’usabilità dell’applicazione. Una situazione del genere si può presentare a tutti: ad uno sviluppatore, ad un utente esperto o ad uno alle prime armi.
Cerchiamo di immaginare cosa succede attualmente per le tre ipotetiche classi di persone che ho elencato.
SVILUPPATORE:
In caso di crash semplicemente lo sviluppatore procederà prima di tutto a cercare un modo per riprodurre il comportamento anomalo, cercherà di ottenere più informazioni possibili come lo stack trace al momento del crash. Successivamente si butterà sul bug tracker del programma specifico, si iscriverà se non l’aveva già fatto in precedenza, cercherà duplicati per il bug che sta segnalando e solo alla fine aprirà una nuova segnalazione. Ovviamente la segnalazione verrà completata con tutti i dati sensibili del proprio sistema, (versioni delle varie librerie coinvolte, tipo di compilatore e altre informazioni varie). A questo punto tutto quello che gli resterà da fare sarà aspettare che qualche buona anima si metta a risolvere il fastidioso bug segnalato. Se lo sviluppatore ha la fortuna di conoscere le tecnologie del programma, avrà inoltre la possibilità di provare a risolvere la cosa mettendo le mani nei sorgenti ed inviare in caso di successo una patch agli sviluppatori. La procedura sarà del tutto analoga nel caso di richiesta di una nuova feature.
UTENTE ESPERTO:
Per un utente esperto il procedimento è pressappoco lo stesso con la sostanziale differenza che non sarà in grado di provare a risolvere il problema in casa. In generale inoltre per un utente, anche se esperto, sarà abbastanza difficile raccogliere le informazioni giuste da segnalare potendo sbagliare nel segnalare troppo o troppo poco. Altro discorso merita quello delle feature. Per quanto riguarda la mia esperienza personale non è semplice immaginare che una richiesta di feature vada fatta in un bug tracker. In generale con un po di lavoro in più da parte degli sviluppatori che raccolgono le varie richieste nel bugtracker si riuscirà a trarre in qualche modo giovamento da questo tipo di segnalazioni.
UTENTE ALLE PRIME ARMI:
Un utente alle prime armi non avrà nemmeno la lontana concezione di quello che significa segnalare un bug. Si troverà smarrito tra la complessità di parole come “stacktrace” e “debug symbols”, non saprà come identificare un problema simile al suo. Nella più rosea delle ipotesi eviterà semplicemente di segnalare il bug, nella peggiore compilerà una richiesta praticamente inutilizzabile. Nel primo caso se il bug è grave l’utente smetterà di utilizzare l’applicazione rivolgendosi ad altro. Nel secondo caso probabilmente vedrà la sua richiesta scartata magari in malo modo da uno sviluppatore, sarà portato a dire che il mondo dell’open source è fatto di cattivoni che non vedono l’ora di mangiare i novizi e in seguito si rivolgerà ad altro. Sarà danneggiato nella misura in cui non potrà ottenere il suo legittimo scopo e danneggerà in quanto determinerà una mole aggiuntiva di lavoro degli sviluppatori che dovranno trovare i bug utili all’interno del rumore di fondo di questo tipo di segnalazioni.
Analizziamo adesso come potrebbero incidere riguardo al numero delle segnalazioni le categorie citate supponendo che il profilo degli utenti rifletta quello di un gruppo eterogeneo di persone e che tutti si cimentino nella stesura:
- Sviluppatori: 0.1%
- Utenti esperti: 0.9%
- Utenti alle prime armi: 99%
Incrociando i profili tracciati a inizio articolo con le percentuali (che ho inventato ovviamente solo per rendere l’idea) si ottiene un quadro disastroso. La prospettiva è quella di ingolfare i bug tracker con un 99% di rumore di fondo, che comunque va letto e scartato e informazioni utili con distribuzione statistica tipica dell’ “ago nel pagliaio”.
STRADE INTRAPRESE:
Ovviamente lo strumento bug tracker per quanto potente non è pensato per la totalità degli utenti ma per sviluppatori e in parte può andare bene anche per gli utenti esperti. La mia opinione a riguardo è che ignorare la massa solo perchè non è in grado di utilizzare lo strumento è un comportamento profondamente sbagliato e controproducente. Molto spesso il parere di chi ha un background completamente diverso permette di vedere tutte quelle piccole magagne su cui lo sviluppatore tende a sorvolare. C’è quindi la necessità di utilizzare (o creare negli ambiti in cui non esistono) strumenti che siano adatti a raccogliere segnalazioni da utenti inesperti.
Una possibile strada è quella adottata dal progetto kde. In caso di crash di una applicazione kde si avvierà automaticamente un wizard per la compilazione della segnalazione che si occuperà di recuperare alcune informazioni contestuali al problema e posterà il tutto sul bug tracker. La procedura sicuramente aiuta a non mandare una segnalazione completamente inutile ma la descrizione del problema a carico dell’utente dovrà sempre essere adeguata al contesto di un bug tracker.
Un approccio alternativo che ho trovato estremamente interessante in questo caso è quello di kmess (client msn messenger per kde). Il team di kmess per riuscire a ricevere feedback dagli utenti ha sviluppato il progetto LikeBack. Nelle immagini all’interno dell’articolo potete vedere come si presenta l’interfaccia all’utente.
Avrete certamente notato come la possibilità di esprimere un parere positivo, un parere negativo, una idea o segnalare un crash è direttamente riconoscibile dall’interfaccia grazie all’utilizzo di icone azzeccate.
Cliccando sull’icona desiderata ci verrà presentata una schermata che non propone termini tecnici, ma si limiterà a dirci in quale lingua possiamo scrivere per essere compresi e proporrà una semplice text area per descrivere l’idea, il crash o il problema. La possibilità di inserire la propria mail per essere ricontattati permette inoltre di rendere l’utente partecipe della soluzione di un problema solo ed esclusivamente se questo lo desidera. Nessun obbligo di registrazione quindi.
Valerio Pilo, sviluppatore italiano del team che sta dietro a questo progetto in un post sul suo blog ha affermato che in poco più di 6 mesi di utilizzo sono giunte attraverso LikeBack più di 2500 segnalazioni, e che nella quasi totalità si sono rivelate utili.
Per quanto riguarda le richieste di nuove feature sono molto interessanti inoltre i vari siti di BRAINSTORM come quello del progetto Ubuntu e di KDE impostati ancor più su una impronta comunitaria. Questi progetti non solo permettono di proporre idee e funzionalità ma anche di votare e portare alla luce quelle che più ci piacciono.
Credo che la possibilità di parlare con chi sviluppa sia una dei valori aggiunti dei progetti free e open source. Lasciare questo privilegio solo a chi ha una buona preparazione tecnica sarebbe una occasione persa sia per gli sviluppatori che per tutto l’ecosistema.
