Il virtuosismo delle segnalazioni nel mondo Open Source

- Open Source, Programmazione

Rispolverando i dati delle statistiche degli articoli più letti sul mio sito ho visto che questo mio articolo del 2014 ha ancora un discreto successo.

All’epoca mi ricordo che scrissi quell’articolo perché ero entrato da poco nel mondo open source e cominciavo a fare i primi contributi e a lavorare col software libero in modo virtuoso, ovvero contribuendo.


Sfruttando il sito https://github-contributions.now.sh/ lanciato recentemente possiamo vedere la mia evoluzione. Il numero di commit per anno ultimamente è diminuito probabilmente dal fattore lavoro e dai nostri repo privati che non possono essere conteggiati.

All’epoca bazzicavo anche su Bugzilla di KDE e su altri progetti che seguivo quindi per me era nato questa necessità: se qualcosa non va apro un ticket.

All’epoca diventò un tormentone per cui la gente mi prendeva in giro ma è stato anche il primo passo per farmi capire di più l’open source. Ricordo ancora l’ansia della prima volta che ho aperto un ticket su Debian o risposto ad uno già esistente. Se scrivevo una cavolata mi avrebbero preso in giro oppure chiuso il ticket senza farsi troppi problemi.

Quindi nel tempo ho sviluppato la mia tecnica nello scrivere dei ticket in modo tale che sia difficile rispondermi sgarbatamente e anche se il mio inglese fa schifo non se la prendano.

Per questo parlo di Virtuosismo, avere una padronanza dello strumento ma anche capirne la sua importanza. Tempo fa scrissi un altro articolo molto letto che ho aggiornato l’anno scorso, riguardo proprio il perché della mia attività nell’open source.

Seguendo la mia filosofia personale, nata dalla mia esperienza cattolica, dove ognuno può fare la differenza ed ha il dovere di rendere il posto migliore per gli altri io mi sono reso conto di averla indirizzata nel mondo Open Source.
Semplicemente se trovo un progetto o un servizio se c’è qualcosa che non va contatto l’assistenza che sia un ticket o un email. Nel tempo ho scritto anche a GitHub o Appear per segnalare problemi oppure facendo suggerimenti ad altri progetti che trovo sulla rete.

Il vantaggio del fare una segnalazione è che qualcuno penserà a quello che si è scritto quindi è importante fare la richiesta in modo “ottimizzato” perché probabilmente qualcuno la prenderà in carico (o forse noi stessi) e avremo quella cosa che ci serve assolutamente.

Inoltre questo stimolo è interessante perché ti permette di fare cose che nessuno poteva pensare che fosse possibile come questo (nato dalla esperienza in questo), oppure questo,  o questo, o questo e così via.

Come fare un ticket

Vuoi aprire un ticket e vuoi essere costruttivo? Vuoi dare una mano ma non hai il tempo?

Con queste due domande è facile immedesimarsi in chi dovrà vagliare la tua richiesta e quindi immedesimarsi.

Chi gestisce un progetto spesso ha carenza di tempo quindi bisogna fornire il più possibile informazioni utili e non lamentele. Spesso fornire qualche esempio o user case aiuta ad evitare un rifiuto superficiale e obbligherà a leggere il ticket per poterlo analizzare nei dettagli.

Quindi la propria visione del problema o di richiesta funzionalità è molto utile perché fornisce il contesto. Mettiamo caso che vi rispondano dopo 2 mesi e ti chiedono maggiori dettagli ma tu non ti ricordi niente. Se li fornisci subito è più facile che la tua richiesta venga elaborata velocemente perché non sono necessari scambi di informazioni.

Lo stile invece deve essere cordiale. A nessuno piace leggere lamentele, neanche se costruttive, anche perché spesso il problema potrebbe essere un utilizzo sbagliato oppure qualcosa che non è stato notato. Questo approccio è utile anche con i centri di assistenza che trovandosi una persona cordiale rispondono cordialmente e sono più propensi ad aiutare.

Spesso in casi di dubbi chiudere anche il messaggio con qualcosa del tipo:

  • La prima volta che uso il progetto e quindi non sono sicuro
  • Non sono sicuro di usarlo correttamente
  • Sono io che sbaglio qualcosa o è proprio così?

Questi escamotage linguistici ti mettono da un punto di vista cordiale e che ne vuoi sapere di più e quindi rispondere è molto più semplice.

Sinceramente ho visto questo approccio funzionare molto bene, in alcuni casi di incomprensione usare la carta anche che il mio inglese non è il massimo o non essere un esperto ha aiutato a diminuire i toni e rendere gli altri partecipanti più invogliati a spiegarsi e fornire maggiori informazioni.

Inoltre aiuta anche in caso se ne debbano fare molte per non risultare antipatico o asfissiante quindi per lavoro dove la velocità e raccolta informazioni sono fondamentali è meglio andare sul sicuro.

Come rispondere ad un ticket

Se il progetto è il nostro come conviene rispondere?

Semplice seguendo le stesse regole evitando la parte del “non esperto” naturalmente 🙂

Chiedere maggiori informazioni, verificare la richiesta o anche fare dei riferimenti al codice nella risposta nel progetto (aiuta ad invogliare altri a fare la modifica al posto tuo) dimostrano la propria professionalità e disponibilità.

In ogni caso documentare anche la chiusura di una richiesta è importante perché la persona ha impiegato del tempo per poterla fare ed è bruttissimo vedersela chiudere con un “It is not our priority”.

Inoltre una risposta celere è veramente apprezzata perché dimostra di stare sul pezzo e di essere veramente interessati a risolvere la questione.

Spesso io in risposta faccio anche delle proposte su come poter applicare la richiesta di funzionalità oppure su come risolvere il bug in modo tale da avviare una conversazione produttiva ed invogliare chi legge e chi scrive a farne di più ed appassionarsi al progetto.

Inoltre non facciamoci problemi a prenderci la colpa in caso di un problema perché dimostra onestà e permette di abbassare il livello tra maintainer e chi ha fatto la richiesta.

Il virtuosismo delle segnalazioni

Riflettiamoci un attimo se a tutte le lamentele di ogni giorno o richieste ricevessimo risposte costruttive. Anche dall’ente locale ad esempio. Quanto sarebbe bello!

Facciamo noi il primo passo perché è difficile che ad una richiesta esaustiva (non una lamentela) e completa di esempi e suggerimenti su come applicarla si ottengano risposte negative o che non arrivino ad un compromesso. Anche in ambito giornaliero.

Dal punto di vista personale aiuta anche a pensare in modo costruttivo e non essere incavolati tutti il giorno. Aiuta ad essere ottimisti ed essere contenti quando la richiesta viene accettata e tu non vedi l’ora di approfittarne.

Come in tutte le cose quando qualcosa non funziona bisogna farsi sentire solo che c’è un metodo che è quello costruttivo e di disponibilità che nella mia esperienza si è dimostrato molto utile per velocizzare ed essere sicuri di una risoluzione che ci interessi.

Ovviamente il metodo non è infallibile al 100% però da una buona sicurezza e rende l’ecosistema più produttivo e facile/piacevole viverci (anche in mancanza di tempo). Oltre a creare una documentazione utile nel tempo che può esserci utile per qualunque cose. Spesso ho visto come i miei stessi articoli o richieste dopo tempo fossero attuali o senza risposta e documentarle permette di non perdersi su Slack che non va bene per questo.

Liked it? Take a second to support Mte90 on Patreon!

Become a Patreon
All the stuff released in this website, where the author is Daniele Scasciafratte, is under the GPL 2.0 license except when the resources have their licenses.

Lascia un commento