master-thesis/src/chapter_3.md

Analisi

RQ1: come il ML e' distribuito sull'architettura dei progetti?

In questa prima analisi si è andato a verificare l'esistenza di una differenza nei files e nelle directories modificate in base al tipo di cambiamento. Per poter svolgere questa analisi è stato necessario individuare il numero totale di file modificati per fix generici e per i fix specifici del \acl{ML}. A tal fine i commit sono stati raggruppati rispetto al progetto e al tipo di cambiamento (\ac{ML}, no \ac{ML}) e per ogni istanza di questo raggruppamento si è eseguito l'union set dei files modificati. Come output di questa fase si è generato per ogni progetto:

• l'insieme dei file modificati per fix di \ac{ML}
• l'insieme dei file modificati per fix generici

Infine eseguendo l'union set tra questi due insiemi si è ottenere l'insieme totale dei files modificati durante i fix. In questo modo è stato possibile andare a valutare la percentuale di files modificati in relazione al tipo di cambiamento. Attraverso la funzione di libreria Python os.path.dirname sono stati ottenuti i tre insiemi sopra citati anche per quanto riguarda le directories.

Dalla @fig:files-directories si può notare che i cambiamenti generici vanno ad impattare su una superficie maggiore del sistema, sia che l'analisi sia svolta al livello di files che di directories. Un'ulteriore aspetto interessante riguarda la varianza delle distribuzioni, infatti, indipendentemente dalla granularità dell'analisi, il dato riguardante i cambiamenti di \acl{ML} è caratterizzato da una maggiore varianza.

