diff --git a/src/chapter_2.md b/src/chapter_2.md
index f0c0325..548bcdb 100644
--- a/src/chapter_2.md
+++ b/src/chapter_2.md
@@ -4,7 +4,7 @@
 
 L'individuazione dei progetti da analizzare è avvenuta mediate l'ausilio dell'\ac{API} messa a disposizione da GitHub.
 In particolare è stata eseguita una query per ottenere una lista di repository che fanno uso di librerie e framework di \ac{ML} come `TensorFlow`, `Pytorch` e `scikit-learn`.
-In questo modo è stato possibile ottenere una lista di $26758$ repository che è stata successivamente filtrata per individuare solo i progetti d'interesse per la seguente analisi.
+In questo modo è stato possibile ottenere una lista di $26758$ repository che è stata successivamente filtrata per individuare solo i progetti d'interesse per il seguente studio.
 
 L'operazione di filtraggio è avvenuta attraverso due fasi; una prima automatica e una seconda manuale.
 La prima fase ha avuto l'obiettivo di selezionare unicamente i repository *popolari*.
@@ -49,7 +49,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}.
-Questa lista 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 su lavori precedenti[@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.
@@ -108,4 +108,3 @@ A questo punto è stato possibile separare i *fix* di \acl{ML} da quelli generic
 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}.
 
 ![Risultato della classificazione dei commit](figures/count-commit.pdf){#fig:count-commit}
-
diff --git a/src/chapter_3.md b/src/chapter_3.md
index 7dc514d..a69e133 100644
--- a/src/chapter_3.md
+++ b/src/chapter_3.md
@@ -22,8 +22,8 @@ Un'ulteriore aspetto interessante riguarda la varianza delle distribuzioni, infa
 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 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 sono state incluse anche librerie utilizzate spesso in ambito \ac{ML}, ma anche in altri ambiti, come ad esempio `pandas`, `numpy` e `scipy`.
+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`.
 
 ![Percentuale di file che utilizzano librerie di ML](figures/imports.pdf){#fig:imports width=70%}
 
@@ -124,5 +124,7 @@ Questo vuol dire che il $50\%$ basso dei *bug* di \ac{ML} viene comunque risolto
 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 ci indica che i *bug* di \ac{ML} sono più difficili di quelli generici il che spiegherebbe anche il dato emerso dalla sezione precedente, in quanto per individuare la fonte del problema è necessaria una discussione più approfondita.
+
+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.