Refactor RQ3

src/chapter_3.md

@@ -148,7 +148,7 @@ La classificazione è avvenuta attraverso la lista delle issues citate all'inter
 
 ## Metodologia
 
-### RQ1: come il ML e' distribuito sull'architettura dei progetti? {#sec:rq1}
+### RQ1: come il ML e' distribuito sull'architettura dei progetti?
 
 In questa prima domanda si vuole andare a capire quant'è ampia la *superficie* del progetto che viene modificata durante gli interventi di *fix*, facendo distinzione tra le correzioni che riguardano il \ac{ML} e quelle generiche.
 Inoltre si vuole anche capire quanti file importano librerie tipiche del \acl{ML}.
@@ -183,7 +183,7 @@ Mentre nel caso di severità *strict* era necessario importare almeno una librer
 Per entrambe le classificazioni si è andato a valutare a quanto ammontava la percentuale di file di \ac{ML} appartenenti ad un progetto.
 Anche i questo caso le distribuzioni sono state analizzate attraverso l'ausilio di un boxplot.
 
-### RQ2: come sono distribuiti i bug sulle diverse fasi di ML? {#sec:rq2}
+### 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.
@@ -204,12 +204,13 @@ In particolare un commit poteva citare:
 
 L'analisi quantitativa è avvenuta attraverso un barplot in cui venivano riportati unicamente i commit a cui è stato possibile assegnare almeno una fase.
 
-### RQ3: esiste una differenza di entropy tra ML bug e altri bug? {#sec:rq3}
+### 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.
+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.
+Il dato rispetto alle linee modificate è già presente nel dataset di partenza, mentre il numero di file modificati può essere ricavato dalla lista dei files modificati nel commit.
 
-Inoltre per poter valutare l'entità del cambiamento è stato necessario conoscere anche il numero totale di file e di linee di ogni progetto.
+Inoltre per poter calcolare la probabilità di un 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`[^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.
@@ -217,7 +218,10 @@ In modo analogo si è proceduto anche per quanto riguarda le linee.
 
 [^branch-master]: 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.
 
-### RQ4: come varia il livello di discussione tra ML bug e altri bug? {#sec:rq4}
+Le due distribuzioni sono state valutate graficamente attraverso un boxplot.
+Inoltre sono stati svolti dei test statistici (*ranksum* e *Cliff's delta*) per verificare la rilevanza di queste differenze.
+
+### 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.
@@ -226,7 +230,7 @@ A questo punto si è cercato di capire se al maggior numero di commenti è assoc
 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.
 
-### RQ5: come varia il time-to-fix tra ML bug e altri bug? {#sec:rq5}
+### 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.