General fixes

src/chapter_1.md

@@ -1,7 +1,7 @@
 # Introduzione
 
-La storia dell'industria dello sviluppo software è caratterizzata da diversi cambiamenti rispetto alle applicazioni dominati.
-Negli anni ottanta il dominio dominante era quello dei personal computer, puoi abbiamo avuto Internet a cui è seguita la nascita del Web al \ac{CERN}.
+La storia dell'industria dello sviluppo software è caratterizzata da diversi cambiamenti rispetto alle applicazioni dominanti.
+Negli anni ottanta il paradigma dominante era quello dei personal computer, poi abbiamo avuto Internet a cui è seguita la nascita del Web al \ac{CERN}.
 Nel 2007 con l'annuncio del primo iPhone è inizia l'era del *mobile computing* a cui è seguita quella del *cloud computing*.
 Negli ultimi anni l'industria non è stata a guardare, ma ha dato vita a sempre più prodotti che fanno uso di \ac{AI} e \ac{ML}.
 Gli strumenti e i software che fanno uso di queste tecnologie sono ormai parte della nostra vita quotidiana e pervadono i campi più disparati.
@@ -9,8 +9,7 @@ Tra questi sicuramente possiamo annoverare: riconoscimento di immagini, diagnosi
 
 La crescente produzione di software basato sul \acl{ML} ha generato un forte impulso anche per quanto riguarda la ricerca.
 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.
-In letteratura non mancano studi atti ad evidenziare le differenze tra progetti di \ac{ML} e progetti classici [@gonzalez2020statemluniverse10].
-Ne tanto meno confronti dei progetti rispetto alle dipendenze e alle librerie utilizzate [@han2020empiricalstudydependency].
+In letteratura non mancano studi atti ad evidenziare le differenze tra progetti di \ac{ML} e progetti classici [@gonzalez2020statemluniverse10], né tanto meno confronti dei progetti rispetto alle dipendenze e alle librerie utilizzate [@han2020empiricalstudydependency].
 
 Molti studi sono, invece, incentrati sulle problematiche legate allo sviluppo di applicazioni di \acl{ML}.
 In alcuni casi l'analisi è stata svolta per librerie specifiche, in altri casi il focus è stato puntato sulle discussioni di \ac{SO}.
@@ -19,7 +18,7 @@ In altri casi ancora l'attenzione è stata rivolta su problematiche specifiche c
 Anche il seguente lavoro si concentra sui difetti riscontrati all'interno delle applicazioni di \acl{ML}.
 In questo caso però la ricerca di differenze è legata agli interventi di *issue fixing* relativi al \ac{ML} rispetto ad interventi di correzione generici.
 
-## Obbiettivi della tesi {#sec:goals}
+## Obiettivi 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.

src/chapter_2.md

@@ -21,14 +21,14 @@ Per poter svolgere questa analisi i contributori sono stati divisi in:
 - *esterni*: i loro contributi sono limitati ad aprire *issues* e commentare le discussioni.
 - *interni*: oltre a svolgere i compiti precedentemente elencati devono anche aver chiuso delle issues o eseguito dei commit sul progetto.
 
-In base a questa divisione si è visto come il tools di \acl{ML} hanno un numero di contributori interni superiore rispetto ai progetti generici.
-Quest'ultimi pero hanno una maggiore partecipazione esterna.
+In base a questa divisione si è visto come i tools di \acl{ML} hanno un numero di contributori interni superiore rispetto ai progetti generici.
+Quest'ultimi però hanno una maggiore partecipazione esterna.
 Se invece l'analisi viene svolta considerando unicamente gli autori dei commit si scopre che i progetti generici mediamente hanno più *contributors*, ma i top 4 repositories con più committer sono tutti legati al mondo del \ac{ML}.
 
 Un'ulteriore analisi è stata svolta anche per quanto riguarda il linguaggio con cui sono stati realizzati i vari progetti.
 Sia nel caso delle applicazioni che nei tools di \acl{ML} il linguaggio più popolare è Python, mentre la seconda posizione varia.
