Gestione delle segnalazioni¶

Quando un utilizzatore trova una funzionalità mancante o un problema sul codice, può aprire una issue (segnalazione) per notificare un problema in modo che esso venga preso in considerazione e corretto.

L’Allegato B alle Linee guida su acquisizione e riuso di software per le pubbliche amministrazioni descrive proprio questi aspetti legati alla manutenzione di software open source.

I sistemi di versionamento del codice, solitamente, dispongono di meccanismi per registrare issue e per seguire la loro risoluzione. Quando si usano tali sistemi, è buona pratica che chi gestisce le issue risponda abbastanza tempestivamente alle segnalazioni indicando la presa in carico e specificando le modalità e le tempistiche con cui saranno risolte.

L’allegato alla linee guida descrive alcune interazioni tipiche che possono verificarsi sul sistema di code hosting di un software open source:

• risoluzione di bug;

• richieste di nuove funzionalità;

• richieste di informazioni o supporto;

• contributi di codice.

L’Ente che ha rilasciato il software deve tendenzialmente occuparsi di garantirne il mantenimento, impostando il flusso di gestione e intervento sulle segnalazioni che provengono dall’esterno. Le segnalazioni, quindi, devono essere monitorate e prioritizzate. Si interverrà poi su alcune di esse, per risolverle e chiuderle.

Diverse issue possono essere prese in carico in un unico periodo e portare al rilascio di una nuova versione del software che le risolve tutte contemporaneamente. In questo caso il progetto lavora per milestone, e ogni milestone risolve un numero variabile di issue aperte nel periodo precedente.

Gestione delle richieste di modifica¶

Quando un contributore invia una richiesta di modifica al codice tramite pull/merge request il maintainer è tenuto a dare un riscontro tempestivo, anche solo per ringraziare il contributore in attesa della revisione del codice. Fornire un feedback immediato ai contributori aiuta a comunicare che il progetto è vivo e mantenuto e incoraggia altri contributi esterni. In questo modo, inoltre, si evita che, non vedendo riscontri, gli altri sviluppatori proseguano lo sviluppo in un proprio fork.

Dichiarazione di obsolescenza di un progetto¶

Può capitare che un repository non venga più mantenuto o esaminato e quindi non sia più di interesse, è tuttavia utile conservarlo per scopi di archiviazione e visualizzazione pubblica. In questo caso è importante denominare il repository come deprecated (obsoleto) in modo da segnalare che il progetto non è più attivo e mantenuto ma è conservato per scopi di archiviazione.