diff --git a/src/chapter_4.md b/src/chapter_4.md
index 13b9b68..66656e5 100644
--- a/src/chapter_4.md
+++ b/src/chapter_4.md
@@ -14,12 +14,28 @@ Inoltre, considerando l'analisi *strict*, è possibile osservare come solo un $2
 
 ![Percentuale di file che utilizzano librerie di ML](figures/imports.pdf){#fig:imports width=70%}
 
+In relazione all'analisi *strict* sono stati poi analizzati i cinque progetti più \acl{ML} *intensive* per valutare eventuali caratteristiche comuni rispetto al dominio applicativo.
+Com'è possibile notare dalla @tbl:ml-intensive i vari progetti si occupano di problematiche diverse, ma in quasi tutti i casi è prevista l'estrapolazione di informazioni da delle immagini.
+L'unica eccezione è data dal progetto *jdb78/pytorch-forecasting* che si occupa del *forecasting* di serie temporali.
+
+| Progetto                    | Dominio Applicativo       |
+|-----------------------------|---------------------------|
+| *davidsandberg/facenet*     | Riconoscimento facciale   |
+| *jdb78/pytorch-forecasting* | Time series forecasting   |
+| *tianzhi0549/FCOS*          | Riconoscimento di oggetti |
+| *emedvedev/attention-ocr*   | Riconoscimento del testo  |
+| *Tianxiaomo/pytorch-YOLOv4* | Riconoscimento di oggetti |
+
+: Dominio applicativo dei progetti con maggior uso di librerie di \ac{ML} {#tbl:ml-intensive}
+
 ## RQ2: come sono distribuiti i bug sulle diverse fasi di ML? {#sec:rq2}
 
 Andando a confrontare la distribuzioni della fasi sui commit (@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.
 
+\newpage
+
 ![Istanze dei fix in base alla fase](figures/count-fix-phases.pdf){#fig:count-fix-phases width=70%}
 
 ## RQ3: esiste una differenza di entropy tra ML bug e altri bug? {#sec:rq3}
@@ -43,7 +59,7 @@ Una situazione analoga si riscontra anche nell'analisi sulle linee (@fig:lines-e
 
 Per verificare la rilevanza statistica di questa diversità sono stati svolti il *ranksum* test e il *Cliff's delta* i cui risultati sono riportati nella @tbl:test-entropy.
 Nel caso dell'entropia sui file possiamo dire che la differenza è marginale poiché il *p-value* è prossimo a $0.05$, mentre nel caso dell'entropia calcolato sulle linee la differenza viene confermata dal test.
-In entrambi i casi, però, l'*effect size* è trascurabile.
+In entrambi i casi, però, l'*effect size* è trascurabile segno che la complessità dell'intervento non varia in base al tipo di intervento.
 
 |              | ranksum p-values | Cliff's delta |
 |--------------|:----------------:|:-------------:|
@@ -52,8 +68,6 @@ In entrambi i casi, però, l'*effect size* è trascurabile.
 
 : Risultati dei test statistici per quanto riguarda l'entropia {#tbl:test-entropy}
 
-\newpage 
-
 ## RQ4: come varia il livello di discussione tra ML bug e altri bug? {#sec:rq4}
 
 Osservando invece il boxplot[^boxplot-discussion] in @fig:discussion-comments si evince una differenza molto più marcata tra le due distribuzioni.
@@ -76,7 +90,7 @@ Mentre la differenza interquartile dei *fix* di \acl{ML} è compreso tra uno e c
   \label{fig:discussion}
 \end{figure}
 
-I risultati di dell'analisi rispetto alle parole medie contenute in un commento sono riportati in @fig:discussion-words.
+I risultati dell'analisi rispetto alle parole medie contenute in un commento sono riportati in @fig:discussion-words.
 Anche in questo caso si può vedere che nel caso di \ac{ML} *fix* la distribuzione presenta valori più elevati e maggiore varianza.
 Per cui non solo nei *fix* di \acl{ML} c'è maggiore discussione, ma la discussione è anche più *densa*.
 
@@ -91,6 +105,21 @@ Inoltre, per entrambe le metriche, abbiamo un *effect size* medio.
 
 : Risultati dei test statistici per quanto riguarda il livello di discussione {#tbl:test-discussion}
 
+Infine, per entrambe le metriche, sono stati analizzati alcuni casi estremi.
+Nel caso della issue numero 96 del progetto *BrikerMan/Kashgari* la problematica riguarda un drastico calo di performance quando il fit viene eseguito con un metodo piuttosto che con un altro.
+All'interno dei commenti, diversi *contributors* del progetto, si scambiano possibili architetture, *snippet* di codice e metriche per confrontare i diversi modelli generati.
+In questo caso l'ampiezza della discussione è sicuramente dovuta alla difficoltà di individuare la problematica.
+
+La issue numero 27 del progetto *pyswarms/issues* è una richiesta di aiuto da parte dell'autore per migliorare l'implementazione della ricerca per il tuning degli hyperparametri.
+In questo caso la discussione si protrae per oltre trenta commenti ed è incentrata sui requisiti dell'implementazione e come implementarla nel rispetto delle linee guida del progetto.
+Quest'intervento di modifica è stato il primo contributo dell'utente non solo su questo progetto, ma sull'intera community di GitHub.
+Questa inesperienza può aver contribuito ad ampliare la discussione.
+
+La stessa analisi è stata svolta anche per le issues che presentano un alto numero di parole medie per commento.
+In questo caso un valore molto elevato della metrica è spesso riconducibile alla condivisione di blocchi di codice.
+Nel sono un esempio la issue tratta precedentemente nel caso dei commenti, ma anche la issue 125 sempre del progetto *BrikerMan/Kashgari*.
+Altre fattori che contribuiscono a spiegare questo dato sono la presenza di blocchi di errori (*mittagessen/kraken/206*) o messaggi di log utili ad inquadrare l'origine del problema (*robertmartin8/PyPortfolioOpt/177*).
+
 ## RQ5: come varia il time-to-fix tra ML bug e altri bug? {#sec:rq5}
 
 Anche in questo caso, osservando la @fig:day-to-fix, è possibile notare una netta differenza tra i *fix* di \ac{ML} e gli altri.
@@ -102,13 +131,23 @@ 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.
+Mentre nel caso dei *fix* di \acl{ML} per essere considerato outlier una *issue*, necessaria di un *time-to-fix* superiore ai trentacinque giorni.
 
 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.
 
+Per quanto riguarda i *fix* che hanno richiesto un tempo estremamente lungo la causa può dipendere anche da ulteriori fattori.
+Nel caso del progetto *CamDavidsonPilon/lifelines* la *issue* numero 507 segnala una problematica di *overflow* durante delle operazioni sul dataset.
+Per stessa ammissione dell'autore del progetto la problematica è banale da risolvere, ma è stato comunque necessario attendere un paio di mesi affinché la correzione venisse portata sul branch principale.
+
+Altre issues invece hanno necessitato di molto tempo per essere risolte in quanto venivano considerate a bassa priorità.
+In questi casi generalmente viene fornito un *work around* che permette di tamponare la problematica.
+La presenza di questo *work around* probabilmente riduce ulteriormente la priorità data alla *issue* il che dilata ulteriormente i tempi.
+Un esempio di questo comportamento ci viene dato dalla *issue* 135 del progetto *robertmartin8/PyPortfolioOpt* che ha richiesto circa sette mesi per essere risolta o dalla *issues* 98 del progetto *mittagessen/kraken* che invece ha necessitato di quasi due anni.
+
 Anche per quest'ultima *RQ* sono stati svolti i test statistici illustrati precedentemente.
 Dai risultati riportati in @tbl:test-time-to-fix è possibile notare un *p-value* inferiore a $0.05$ e un *effect size* medio.
+Questi risultati non solo confermano la differenza osservata nel boxplot, ma ci confermano che l'impatto sulla metrica non è trascurabile.
 
 |            | ranksum p-values | Cliff's delta |
 |------------|:----------------:|:-------------:|