-Nel caso del tools questa è occupata da C++, mentre nelle applicazioni dai Notebook Jupyter.
-Nei progetti generici invece Python occupa solo la terza posizione in quanto popolarità e le prime due sono occupate da JavaScript e Java.
+Nel caso dei tools questa è occupata da C++, mentre nelle applicazioni dai Notebook Jupyter.
+Nei progetti generici invece Python occupa solo la terza posizione in quanto a popolarità e le prime due sono occupate da JavaScript e Java.
 
 ## Analisi in base al framework utilizzato
 
@@ -52,14 +52,14 @@ La classifica delle librerie più utilizzate è rimasta sostanzialmente invariat
 L'unica eccezione riguarda i progetti realizzati a fini di ricerca.
 In questo caso `TensorFlow` e `PyTorch` sono in posizioni invertite.
 Anche per quanto riguarda la classificazione rispetto al dominio applicativo la situazione è costante.
-Infatti, indipendentemente dalla libreria utilizzata, il progetti più frequenti sono quelli che hanno a che fare con video e immagini e con il \ac{NLP}.
+Infatti, indipendentemente dalla libreria utilizzata, i progetti più frequenti sono quelli che hanno a che fare con video e immagini e con il \ac{NLP}.
 
 Un'ulteriore \ac{RQ} è andata a valutare il tipo di dipendenza, facendo distinzione tra dipendenze dirette e indirette.
 Per tutte è tre le librerie si è visto che è più probabile avere una dipendenza diretta che indiretta.
 `PyTorch` è la libreria che più frequentemente è importata direttamente, mentre `Theano` ha una probabilità di essere importata direttamente quasi uguale a quella di essere importata indirettamente.
 
-Un ulteriore analisi è stata condotta per individuare quanto frequentemente i progetti aggiornano le loro dipendenze o eseguono dei downgrade.
-In questo caso si è visto che il progetti basati su `TensorFlow` e `PyTorch` aggiornano le proprie dipendenze molto più frequentemente rispetto ai progetti basati su `Theano`.
+Un'ulteriore analisi è stata condotta per individuare quanto frequentemente i progetti aggiornano le loro dipendenze o eseguono dei downgrade.
+In questo caso si è visto che i progetti basati su `TensorFlow` e `PyTorch` aggiornano le proprie dipendenze molto più frequentemente rispetto ai progetti basati su `Theano`.
 Mentre il tasso di downgrade è sostanzialmente equivalente.
 Nel caso dei progetti che dipendono da `TensorFlow` la maggior parte dei downgrade viene spiegata dalla volontà di non utilizzare la nuova \ac{API} introdotta nella versione 2.0 della libreria.
 Sempre analizzando la versione della libreria utilizzata si è visto che i progetti basati su `Theano` sono quelli che utilizzano più frequentemente l'ultima versione disponibile della libreria.
@@ -72,9 +72,9 @@ In particolare emerge che le fasi più discusse sono quelle di *model training*
 Mentre la fase meno discussa è quella di *model tuning*.
 Per quanto riguarda le differenze, dallo studio, emerge che `TensorFlow` e `PyTorch` hanno topic di discussione totalmente confrontabili.
 Oltre ai topic citati precedentemente, per questi framework, si discute molto anche della *data preparation*.
-Mentre la discussioni riguardanti `Theano` sono quasi esclusivamente concentrate sul *model training*.
+Mentre le discussioni riguardanti `Theano` sono quasi esclusivamente concentrate sul *model training*.
 
-Da questi due studi è possibile evince sicuramente una forte somiglianza per quanto riguarda `TensorFlow` e `PyThorch`.
+Da questi due studi si evince una forte somiglianza per quanto riguarda `TensorFlow` e `PyThorch`.
 La principale differenza viene riscontrata per quanto riguarda i campi di applicazione, con `TensorFlow` che viene generalmente preferito fatti salvi gli ambiti di ricerca.
 Mentre `Theano` presenta molte diversità sia per quanto riguarda gli impieghi che le discussioni.
 
