Refactoring

src/chapter_2.md

@@ -18,16 +18,16 @@ I progetti che hanno superato questa prima selezione dovevano:
 - avere dieci contributors.
 - avere almeno venticinque fork.
 
-Alla fine di questa prima selezione sono rimasti solo sessantasei repository che sono stati analizzati manualmente per rimuovere listati associati a libri e/o tutorial, progetti non in lingua inglese e librerie.
-Alla fine di questa seconda fase solo rimasti trenta progetti.
+Alla fine di questa prima selezione il numero di repository si è ridotto a sessantasei che sono stati analizzati manualmente per rimuovere listati associati a libri e/o tutorial, progetti non in lingua inglese e librerie.
+Alla fine di questa seconda fase il numero di progetti è sceso a trenta.
 
 ## Fetch di issues e commit
 
 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.
-Inoltre il codice è stato dispiegato su un \ac{VPS} in modo da rendere *frictionless* il processo di fetch.
+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.
+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:
 
@@ -38,25 +38,42 @@ Con il processo precedentemente illustrato è stato possibile recuperare:
 
 ### Classificazione delle issues
 
-Al fine di poter eseguire un confronto tra i *bugfix* di \ac{ML} e quelli *generici* è stato necessario classificare sia le issues che i commit.
+Al fine di poter eseguire un confronto tra i *fix* di \ac{ML} e quelli *generici* è stato necessario classificare sia le issues che i commit.
 Per quanto riguarda i primi si è scelto di attuare una classificazione basata sul testo, in particolare considerando il titolo e il corpo della issue, ma escludendo i commenti di risposta in modo da non rendere i dati troppo rumorosi.
-
 Il numero elevato di elementi non rende praticabile una classificazione manuale per cui si è optato per una classificazione automatica.
 A tal fine sono stati implementati ed analizzati due classificatori, uno supervisionato e uno non supervisionato.
-I due modelli analizzati sono basati su:
 
-- una classificazione tramite una lista di vocaboli tipici del \ac{ML}.
+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 prima classificazione non necessita di un *labeling* manuale dei dati, ma richiede la definizione dei vocaboli tipici del \ac{ML}.
+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].
 In questo modo tutte le issues che utilizzavano almeno un vocabolo tipico del Machine Learning 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 $377$ issues che sono state divise tra due lettori e labellate.
-A partire da questo dataset è stato definito un training set attraverso il quale si è allenato il modello bayesiano.
+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 da un lavoro di *Microsoft*[@amershi-2019-softwareengineeringmachine].
+
+Le fasi considerate sono:
+
+- *Model Requirements*
+- *Data Collection*
+- *Data Labeling*
+- *Data cleaning*[^data-cleaning]
+- *Feature Engineering*
+- *Model Training*
+- *Model Evaluation*
+- *Model Deployment*
+- *Model Monitoring*
+
+[^data-cleaning]: Nella fase di *Data Cleaning* non rientrano soltanto le operazioni strettamente di pulizia come ad esempio rimozione di record rumorosi o incompleti, ma tutte le trasformazioni eseguite sui dati, quindi anche operazioni di standardizzazione, flip di immagini ecc.
+
+A partire dal dataset *labellato* è stato possibile costruire un training e un test set, mediante i quali è stato possibile allenare e valutare le performance del modello bayesiano.
+Mentre le performance del primo modello sono state valutate sull'intero dataset.
 
-Le performance del primo modello sono state valutate attraverso il dataset di issues *labellate*, mentre per quanto il modello bayesiano la valutazione è avvenuta attraverso l'impiego del test set.
 Al fine di poter confrontare i due modelli sono state utilizzate le metriche di precision e recall.
 Com'è possibile notare dai valori riportati in @tbl:confronto-modelli-classificazione-issues, il modello...
 
@@ -69,10 +86,10 @@ Com'è possibile notare dai valori riportati in @tbl:confronto-modelli-classific
 
 ### Classificazione dei commit
 
-Prima di poter classificare i commit si è reso necessaria un'ulteriore fase di filtraggio in modo da poter separare i commit di *bug fixing* da quelli generici.
-Sono stati considerati come commit di *fix* tutti quei commit che, all'interno del messaggio, facevano riferimento a delle issues attraverso la notazione *"#"*.
+Prima di poter classificare i commit si è reso necessaria un'ulteriore fase di filtraggio in modo da poter separare i commit di *issue fixing* da quelli generici.
+Sono stati considerati come commit di *fix* tutti quei commit al cui interno veniva fatto riferimento a delle issues attraverso la notazione *"#"*.
 Questa operazione ha ridotto il dataset dei commit a $3321$ unità.
 
-A questo punto è stato possibile separare i *bugfix* di Machine Learning e quelli generici.
-La classificazione è stata ottenuta sfruttando 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}.
+A questo punto è stato possibile separare i *fix* di Machine Learning e quelli generici.
+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}.