Fix chapter 3

src/chapter_3.md

@@ -2,28 +2,28 @@
 
 ## Research Questions
 
-Gli obiettivi di questa tesi illustrati nella @sec:goals sono stati racchiusi in cinque \ac{RQ} di seguito elencate.
+Gli obiettivi di questa tesi illustrati nella @sec:goals sono stati racchiusi in cinque \acl{RQ} di seguito elencate.
 
 - **RQ1**: *come il \ac{ML} e' distribuito sull'architettura dei progetti?*
 
-  In questa *RQ* si vuole investigare l'architettura dei progetti.
+  In questa *\ac{RQ}* si vuole investigare l'architettura dei progetti.
   In particolare l'attenzione viene concentratala sui files e sulle directories modificate durante interventi di *issues fixing*.
   Obbiettivo di questa domanda è anche individuare la percentuale di files che utilizzano import riconducibili a librerie e framework di \acl{ML}.
 - **RQ2**: *come sono distribuiti i bug sulle diverse fasi di \ac{ML}?* 
 
   Il workflow tipico per lo sviluppo di un'applicazione di \acl{ML} si compone di più fasi.
-  L'obiettivo di questa *RQ* è quello di individuare le fasi più critiche per quanto riguarda l'introduzione di difetti all'interno del prodotto software.
+  L'obiettivo di questa *\ac{RQ}* è quello di individuare le fasi più critiche per quanto riguarda l'introduzione di difetti all'interno del prodotto software.
 - **RQ3**: *esiste una differenza di entropy tra \ac{ML} bug e altri bug?*
 
   A partire dai lavori precedenti svolti sull'entropia di un cambiamento, si vuole capire se esiste una differenza in termini di entropia generata tra le correzioni dei difetti ascrivibili al \acl{ML} e gli altri difetti.
 - **RQ4**: *come varia il livello di discussione tra \ac{ML} bug e altri bug?*
 
-  Questa *RQ* riguarda il livello di discussione dei *bug*.
+  Questa *\ac{RQ}* riguarda il livello di discussione dei *bug*.
   In particolare si vuole capire se, all'interno dei progetti di \acl{ML}, i bug generici sono discussi con lo stesso livello di approfondimento di quelli specifici del \ac{ML}.
 - **RQ5**: *come varia il time-to-fix tra \ac{ML} bug e altri bug?*
 
   Un altro aspetto caratteristico di un *fix* è il tempo necessario per poter essere attuato.
-  Questa *RQ* ha lo scopo di verificare l'esistenza di differenze tra i *bug* generici e quelli di \acl{ML}.
+  Questa *\ac{RQ}* ha lo scopo di verificare l'esistenza di differenze tra i *bug* generici e quelli di \acl{ML}.
 
 ## Selezione dei progetti
 
@@ -74,7 +74,7 @@ I due modelli considerati sono:
 - un modello *naïve Bayes* [@2021naivebayesclassifier; @harrington2012machinelearningaction].
 
 La classificazione mediate il classificatore statico non necessita di un *labeling* manuale dei dati, ma richiede la definizione dei vocaboli tipici del \ac{ML}.
-Lista dei termini caratteristici del \acl{ML} non è stata costruita da zero, ma è basata su lavori precedenti[@humbatova-2019-taxonomyrealfaults].
+Lista dei termini caratteristici del \acl{ML} non è stata costruita da zero, ma è basata sul lavoro di Humbatova *et al.* [@humbatova-2019-taxonomyrealfaults].
 In questo modo tutte le issues che utilizzavano almeno un vocabolo tipico del \acl{ML} sono state classificate come issues di \ac{ML}.
 
 Nel caso del modello *naïve Bayes*, essendo questo un algoritmo di apprendimento supervisionato, si è resa necessaria una classificazione manuale delle issues.
@@ -127,7 +127,7 @@ Dalla @fig:labeling-type si evince la natura minoritaria delle issues di \ac{ML}
 ### Classificazione dei commit {#sec:classificazione-commit}
 
 Prima di poter classificare i commit si è reso necessaria un'ulteriore fase di filtraggio in modo da poter separare i commit di *issue fixing* da quelli generici.