@@ -82,7 +82,7 @@ Mentre `Theano` presenta molte diversità sia per quanto riguarda gli impieghi c
 
 Lo studio di Grichi *et al.* [@grichi2020impactmultilanguagedevelopment] si concentra sui sistemi *multi-linguaggio*.
 In questo caso si vuole capire se i sistemi di \ac{ML} sono più soggetti all'essere realizzati attraverso linguaggi diversi.
-Inoltre analizzando le pull request realizzate in più linguaggi si vuole capire se queste sono accettate con la stessa frequenza di quelle *mono-linguaggio* e se la presenza di difetti è equivalente.
+Inoltre analizzando le \ac{PR} realizzate in più linguaggi si vuole capire se queste sono accettate con la stessa frequenza di quelle *mono-linguaggio* e se la presenza di difetti è equivalente.
 
 L'analisi è stata svolta su 27 progetti open source hostati su GitHub.
 I progetti sono poi stati classificati in tre categorie:
@@ -92,7 +92,7 @@ I progetti sono poi stati classificati in tre categorie:
 - Cat III: include 7 sistemi di \acl{ML} *mono-linguaggio*.
 
 Successivamente sono state scaricate le \ac{PR} di ogni progetto considerato.
-Le \ac{PR}s sono state categorizzate per individuare le quelle accettate e quelle rifiutate.
+Le \ac{PR}s sono state categorizzate per individuare quelle accettate e quelle rifiutate.
 Inoltre le \acl{PR} sono state categorizzate anche il base al numero di linguaggi utilizzati.
 In questo modo è stato possibile individuare le \ac{PR} *mono-linguaggio* e quelle *multi-linguaggio*.
 Infine per ogni \ac{PR} è stato individuato il tempo necessario alla sua accettazione o chiusura e i difetti introdotti dalla \acl{PR}.
@@ -115,10 +115,10 @@ Nello studio di Zhang *et al.* [@zhang2018empiricalstudytensorflow] l'attenzione
 Per lo studio sono stati recuperati dei *bug* di `TensorFlow` sia da progetti su GitHub (88 elementi) sia da quesiti su \acl{SO} (87 elementi).
 
 Gli autori dello studio, per poter individuare la causa dei *bug* e i loro sintomi hanno dovuto analizzare manualmente gli elementi del dataset.
-Nel caso di *bug* discussi su \ac{SO} le informazioni sono state recupera della discussione.
+Nel caso di *bug* discussi su \ac{SO} le informazioni sono state recuperate dalla discussione.
 Mentre nel caso dei *bug* recuperati da GitHub le informazioni sono state recuperate tramite lo studio dell'intervento di *fix* e il messaggio associato ad esso.
 
-In questo modo è stato possibile individuare quattro sintomi:
+In questo modo è stato possibile individuare tre sintomi:
 
 - *Error*: durante l'esecuzione viene sollevato un errore riconducibile a `TensorFlow`.
 - *Low Effectiveness*: il programma presenta dei valori di *accuracy*, *loss* ecc. estremamente scadenti.
@@ -138,7 +138,7 @@ Anche lo studio di Humbatova *et al.* [@humbatova-2019-taxonomyrealfaults] ha co
 In questo caso però la visione è più ampia e non si limita ad una singola libreria.
 Inoltre in questo caso lo scopo ultimo del lavoro è la costruzione di una tassonomia per le problematiche di \ac{ML}.
 