{#fig:files-directories width=80%}

Un'ulteriore analisi rispetto all'architettura dei progetti è stata svolta mediante gli import. Attraverso uno script sono stati estratti, per ogni file, gli import utilizzati all'interno del file stesso. A questo punto sono stati individuati i files di \acl{ML} in base agli import utilizzati. La classificazione è avvenuta utilizzando due livelli di severità; in un primo (severità strict) caso sono stati considerati come import di \acl{ML} solo delle librerie strettamente di \ac{ML} come ad esempio keras, TernsorFlow, PyTorch, ecc. Mentre in un secondo caso (severità base) sono state incluse anche librerie utilizzate spesso in ambito \ac{ML}, ma anche in altri ambiti, come ad esempio pandas, numpy e scipy.

{#fig:imports width=70%}

Dal boxplot riportato in @fig:imports si può notare che, indipendentemente dalla severità dell'analisi, la percentuale di file che utilizzano librerie di \acl{ML} è caratterizzata da una forte varianza. Ciò indica che i progetti inclusi all'interno dello studio sono di varia natura e che alcuni sono più incentrati sul \ac{ML} rispetto ad altri. Inoltre, considerando l'analisi strict, è possibile osservare come solo un 25\% dei progetti abbia una percentuale di files di \ac{ML} superiore al 45\%.

RQ2: come sono distribuiti i bug sulle diverse fasi di ML?

Come illustrato nella @sec:classificazione-commit per poter determinare la natura di un issue fix si è fatto ricorso alla classificazione delle issues ad esso associate. La maggior parte delle issues è stata classificata automaticamente, ma è stato comunque necessario classificarne una porzione in modo manuale per poter avere un train/test set. Come detto precedentemente, nel caso delle issues classificate a mano, oltre all'individuazione della tipologia (\ac{ML}, non \ac{ML}) è stata individuata anche la fase in cui il problema si palesava (si veda @sec:classificazione-issues). Questo dato aggiuntivo presente su alcune issues è stato proiettato anche sulla classificazione dei commit di fix per andare a valutare come questi sono distribuiti sulle varie fasi. I risultati di questa analisi sono riportati in @fig:count-fix-phases.

{#fig:count-fix-phases width=70%}

Rispetto alla distribuzione sulle issues (@fig:labeling-phases) è possibile notare la scomparsa della fase data collection, inoltre è evidente anche la riduzione delle occorrenze di model training e una crescita d'importanza per quanto riguarda le fasi di model requirements e model deployment. Sfortunatamente i dati disponibili per questa analisi sono molto limitati (è stato possibile ricavare la fase solo per quaranta fix), per cui non è stato possibile effettuare delle analisi più approfondite.

RQ3: esiste una differenza di entropy tra ML bug e altri bug?

La successiva analisi avevo lo scopo di verificare l'esistenza di una differenza tra l'entropia del fix rispetto alla natura di questi. L'analisi è stata svolta sia a livello di file, sia a livello di linee, quindi per ogni commit del dataset è stato necessario individuare sia il numero di file che hanno subito delle modifiche, sia il numero di linee alterate, considerando in questo modo sia le aggiunte che le rimozioni.

Inoltre per poter valutare l'entità del cambiamento è stato necessario conoscere anche il numero totale di file e di linee di ogni progetto. Questi valori sono stati calcolati attraverso la storia git del branch master¹. Per ogni commit sono stati individuati i file aggiunti (+1) e rimossi (-1) in modo tale da poter calcolare il delta-cambiamento del commit. Eseguendo la somma di questo delta su tutti i commit si è ottenuto il numero totale di file del progetto. In modo analogo si è proceduto anche per quanto riguarda le linee.

Una volta note queste informazioni preliminari è stato possibile calcolare l'entropia dei fix che è stata riportata nei boxplot² in @fig:entropy. Dal boxplot in @fig:files-entropy è possibile notare una distribuzione equivalente per le due tipologie di fix. Una situazione analoga si riscontra anche nell'analisi sulle linee (@fig:lines-entropy) anche se in questo caso è possibile notare che i valori di entropia associati ai fix di \ac{ML} sono shiftati leggermente verso l'alto.

\begin{figure}[!ht] \subfloat[Entropia calcolata sui files\label{fig:files-entropy}]{% \includegraphics[width=0.45\textwidth]{src/figures/files-entropy.pdf} } \hfill \subfloat[Entropia calcolata sulle linee\label{fig:lines-entropy}]{% \includegraphics[width=0.45\textwidth]{src/figures/lines-entropy.pdf} } \caption{Entropia in base al tipo di fix} \label{fig:entropy} \end{figure}

Per verificare la rilevanza statistica di questa diversità sono stati svolti il ranksum test e il Cliff's delta i cui risultati sono riportati nella @tbl:test-entropy. Nel caso dell'entropia sui file possiamo dire che la differenza è marginale poiché il p-value è prossimo a 0.05, mentre nel caso dell'entropia calcolato sulle linee la differenza viene confermata dal test. In entrambi i casi, l'effect size è trascurabile.

	ranksum p-values	Cliff's delta
file entropy	0.059	0.044
line entropy	5.932e-06	0.105

: Risultati dei test statistici per quanto riguarda l'entropia {#tbl:test-entropy}

RQ4: come varia il livello di discussione tra ML bug e altri bug?

Per rispondere a questa domanda è stato necessario andare a valutare il numero di commenti presenti all'interno di ogni issues. Poiché un singolo commit può far riferimento a più issues è stato considerato il numero di commenti medi. I risultati ottenuti sono stati riportati nel boxplot³ in @fig:discussion-comments.

In questo caso si evince una differenza molto più marcata tra le due distribuzioni. In particolare è possibile notare che le issue fix di \ac{ML} presentano una maggiore discussione e anche una maggiore varianza. Se consideriamo la differenza interquartile, in modo da escludere completamente eventuali outlier, possiamo osservare che nei fix generici questa varia tra zero e uno. Ciò vuol dire che il 50\% interno delle issues o non presenta commenti o ne presenta uno solo. Mentre la differenza interquartile dei fix di \acl{ML} è compreso tra uno e cinque quindi nel 50\% interno tutte le issues hanno almeno un commento di risposta.

\begin{figure}[!ht] \subfloat[Numero di commenti medi\label{fig:discussion-comments}]{% \includegraphics[width=0.45\textwidth]{src/figures/comments.pdf} } \hfill \subfloat[Numero di parole medie per commento\label{fig:discussion-words}]{% \includegraphics[width=0.45\textwidth]{src/figures/words.pdf} } \caption{Livello di discussione in base al tipo} \label{fig:discussion} \end{figure}

A questo punto si è cercato di capire se al maggior numero di commenti è associata effettivamente una maggiore quantità di informazioni scambiate. Per svolgere questa analisi si è partiti dal presupposto che la quantità di informazioni scambiate sia proporzionale al numero di parole utilizzate nel commento. Quindi per ogni issue è stato calcolato il numero medio di parole presenti all'interno di un commento. I risultati di quest'ulteriore analisi sono riportati in @fig:discussion-words. Anche in questo caso si può vedere che nel caso di \ac{ML} fix la distribuzione presenta valori più elevati e maggiore varianza. Per cui non solo nei fix di \acl{ML} c'è maggiore discussione, ma la discussione è anche più densa.

Anche in questo caso sono stati svolti i test statistici. In @tbl:test-discussion è possibile vedere come per entrambe le metriche considerate il p-value sia abbondantemente inferiore alla soglia di 0.05 quindi abbiamo una conferma della diversità delle due distribuzioni riscontrata dal boxplot. Inoltre, per entrambe le metriche, abbiamo un effect size medio.

	ranksum p-values	Cliff's delta
commenti medi	9.053e-75	0.425
parole per commento	2.889e-59	0.377

: Risultati dei test statistici per quanto riguarda il livello di discussione {#tbl:test-discussion}

RQ5: come varia il time-to-fix tra ML bug e altri bug?

In quest'ultima analisi si vuole andare a valutare se c'è differenza nel tempo necessario per eseguire il fix. Per valutare questo parametro è stato necessario estrarre da ogni issue la data di apertura e di chiusura e calcolare i giorni che intercorrono tra queste. I risultati così ottenuti sono stati riportati in @fig:day-to-fix.

{#fig:day-to-fix width=70%}

Anche in questo caso è possibile notare una netta differenza tra i fix di \ac{ML} e gli altri. In particolare i bug di \acl{ML} necessitano, mediamente, di maggior tempo per essere risolti e sono caratterizzati da una varianza maggiore. Inoltre è possibile vedere come la mediana non sia centrata, bensì spostata verso il basso. Questo vuol dire che il 50\% basso dei bug di \ac{ML} viene comunque risolto in tempi brevi (due giorni circa), mentre l'altro 50\% può richiedere una quantità di tempo decisamente superiore.

Un'ulteriore testimonianza del maggior tempo necessario per risolvere le problematiche legate al \ac{ML} ci viene data dagli outlier. Nel caso di un problema generico, questo, viene considerato come anomalo se per essere risolto necessita di un tempo superiore ai cinque giorni. Mentre nel caso dei fix di \acl{ML} per essere considerato outlier un issue, necessaria di un time-to-fix superiore ai trentacinque giorni.

Il maggior tempo necessario ad attuare la correzione indica che i bug di \ac{ML} sono più difficili da individuare e correggere rispetto a quelli generici. Inoltre questo risultato contribuisce a spiegare il dato emerso dalla sezione precedente, in quanto per individuare la fonte del problema sembrerebbe essere necessaria una discussione più approfondita.

Anche per quest'ultima RQ sono stati svolti i test statistici illustrati precedentemente. Dai risultati riportati in @tbl:test-time-to-fix è possibile notare un p-value inferiore a 0.05 e un effect size medio.

	ranksum p-values	Cliff's delta
day-to-fix	7.354e-53	0.355

: Risultati dei test statistici per quanto riguarda il time-to-fix {#tbl:test-time-to-fix}

---

1. Oltre al branch master è stato considerato anche il branch main diventato molto comune dopo le proteste del movimento Black Lives Matter e il branch master-V2 unico branch utilizzato da un progetto. ↩︎

2. Per ragioni di visualizzazione è stato scelto il $95$-esimo quantile come limite superiore di entrambi i grafici. ↩︎

3. In questo caso il limite superiore è pari al $97$-esimo quantile. ↩︎