L'individuazione dei progetti da analizzare è avvenuta mediate l'ausilio dell'\ac{API} messa a disposizione da GitHub.
In particolare è stata eseguita una query per ottenere una lista di repository che fanno uso di librerie e framework di \ac{ML} come `TensorFlow`, `Pytorch` e `scikit-learn`.
In questo modo è stato possibile ottenere una lista di $26758$ repository che è stata successivamente filtrata per individuare solo i progetti d'interesse per la seguente analisi.
L'operazione di filtraggio è avvenuta attraverso due fasi; una prima automatica e una seconda manuale.
La prima fase ha avuto l'obiettivo di selezionare unicamente i repository *popolari*.
Nella maggior parte dei casi viene utilizzato il numero di stelle come indice della popolarità di un progetto [@borges2016understandingfactorsthat], ma per questo lavoro si è preferito dare maggiore rilevanza al numero di fork, al numero di *contributors* e al numero di issues chiuse.
Questa scelta è stata dettata dall'esigenza di selezionare non solo repository popolari, ma anche caratterizzati da una forte partecipazione della community.
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.
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.
Con il processo precedentemente illustrato è stato possibile recuperare:
- $34180$ commit.
- $15267$ tra issues e pull request.
## Classificazione dei dati
### 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.
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}.
- 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}.
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.
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...
: Confronto dei due modelli per la classificazione delle issues. {#tbl:confronto-modelli-classificazione-issues}
### 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 *"#"*.
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}.