-Anche in questo caso il dati sono stati recuperati sia da \acl{SO} che da GitHub.
+Anche in questo caso i dati sono stati recuperati sia da \acl{SO} che da GitHub.
 Inoltre per questo studio è stata anche svolta un'intervista a 20 persone tra ricercatori e sviluppatori nel campo del \acl{ML}.
 Partendo da questi dati è stata costruita una tassonomia attraverso un approccio *bottom-up*.
 La tassonomia si compone di 5 categorie *top-level*, 3 delle quali sono state divise in sotto categorie.
@@ -156,7 +156,7 @@ Come si può notare, fatta salva la specificità del primo lavoro, esiste una fo
 
 ## Analisi delle discussioni di Stack Overflow riguardanti il ML
 
-Nello studio di Bangash *et al.* [@bangash2019whatdevelopersknow] viene svolta un analisi degli argomenti di \acl{ML} discussi più frequentemente dagli sviluppatori.
+Nello studio di Bangash *et al.* [@bangash2019whatdevelopersknow] viene svolta un'analisi degli argomenti di \acl{ML} discussi più frequentemente dagli sviluppatori.
 In questo caso, a differenza dello studio di Han *et al.* [@han2020whatprogrammersdiscuss] discusso precedentemente, non viene svolta alcuna distinzione in base alla libreria utilizzata.
 Inoltre questo studio utilizza unicamente informazioni recuperate da \acl{SO}, mentre l'altro lavoro univa le domande di \ac{SO} alla discussione generata all'interno dei repositories di GitHub.
 
@@ -168,7 +168,7 @@ Tutte queste discussioni sono state inserite nel topic *framework*.
 Anche nel lavoro di Alshangiti *et al.* [@alshangiti2019whydevelopingmachine] vengono analizzate le domande presenti sulla piattaforma \acl{SO}.
 In questo caso però oltre ad un analisi qualitativa rispetto al contenuto di queste discussioni è stata eseguita anche un'analisi comparativa tra le discussioni inerenti al \acl{ML} e le altre.
 
-Per svolgere questa analisi gli autori sono partiti dal dump del database di \ac{SO} e hai individuato tre campioni:
+Per svolgere questa analisi gli autori sono partiti dal dump del database di \ac{SO} e hanno individuato tre campioni:
 
 - *Quantitative Study Sample*: si compone di 86983 domande inerenti al \ac{ML}, con le relative risposte.
   L'individuazione dei post è avvenuta attraverso la definizione di una lista contente 50 tag utilizzate su \ac{SO} per le domande di \acl{ML}.
@@ -179,7 +179,7 @@ Per svolgere questa analisi gli autori sono partiti dal dump del database di \ac
 
 La prima *\ac{RQ}* dello studio vuole verificare se rispondere ad una domanda inerente al \acl{ML} sia più complicato.
 Per valutare la complessità di risposta sono state contate le domande che non presentano alcuna risposta, le domande che non presentano risposte accettate e la mediana del tempo necessario affinché una domanda abbia una risposta accettata.
-Dal confronta tra il primo e il terzo sample rispetto a queste metriche è emerso che i post inerenti al \ac{ML} hanno una maggiore probabilità di non avere risposte/risposte accettate.
+Dal confronto tra il primo e il terzo sample rispetto a queste metriche è emerso che i post inerenti al \ac{ML} hanno una maggiore probabilità di non avere risposte/risposte accettate.
 Inoltre si è visto come mediamente le domande di \acl{ML} necessitano di un tempo dieci volte maggiore per poter avere una risposta accettata.
 Una spiegazione a questo fenomeno ci viene fornita dalla seconda *\ac{RQ}* in cui viene evidenziato che all'interno della community di \acl{SO} c'è una carenza di esperti di \acl{ML} [^expertise-rank].
 
@@ -190,7 +190,7 @@ Se l'utente C risponde ad una domanda di B, allora questo avrà una esperienza s
 
 Lo studio è stato in grado anche di individuare le fasi in cui gli sviluppatori riscontrano maggiori problematiche.
 In generale le maggiori difficoltà sono state riscontrate nel *preprocessing dei dati*, nella configurazione dell'ambiente di sviluppo e nel deployment del modello.
