Quando si parla di contribuire a un progetto open source, si pensa quasi sempre alle pull request con nuove funzionalità. Eppure una parte enorme del lavoro che tiene in vita un progetto non è codice: è spiegare, tradurre, ordinare, verificare, rispondere. Molti manutentori dicono che è proprio questo il lavoro che manca di più, perché è meno visibile e meno gratificante. Ed è un'ottima porta d'ingresso per chi non programma o per chi vuole conoscere un progetto prima di toccarne il codice.
Documentazione
La documentazione è spesso il punto più debole di un progetto tecnicamente solido. Chi la scrive conosce il software troppo bene per accorgersi dei passaggi che dà per scontati. Un utente nuovo, al contrario, li vede tutti.
Contributi concreti:
- correggere istruzioni che non funzionano più con la versione attuale;
- aggiungere un esempio completo per un caso d'uso comune;
- scrivere una guida introduttiva che parte da un'installazione pulita;
- segnalare in modo puntuale le pagine poco chiare, indicando dove ti sei bloccato;
- uniformare terminologia e struttura tra pagine scritte da persone diverse.
Un buon metodo è annotare ogni difficoltà incontrata durante la prima installazione: quell'elenco è già un piano di miglioramento della documentazione.
Traduzioni
Un software disponibile solo in inglese esclude molte persone. Molti progetti usano piattaforme di traduzione collaborativa che non richiedono di usare Git: si traducono le stringhe direttamente nel browser.
Alcune attenzioni rendono la traduzione davvero utile:
- usare il glossario del progetto, o proporne uno, per tradurre sempre allo stesso modo i termini chiave;
- rispettare i segnaposto come
%so{nome}, che non vanno tradotti né spostati arbitrariamente; - provare l'interfaccia tradotta, perché una stringa corretta può essere troppo lunga per un pulsante;
- mantenere, non solo tradurre: le stringhe nuove arrivano a ogni versione.
Triage delle issue
Il triage consiste nel mettere ordine tra le segnalazioni in arrivo. Nei progetti popolari le issue si accumulano più velocemente di quanto i manutentori riescano a leggerle. Chi aiuta può:
- verificare se un bug segnalato è riproducibile con l'ultima versione;
- chiedere le informazioni mancanti all'autore;
- individuare i duplicati e collegarli all'issue originale;
- proporre etichette per tipo, area e priorità, se il progetto lo consente;
- segnalare le issue ormai risolte che possono essere chiuse.
Questo lavoro fa risparmiare ai manutentori ore ogni settimana e, nel tempo, porta spesso a ottenere permessi di gestione del tracker.
Test delle versioni preliminari
Prima di un rilascio molti progetti pubblicano versioni beta o candidate. Provarle sul proprio uso reale, e riferire cosa funziona e cosa no, intercetta problemi che i test automatici non vedono: configurazioni particolari, combinazioni di hardware, flussi di lavoro insoliti. Anche un semplice «ho aggiornato il mio ambiente e tutto funziona» è un'informazione utile, se accompagnato dai dettagli dell'ambiente.
Supporto agli altri utenti
Forum, chat e sezioni di domande sono pieni di richieste che chiunque abbia un po' di esperienza può risolvere. Rispondere lì libera i manutentori dal supporto di base. Alcune regole:
- rispondi solo se sei ragionevolmente sicuro;
- indica la documentazione pertinente, così la risposta resta utile anche dopo;
- se una domanda torna spesso, proponi di aggiungerla alla documentazione.
Design, accessibilità e comunicazione
Altri contributi preziosi e spesso trascurati:
| Ambito | Esempi di contributo |
|---|---|
| Design | Revisione dell'interfaccia, icone, coerenza visiva |
| Accessibilità | Verifica con lettore di schermo, contrasto, navigazione da tastiera |
| Comunicazione | Note di rilascio leggibili, articoli introduttivi, aggiornamento del sito |
| Organizzazione | Gestione di eventi, riunioni, verbali |
L'accessibilità in particolare richiede competenze specifiche che raramente sono presenti tra gli sviluppatori di un progetto.
Come iniziare
Leggi il file CONTRIBUTING.md: molti progetti descrivono anche i contributi non tecnici. Presentati dove la comunità si ritrova e chiedi dove serve aiuto. Comincia con qualcosa di piccolo e ben definito, completalo e solo dopo prendine un altro. Un contributo concluso vale più di tre iniziati.
Nel mio lavoro ho visto persone diventare punti di riferimento di un progetto senza aver mai scritto codice, semplicemente perché erano quelle che conoscevano meglio la documentazione e gli utenti.
In sintesi
- Gran parte del lavoro che tiene in vita un progetto non è codice.
- Documentazione, traduzioni e triage sono i contributi più richiesti.
- Testare le versioni preliminari e aiutare gli utenti alleggerisce molto i manutentori.
- Design, accessibilità e comunicazione richiedono competenze spesso assenti nei progetti.
- Inizia con un compito piccolo e portalo a termine.
