Refactor chapter 3

src/chapter_1.md

@@ -11,7 +11,7 @@ La crescente produzione di software basato sul \acl{ML} ha generato un forte imp
 L'attenzione non è stata puntata unicamente sullo studio di nuovi modelli e architetture, ma anche sul processo di sviluppo di questi prodotti per andare a valutare i vari problemi da un punto di vista ingegneristico.
 Il seguente lavoro si muove proprio in questo solco e ha lo scopo di studiare come le componenti di \ac{ML} sono distribuite sull'architettura dei sistemi, ma anche di capire se esistono delle differenze tra gli interventi di *issue fixing* doviti a problematiche di \acl{ML} e quelli generici.
 
-## Obbiettivi della tesi
+## Obbiettivi della tesi {#sec:goals}
 
 Questo studio vuole verificare la presenza di differenze, all'interno di progetti di \acl{ML}, rispetto a come sono trattate le *issues* legate a tematiche di \ac{ML} e quelle generiche.
 In particolare si vuole capire come la risoluzione di queste problematiche va ad impattare sull'architettura, sia in termini di moduli modificati sia in termini di entropia generata.
@@ -22,7 +22,7 @@ Infine si vuole capire se le *issues* sono trattate tutte allo stesso modo per q
 
 Nella @sec:related-works viene svolta una panoramica sui lavori correlati.
 Nella @sec:methodology vengono presentate le *research question*, viene descritta la procedura utilizzata per la raccolta dei commit e delle issues e come queste sono state classificate.
-Inoltre viene illustrata la metodologia di analisi impiegata per lo studio di ogni *\ac{RQ}*
+Inoltre viene illustrata la metodologia di analisi impiegata per lo studio di ogni *\ac{RQ}*.
 I risultati delle analisi e una discussione qualitativa su alcuni *casi estremi* sono riportati nella @sec:results.
 Infine la @sec:conclusions chiude questa tesi.
 

src/chapter_3.md

@@ -2,7 +2,7 @@
 
 ## Research Questions
 
-Questo studio ha l'obiettivo di dare una risposta a queste cinque domande:
+Gli obiettivi di questa tesi illustrati nella @sec:goals sono stati racchiusi in cinque \ac{RQ} di seguito elencate.
 
 - **RQ1**: *come il \ac{ML} e' distribuito sull'architettura dei progetti?*
 
@@ -49,7 +49,7 @@ Alla fine di questa seconda fase il numero di progetti è sceso a trenta.
 ## Fetch di issues e commit
 
 Una volta individuati i progetti da analizzare si è reso necessario recuperare l'intera storia dei progetti e le issues ad essi associate.
-Per entrambe le operazioni è stato utilizzato il tool *perceval*[@duenas2018percevalsoftwareproject].
+Per entrambe le operazioni è stato utilizzato il tool *perceval* [@duenas2018percevalsoftwareproject].
 Nel caso delle issues, essendo queste informazioni non direttamente contenute all'interno del repository `git`, è stato necessario utilizzare nuovamente l'\ac{API} di GitHub.
 Poiché le chiamate associate ad un singolo *token* sono limitate nel tempo si è scelto di configurare *perseval* in modo tale da introdurre in automatico uno ritardo ogni qualvolta veniva raggiunto il limite.
 Inoltre il codice è stato dispiegato su un \ac{VPS} in modo da poter eseguire il fetch senza che fosse necessario mantenere attiva una macchina fisica.
@@ -64,8 +64,8 @@ Con il processo precedentemente illustrato è stato possibile recuperare:
 ### Classificazione delle issues {#sec:classificazione-issues}
 
 Al fine di poter eseguire un confronto tra i *fix* di \ac{ML} e quelli *generici* è stato necessario classificare sia le issues che i commit.
-Per quanto riguarda i primi si è scelto di attuare una classificazione basata sul testo, in particolare considerando il titolo e il corpo della issue, ma escludendo i commenti di risposta in modo da non rendere i dati troppo rumorosi.
 Il numero elevato di elementi non rende praticabile una classificazione manuale per cui si è optato per una classificazione automatica.
+Per quanto riguarda i primi si è scelto di attuare una classificazione basata sul testo, in particolare considerando il titolo e il corpo della issue, ma escludendo i commenti di risposta in modo da non rendere i dati troppo rumorosi.
 A tal fine sono stati implementati ed analizzati due classificatori, uno supervisionato e uno non supervisionato.
 
 I due modelli considerati sono:
@@ -79,8 +79,9 @@ In questo modo tutte le issues che utilizzavano almeno un vocabolo tipico del \a
 
 Nel caso del modello *naïve Bayes*, essendo questo un algoritmo di apprendimento supervisionato, si è resa necessaria una classificazione manuale delle issues.
 A tal scopo è stato eseguito un campionamento stratificato in base al progetto di provenienza di $376$ issues che sono state divise tra due lettori e labellate.
+La label delle *issues* è stata determinata andando analizzare il titolo, il corpo e i commenti associati alla *issue*.
 Durante il labeling si scelto di classificare ulteriormente le issue di \ac{ML} al fine di individuare anche la fase in cui il problema si è palesato.
-La definizioni delle varie fasi è avvenuta partendo da un lavoro di *Microsoft*[@amershi-2019-softwareengineeringmachine].
+La definizioni delle varie fasi è avvenuta partendo dal lavoro di Amershi *et al.* [@amershi-2019-softwareengineeringmachine] realizzato nei laboratori di *Microsoft*.
 
 Le fasi considerate sono:
 
@@ -112,9 +113,9 @@ Mentre le performance del primo modello sono state valutate sull'intero dataset.
   \label{fig:labeling}
 \end{figure}
 
-Al fine di poter confrontare i due modelli sono state utilizzate le metriche di precision e recall.
-Com'è possibile notare dai valori riportati in @tbl:confronto-modelli-classificazione-issues, il modello basato sulla lista di vocaboli è leggermente più preciso del modello bayesiano, ma presenta una recall decisamente più bassa.
-Dalla @fig:labeling-type si evince la natura minoritaria delle issues di \ac{ML} rispetto alle issues generiche, per questo motivo si è scelto di preferire il modello naïve Bayes in modo da perdere quante meno istanze possibili anche a costo di sacrificare leggermente la precisione.
+Al fine di poter confrontare i due modelli sono state utilizzate le metriche di *precision* e *recall*.
+Com'è possibile notare dai valori riportati in @tbl:confronto-modelli-classificazione-issues, il modello basato sulla lista di vocaboli è leggermente più preciso del modello bayesiano, ma presenta una *recall* decisamente più bassa.
+Dalla @fig:labeling-type si evince la natura minoritaria delle issues di \ac{ML} rispetto alle issues generiche, per questo motivo si è preferito il modello naïve Bayes in modo da perdere quante meno istanze possibili anche a costo di sacrificare leggermente la precisione.
 
 |           | Classificatore statico | naïve Bayes |
 |-----------|------------------------|-------------|
@@ -132,6 +133,5 @@ Questa operazione ha ridotto il dataset dei commit a $3321$ unità la cui distri
 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}.
 
-\newpage
-
 ![Risultato della classificazione dei commit](figures/count-commit.pdf){#fig:count-commit width=80%}
+