-Per quanto riguarda i task specifici del \acl{DL} le maggiori problematiche riguarda applicazioni di \ac{NLP} e riconoscimento degli oggetti.
+Per quanto riguarda i task specifici del \acl{DL} le maggiori problematiche riguardano applicazioni di \ac{NLP} e riconoscimento degli oggetti.
 Infine lo studio ha mostrato come, nonostante la vasta adozione, molti utenti riscontrano problemi nell'utilizzo dell'\ac{API} di `TensorFlow`.
 
 ## Entropia di un cambiamento {#sec:entropy}

src/chapter_3.md

@@ -7,8 +7,8 @@ Gli obiettivi di questa tesi illustrati nella @sec:goals sono stati racchiusi in
 - **RQ1**: *come il \ac{ML} e' distribuito sull'architettura dei progetti?*
 
   In questa *\ac{RQ}* si vuole investigare l'architettura dei progetti.
-  In particolare l'attenzione viene concentratala sui files e sulle directories modificate durante interventi di *issues fixing*.
-  Obbiettivo di questa domanda è anche individuare la percentuale di files che utilizzano import riconducibili a librerie e framework di \acl{ML}.
+  In particolare l'attenzione viene concentrata sui files e sulle directories modificate durante interventi di *issues fixing*.
+  Obiettivo di questa domanda è anche individuare la percentuale di files che utilizzano import riconducibili a librerie e framework di \acl{ML}.
 - **RQ2**: *come sono distribuiti i bug sulle diverse fasi di \ac{ML}?* 
 
   Il workflow tipico per lo sviluppo di un'applicazione di \acl{ML} si compone di più fasi.
@@ -51,7 +51,7 @@ Alla fine di questa seconda fase il numero di progetti è sceso a trenta.
 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].
 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.
+Poiché le chiamate associate ad un singolo *token* sono limitate nel tempo si è scelto di configurare *perseval* in modo tale da introdurre in automatico un 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.
 
 Con il processo precedentemente illustrato è stato possibile recuperare:
@@ -73,15 +73,15 @@ I due modelli considerati sono:
 - un classificatore statico basato su una lista di vocaboli tipici del \ac{ML}.
 - 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}.