-Sono stati considerati come commit di *fix* tutti quei commit al cui interno veniva fatto riferimento a delle issues attraverso la notazione *"#"*.
+Sono stati considerati come commit di *fix* tutti quei commit al cui interno veniva fatto riferimento a delle *issues* attraverso la notazione *"#"*.
 Questa operazione ha ridotto il dataset dei commit a $3321$ unità la cui distribuzione in base al tipo è riportata in @fig:count-commit.
 
 Da ogni commit sono state estratte le informazioni rilevanti per le analisi.
@@ -142,10 +142,12 @@ In particolare è stato conservato:
 - La lista delle *issues* citate.
 
 A questo punto è stato possibile separare i *fix* di \acl{ML} da quelli generici.
-La classificazione è avvenuta attraverso la lista delle issues citate all'interno del *commit message* e sono stati considerati come commit di \ac{ML} tutti quei commit che facevano riferimento ad almeno una issue di \ac{ML}.
+La classificazione è avvenuta attraverso la lista delle issues citate all'interno del *commit message* e sono stati considerati come commit di \ac{ML} tutti quei commit che facevano riferimento ad almeno una issue di \acl{ML}.
 
 ![Risultato della classificazione dei commit](figures/count-commit.pdf){#fig:count-commit width=80%}
 
+\newpage
+
 ## Metodologia
 
 ### RQ1: come il ML e' distribuito sull'architettura dei progetti?
@@ -153,7 +155,7 @@ La classificazione è avvenuta attraverso la lista delle issues citate all'inter
 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}.
 
-Per poter svolgere la prima analisi analisi è stato necessario individuare il numero totale di file modificati per *fix* generici e per i *fix* specifici del \acl{ML}.
+Per poter svolgere la prima 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}).
 All'interno di ogni raggruppamento si è eseguita la concatenazione della lista dei file modificati.
 Poiché non si è interessati al numero di modifiche che ha subito ogni file le liste sono state trasformate in insiemi per eliminare le ripetizioni.
@@ -180,7 +182,7 @@ Ogni file è stato classificato come di \acl{ML} o meno in base a due livelli se
 Nel caso della severità *base* per rientrare all'interno dei file che fanno uso di librerie di \ac{ML} bastava importare almeno una libreria contenuta in uno dei due gruppi precedentemente descritti.
 Mentre nel caso di severità *strict* era necessario importare almeno una libreria presente nel primo gruppo.
 
-Per entrambe le classificazioni si è andato a valutare a quanto ammontava la percentuale di file di \ac{ML} appartenenti ad un progetto.
+Per entrambe le classificazioni si è andato a valutare a quanto ammontava la percentuale di file di \ac{ML} appartenenti ad ogni 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?
@@ -208,7 +210,7 @@ L'analisi quantitativa è avvenuta attraverso un barplot in cui venivano riporta
 
 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.
-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.
+Il dato rispetto alle linee modificate è già presente nel dataset di partenza (si veda @sec:classificazione-commit), mentre il numero di file modificati può essere ricavato dalla lista dei files modificati nel commit.
 
 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].
@@ -224,9 +226,9 @@ Inoltre sono stati svolti dei test statistici (*ranksum* e *Cliff's delta*) per
 ### 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.
-Questo dato non è presente nel dataset di partenze, ma può essere ricavato a partire dalla lista delle *issues* citate.
-Per ogni *issue* citata si è calcolato il numero di commenti.
-Poiché un singolo commit può far riferimento a più *issues* è stato calcolato il numero di commenti medi.
+Questo dato non è presente nel dataset dei commit generato inizialmente (si veda @sec:classificazione-commit), ma può essere ricavato a partire dalla lista delle *issues* citate.
+Dato un commit si è considerata la lista delle *issues* citate, e per ogni *issue* citata si è calcolato il numero di commenti.
+Poiché un singolo commit può far riferimento a più *issues* è stato necessario anche calcolare il numero di commenti medi.
 
 Il livello della discussione non viene determinato solo dal numero di commenti, ma anche dalla lunghezza di questi.
 Quindi per ogni *issue* è stato calcolato anche il numero medio di parole presenti all'interno di un commento.

src/metadata.yaml

@@ -41,6 +41,8 @@ acronym:
     long: Machine Learning
   - short: NLP 
     long: Natural Language Processing
+  - short: RQ
+    long: Research Question
   - short: SATD
     long: Self-Admitted Technical Debt
   - short: VPS