diff --git a/src/chapter_3.md b/src/chapter_3.md
index c7180fc..c97b3cb 100644
--- a/src/chapter_3.md
+++ b/src/chapter_3.md
@@ -1,6 +1,6 @@
 # Analisi
 
-## RQ1: come il ML e' distribuito sull'architettura dei progetti?
+## RQ1: come il ML e' distribuito sull'architettura dei progetti? {#sec:rq1}
 
 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}.
@@ -31,7 +31,7 @@ Dal boxplot riportato in @fig:imports si può notare che, indipendentemente dall
 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?
+## RQ2: come sono distribuiti i bug sulle diverse fasi di ML? {#sec:rq2}
 
 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.
@@ -44,7 +44,7 @@ I risultati di questa analisi sono riportati in @fig:count-fix-phases.
 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?
+## RQ3: esiste una differenza di entropy tra ML bug e altri bug? {#sec:rq3}
 
 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.
@@ -86,7 +86,7 @@ In entrambi i casi, l'*effect size* è trascurabile.
 
 : 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?
+## RQ4: come varia il livello di discussione tra ML bug e altri bug? {#sec:rq4}
 
 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.
@@ -130,7 +130,7 @@ Inoltre, per entrambe le metriche, abbiamo un *effect size* medio.
 
 : 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?
+## RQ5: come varia il time-to-fix tra ML bug e altri bug? {#sec:rq5}
 
 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.
diff --git a/src/chapter_4.md b/src/chapter_4.md
new file mode 100644
index 0000000..d1348d3
--- /dev/null
+++ b/src/chapter_4.md
@@ -0,0 +1,29 @@
+# Conclusioni
+
+La *RQ1* (@sec:rq1) ci ha permesso di inquadrare la natura dei progetti considerati per questo studio.
+Attraverso l'analisi degli import si è mostrato come l'utilizzo di librerie di \acl{ML} vari a seconda del progetto.
+Da questo dato si può capire che i progetti all'interno del dataset sono diversi tra di loro e che alcuni sono più incentrati sul \ac{ML} rispetto ad altri.
+Si è anche visto che la percentuale di progetti con un numero di *source files* di \acl{ML} superiore al $45\%$ sia molto limitata.
+Inoltre andando ad analizzare la porzione di sistema impattata dai cambiamenti si è visto come anche in questo caso il dato sia caratterizzato da una forte variabilità.
+
+Le *RQ3*, *RQ4* e *RQ5* (da @sec:rq3) sono andate a valutare nello specifico le differenze in termini di entropia, discussione e *time-to-fix* tra gli interventi di *issue fixing* generici e quelli specifici del \acl{ML}.
+Da queste analisi si evince che tra i due tipi di interventi ci sono sia similitudini che differenze.
+Nel caso dell'entropia e della complessità del processo di cambiamento del software non sono emerse differenze rilevanti.
+Questo ci porta a pensare che il processo di cambiamento non varia in base al tipo di intervento, ma sia costante.
+
+Nel caso del livello di discussione e del *time-to-fix* sono emerse delle differenze confermate anche dai test statistici effettuati.
+In entrambi i casi l'essere un *fix* legato al \acl{ML} ha spinto la metrica verso l'alto.
+Nel caso dei messaggi scambiati non solo si è riscontrato un numero medio di messaggi più elevato, ma si è visto anche che questi mediamente sono più lunghi.
+Questo dato potrebbe dipendere sia dal maggiore tempo richiesto per d'individuazione e correzione delle problematiche legate al \ac{ML}, sia da un maggiore interesse per queste problematiche rispetto alle altre.
+
+## Sviluppi futuri
+
+Nella *RQ2* sfortunatamente non è stato possibile svolgere un'analisi più approfondita per la carenza di dati.
+Un possibile sviluppo futuro potrebbe consistere nella realizzazione di un classificatore *multi-label* in grado di individuare la fase in cui il problema si è manifestato.
+In questo modo non solo sarebbe possibile conoscere la fase per ogni intervento di *fix*, ma anche definire delle nuove analisi.
+Per esempio si potrebbe andare a ricercare differenze in termini di entropia, discussione e *time-to-fix* in base alla fase in cui si è presentata la *issue*.
+
+Per quanto riguarda la valutazione dell'entropia si è scelto come intervallo temporale di riferimento il singolo commit.
+Utilizzando questa configurazione non si è riscontrata nessuna differenza degna di nota.
+Un possibile sviluppo futuro potrebbe consistere nell'andare a valutare l'entropia considerando dei riferimenti temporali più ampi e verificare in questo caso la presenza di differenze.
+