diff --git a/src/chapter_3.md b/src/chapter_3.md
index 886214d..f3fad1c 100644
--- a/src/chapter_3.md
+++ b/src/chapter_3.md
@@ -1,4 +1,4 @@
-# Metodologia {#sec:methodology}
+# Costruzione del dataset e metodologia {#sec:methodology}
 
 ## Research Questions
 
@@ -135,3 +135,59 @@ La classificazione è avvenuta attraverso la lista delle issues citate all'inter
 
 ![Risultato della classificazione dei commit](figures/count-commit.pdf){#fig:count-commit width=80%}
 
+## Metodologia
+
+### 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}.
+A tal fine i commit sono stati raggruppati rispetto al progetto e al tipo di cambiamento (\ac{ML}, no \ac{ML}) e per ogni istanza di questo raggruppamento si è eseguito l'union set dei files modificati.
+Come output di questa fase si è generato per ogni progetto:
+
+- l'insieme dei file modificati per *fix* di \ac{ML}
+- l'insieme dei file modificati per fix generici
+
+Infine eseguendo l'union set tra questi due insiemi si è ottenere l'insieme totale dei files modificati durante i *fix*.
+In questo modo è stato possibile andare a valutare la percentuale di files modificati in relazione al tipo di cambiamento.
+Attraverso la funzione di libreria Python `os.path.dirname` sono stati ottenuti i tre insiemi sopra citati anche per quanto riguarda le directories.
+
+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 (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`.
+
+### 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.
+Come detto precedentemente, nel caso delle *issues* classificate a mano, oltre all'individuazione della tipologia (\ac{ML}, non \ac{ML}) è stata individuata anche la fase in cui il problema si palesava (si veda @sec:classificazione-issues).
+Questo dato aggiuntivo presente su alcune issues è stato *proiettato* anche sulla classificazione dei commit di *fix* per andare a valutare come questi sono distribuiti sulle varie fasi.
+
+### 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.
+
+Inoltre per poter valutare l'entità del 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.
+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}
+
+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.
+
+A questo punto si è cercato di capire se al maggior numero di commenti è associata effettivamente una maggiore quantità di informazioni scambiate.
+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}
+
+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.
+