-Lista dei termini caratteristici del \acl{ML} non è stata costruita da zero, ma è basata sul lavoro di Humbatova *et al.* [@humbatova-2019-taxonomyrealfaults].
+La classificazione mediante il classificatore statico non necessita di un *labeling* manuale dei dati, ma richiede la definizione dei vocaboli tipici del \ac{ML}.
+La lista dei termini caratteristici del \acl{ML} non è stata costruita da zero, ma è basata sul lavoro di Humbatova *et al.* [@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.
 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 dal lavoro di Amershi *et al.* [@amershi-2019-softwareengineeringmachine] realizzato nei laboratori di *Microsoft*.
+La label delle *issues* è stata determinata andando ad 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 definizione delle varie fasi è avvenuta partendo dal lavoro di Amershi *et al.* [@amershi-2019-softwareengineeringmachine] realizzato nei laboratori di *Microsoft*.
 
 Le fasi considerate sono:
 
@@ -94,7 +94,7 @@ Le fasi considerate sono:
 - *Model Training*: questa fase racchiude il training vero e proprio del modello.
 - *Model Evaluation*: in questa fase vengono valutate le performance del modello utilizzando metriche standard come *precision* e *recall*, ma anche andando a confrontare i risultati ottenuti rispetto a quelli generati da altri modelli o rispetto all'esperienza[^esperienza].
 - *Model Deployment*: questa fase riguarda il dispiegamento del modello sul dispositivo target.
-- *Model Monitoring*: una volta dispiegato il modello deve essere continuamente monitora al fini di assicurasi un corretto comportamento anche sui dati reali.
+- *Model Monitoring*: una volta dispiegato il modello deve essere continuamente monitorato al fine di assicurasi un corretto comportamento anche sui dati reali.
 
 [^esperienza]: Non sempre è possibile valutare un modello in modo oggettivo, ci sono determinati contesti, come ad esempio la generazione di *deep fakes*, in cui è comunque necessaria una valutazione umana per determinare la qualità del risultato.
 
@@ -164,7 +164,7 @@ Come output di questa fase si è ottenuto 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*.
+Infine eseguendo l'union set tra questi due insiemi si è ottenuto l'insieme totale dei files modificati durante i *fix*.
 A questo punto per ogni progetto si è calcolata la percentuale di file modificati durante interventi di *fix* di \ac{ML} (`ml_file_ratio`) e la percentuale di file modificati durante *fix* generici (`no_ml_file_ratio`).
 
 Attraverso la funzione di libreria Python `os.path.dirname` sono stati ottenuti i tre insiemi sopra citati anche per quanto riguarda le directories.
@@ -183,7 +183,7 @@ Nel caso della severità *base* per rientrare all'interno dei file che fanno uso
 Mentre nel caso di severità *strict* era necessario importare almeno una libreria presente nel primo gruppo.
 
 Per entrambe le classificazioni si è andato a valutare a quanto ammontava la percentuale di file di \ac{ML} appartenenti ad ogni progetto.
-Anche i questo caso le distribuzioni sono state analizzate attraverso l'ausilio di un boxplot.
+Anche in questo caso le distribuzioni sono state analizzate attraverso l'ausilio di un boxplot.
 
 ### RQ2: come sono distribuiti i bug sulle diverse fasi di ML?
 

src/chapter_4.md

@@ -15,7 +15,7 @@ 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=80%}
 
 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.
+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 immagini.
 L'unica eccezione è data dal progetto *jdb78/pytorch-forecasting* che si occupa del *forecasting* di serie temporali.
 
 | Progetto                    | Dominio Applicativo       |
@@ -37,7 +37,7 @@ Questo vuol dire che i progetti considerati nello studio sono di varia natura.
 
 ## 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*.
+Andando a confrontare la distribuzione delle 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.
@@ -84,7 +84,7 @@ Osservando invece il boxplot[^boxplot-discussion] in @fig:discussion-comments si
 In particolare è possibile notare che le *issue fix* di \ac{ML} presentano una maggiore discussione e anche una maggiore varianza.
 Se consideriamo la differenza interquartile, in modo da escludere completamente eventuali outlier, possiamo osservare che nei *fix* generici questa varia tra zero e uno.
 Ciò vuol dire che il $50\%$ interno delle issues o non presenta commenti o ne presenta uno solo.
-Mentre la differenza interquartile dei *fix* di \acl{ML} è compreso tra uno e cinque quindi nel $50\%$ interno tutte le issues hanno almeno un commento di risposta.
+Mentre la differenza interquartile dei *fix* di \acl{ML} è compreso tra uno e cinque, quindi nel $50\%$ interno tutte le issues hanno almeno un commento di risposta.
 
 [^boxplot-discussion]: In questo caso il limite superiore è pari al $97$-$esimo$ quantile.
 
@@ -129,8 +129,8 @@ 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*).
+Ne sono un esempio la issue tratta precedentemente nel caso dei commenti, ma anche la issue 125 sempre del progetto *BrikerMan/Kashgari*.
+Altri 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*).
 
 \begin{tcolorbox}[colback=white, boxrule=0.3mm]
 Le \emph{issues} di \acl{ML} sono caratterizzata da una maggiore discussione.
@@ -154,13 +154,13 @@ Il maggior tempo necessario ad attuare la correzione indica che i *bug* di \ac{M
 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.
+Nel caso del progetto *CamDavidsonPilon/lifelines* la *issue* numero 507 segnala una problematica di *overflow* durante le 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.
+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 *issue* 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.