# Conclusioni {#sec:conclusions}

La *RQ1* (@sec:rq1) ci ha permesso di inquadrare la natura dei progetti considerati per questo studio.
Attraverso l'analisi degli import si è mostrato come l'utilizzo di librerie di \ac{ML} vari a seconda del progetto.
Da questo dato si può capire che i progetti all'interno del dataset sono diversi tra di loro e che alcuni sono più incentrati sul \ac{ML} rispetto ad altri.
Si è anche visto che la percentuale di progetti con un numero di *source files* di \ac{ML} superiore al $45\%$ sia molto limitata.
Inoltre andando ad analizzare la porzione di sistema impattata dai cambiamenti si è visto come anche in questo caso il dato sia caratterizzato da una forte variabilità.

Le *RQ3*, *RQ4* e *RQ5* (da @sec:rq3) sono andate a valutare nello specifico le differenze in termini di entropia, discussione e *time-to-fix* tra gli interventi di *issue fixing* generici e quelli specifici del \ac{ML}.
Da queste analisi si evince che tra i due tipi di interventi ci sono sia similitudini che differenze.
Nel caso dell'entropia e della complessità del processo di cambiamento del software non sono emerse differenze rilevanti.
Questo ci porta a pensare che il processo di cambiamento non varia in base al tipo di intervento, ma sia costante.

Nel caso del livello di discussione e del *time-to-fix* sono emerse delle differenze confermate anche dai test statistici effettuati.
In entrambi i casi l'essere un *fix* legato al \ac{ML} ha spinto la metrica verso l'alto.
Nel caso dei messaggi scambiati non solo si è riscontrato un numero medio di messaggi più elevato, ma si è visto anche che questi mediamente sono più lunghi.
Questo dato potrebbe dipendere sia dal maggiore tempo richiesto per d'individuazione e correzione delle problematiche legate al \ac{ML}, sia da un maggiore interesse per queste problematiche rispetto alle altre.

## Sviluppi futuri

Nella *RQ2* sfortunatamente non è stato possibile svolgere un'analisi più approfondita per la carenza di dati.
Un possibile sviluppo futuro potrebbe consistere nella realizzazione di un classificatore *multi-label* in grado di individuare la fase in cui il problema si è manifestato.
In questo modo non solo sarebbe possibile conoscere la fase per ogni intervento di *fix*, ma anche definire delle nuove analisi.
Per esempio si potrebbe andare a ricercare differenze in termini di entropia, discussione e *time-to-fix* in base alla fase in cui si è presentata la *issue*.

Per quanto riguarda la valutazione dell'entropia si è scelto come intervallo temporale di riferimento il singolo commit.
Utilizzando questa configurazione non si è riscontrata nessuna differenza degna di nota.
Un possibile sviluppo futuro potrebbe consistere nell'andare a valutare l'entropia considerando dei riferimenti temporali più ampi e verificare in questo caso la presenza di differenze.