makefile

@@ -12,6 +12,7 @@ thesis: src/* out ieee.csl
 draft: src/* ieee.csl
 	pandoc src/*.md src/metadata.yaml       \
   -o draft.pdf    												\
+	-M draft=true														\
   --template latekiss                     \
   --resource-path src                     \
   --top-level-division chapter            \

src/chapter_1.md

@@ -1,35 +1,35 @@
 # Introduzione
 
-Lo sviluppo del software è stato caratterizzato da diversi cambiamenti rispetto alle applicazioni dominanti.
+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.
 Tra questi sicuramente possiamo annoverare: riconoscimento di immagini, diagnosi di malattie, \ac{NLP}, guida autonoma e riconoscimento vocale.
 
-La crescente produzione di software basato sul \ac{ML} ha generato un forte impulso anche per quanto riguarda la ricerca.
+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], 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 \ac{ML}.
+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 [@zhang2018empiricalstudytensorflow], in altri casi il focus è stato puntato sulle discussioni di \ac{SO} [@hassan2009predictingfaultsusing; @shannon1948mathematicaltheorycommunication].
 In altri casi ancora l'attenzione è stata rivolta su problematiche specifiche come quella del \ac{SATD} [@liu2021exploratorystudyintroduction].
 
-Anche il seguente lavoro si concentra sui difetti riscontrati all'interno delle applicazioni di \ac{ML}.
+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.
 
 ## Obiettivi della tesi {#sec:goals}
 
-Questo studio vuole verificare la presenza di differenze, all'interno di progetti di \ac{ML}, rispetto a come sono trattate le *issue* legate a tematiche di \ac{ML} e quelle generiche.
-In particolare si vuole investigare come la risoluzione di queste problematiche va ad impattare sull'architettura, sia in termini di moduli modificati sia in termini di entropia generata.
+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.
 Si vuole anche scoprire se sono presenti delle fasi del processo di sviluppo che sono più critiche di altre.
-Infine si vuole comprendere se le *issue* sono trattate tutte allo stesso modo per quanto riguarda il livello di discussione e il tempo necessario alla loro risoluzione.
+Infine si vuole capire se le *issues* sono trattate tutte allo stesso modo per quanto riguarda il livello di discussione e il tempo necessario alla loro risoluzione.
 
 ## Struttura della tesi
 
-Nel capitolo [-@sec:related-works] viene svolta una panoramica sullo stato dell'arte.
-Nel capitolo [-@sec:methodology] vengono presentate le \ac{RQ}, viene descritta la procedura utilizzata per la raccolta dei commit e delle issue e come queste sono state classificate.
+Nella sezione [-@sec:related-works] viene svolta una panoramica sullo stato dell'arte.
+Nella sezione [-@sec:methodology] vengono presentate le \ac{RQ}, viene descritta la procedura utilizzata per la raccolta dei commit e delle issues e come queste sono state classificate.
 Inoltre viene illustrata la metodologia di analisi impiegata per lo studio di ogni *\ac{RQ}*.
-I risultati delle analisi e una discussione qualitativa su alcuni *casi estremi* sono riportati nel capitolo [-@sec:results].
-Infine il capitolo [-@sec:conclusions] chiude questa tesi.
+I risultati delle analisi e una discussione qualitativa su alcuni *casi estremi* sono riportati nella sezione [-@sec:results].
+Infine la sezione [-@sec:conclusions] chiude questa tesi.
 

src/chapter_2.md

@@ -1,14 +1,8 @@
 # Stato dell'arte {#sec:related-works}
 
-In questo capitolo verranno presentati diversi lavori di ricerca alla base di questo studio.
-I lavori, sebbene tutti incentrati sul \ac{ML}, vanno ad approfondire diversi aspetti.
-In alcuni casi l'attenzione principale è rivolta alle difficoltà e alle problematiche riscontrate dagli sviluppatori.
-In altri casi viene svolto un confronto tra progetti di \ac{ML} e progetti generici o tra progetti che fanno uso di diversi framework di \ac{ML}.
-Infine viene anche presentato un lavoro sulla complessità del processo di cambiamento del software e su i suoi effetti sull'introduzione di difetti.
+## Confronto tra progetti di ML e progetti generici
 
-\section[Confronto tra progetti di ML e progetti generici]{Confronto tra progetti di machine learning e progetti generici}
-
-Nello studio di Gonzalez *et al.* [@gonzalez2020statemluniverse10] vengono presentate le principali differenze tra i repository di \ac{ML} e i progetti classici.
+Nello studio di Gonzalez *et al.* [@gonzalez2020statemluniverse10] ci vengono presentate le principali differenze tra i repository di \acl{ML} e i progetti classici.
 I dati per lo studio sono stati recuperati attraverso l'\ac{API} messa a disposizione di GitHub attraverso la quale è stato possible collezionare i dati associati a 9325 progetti open source così raggruppati:
 
 - 5224 progetti legati all'\ac{AI} e al \ac{ML} divisi a loro volta in:
@@ -17,22 +11,22 @@ I dati per lo studio sono stati recuperati attraverso l'\ac{API} messa a disposi
 - 4101 progetti generici
 
 Gli aspetti considerati dallo studio sono molteplici e di varia natura.
-Una prima analisi è stata condotta rispetto alla nascita dei vari repository.
-In questo modo è stato possibile individuare nel 2017 l'anno della forte crescita dei repository di \ac{AI} & \ac{ML}.
-Infatti questo è stato il primo anno in cui sono stati creati più progetti legati al \ac{ML} rispetto a quelli generici.
+Una prima analisi è stata condotta rispetto alla nascita dei vari repositories.
+In questo modo è stato possibile individuare nel 2017 l'anno del *boom* dei repositori di \ac{AI} & \ac{ML}.
+Infatti questo è stato il primo anno in cui sono stati creati più progetti legati al \acl{ML} rispetto a quelli generici.
 
-Una seconda analisi ha permesso di comprendere come varia la partecipazione ai vari progetti.
+Una seconda analisi ha permesso di capire come varia la partecipazione ai vari progetti.
 Per poter svolgere questa analisi i contributori sono stati divisi in:
 
-- *esterni*: i loro contributi sono limitati ad aprire *issue* e commentare le discussioni.
-- *interni*: oltre a svolgere i compiti precedentemente elencati devono anche aver chiuso delle issue o eseguito dei commit sul progetto.
+- *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 i tools di \ac{ML} hanno un numero di contributori interni superiore rispetto ai progetti generici.
+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 repository con più committer sono tutti legati al mondo del \ac{ML}.
+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 \ac{ML} il linguaggio più popolare è Python, mentre la seconda posizione varia.
+Sia nel caso delle applicazioni che nei tools di \acl{ML} il linguaggio più popolare è Python, mentre la seconda posizione varia.
 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.
 
@@ -51,7 +45,7 @@ Come obiettivi dei progetti sono stati considerati:
 - *Competitions*: progetti realizzati per la partecipazione a delle competizioni o sfide.
 - *Learning & Teaching*: progetti realizzati per libri e/o tutorial o per esercitarsi.
 - *Paper Experiments*: progetti realizzati al fine di ricerca.
-- *Software Development*: comprende librerie, plug-in, tools ecc.
+- *Software Development*: comprende librerie, plug-in, tools ecc.a
 - *Other*
 
 La classifica delle librerie più utilizzate è rimasta sostanzialmente invariata per tutte le categorie; il primo posto è occupato da `TensorFlow` seguito da `PyTorch` e `Theano`.
@@ -60,7 +54,7 @@ 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, i progetti più frequenti sono quelli che hanno a che fare con video e immagini e con il \ac{NLP}.
 
-Un'ulteriore \ac{RQ} ha valutato il tipo di dipendenza, facendo distinzione tra dipendenze dirette e indirette.
+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.
 
@@ -70,7 +64,7 @@ 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.
 
-In un altro lavoro, Han *et al.* [@han2020whatprogrammersdiscuss] hanno spostato il focus sugli argomenti di discussione e su come questi variano in base al framework utilizzato.
+In un altro lavoro di Han *et al.* [@han2020whatprogrammersdiscuss] il focus si sposta sugli argomenti di discussione e su come questi variano in base al framework utilizzato.
 In questo caso all'interno dei dataset non sono rientrati unicamente i dati recuperati da GitHub, ma anche le discussioni su \ac{SO}.
 
 Questo studio ha permesso di evidenziare differenze e similitudini per quanto riguarda le discussioni che si generano intorno ai tre framework di interesse.
@@ -84,41 +78,41 @@ Da questi due studi si evince una forte somiglianza per quanto riguarda `TensorF
 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.
 
-\section[Analisi dei progetti di ML multi-linguaggio]{Analisi dei progetti di machine learning multi-linguaggio}
+## Analisi dei progetti di ML multi-linguaggio
 
 Lo studio di Grichi *et al.* [@grichi2020impactmultilanguagedevelopment] si concentra sui sistemi *multi-linguaggio*.
-In questo caso si vuole comprendere se i sistemi di \ac{ML} sono più soggetti all'essere realizzati attraverso linguaggi diversi.
-Inoltre analizzando le \ac{PR} realizzate in più linguaggi si vuole investigare se queste sono accettate con la stessa frequenza di quelle *mono-linguaggio* e se la presenza di difetti è equivalente.
+In questo caso si vuole capire se i sistemi di \ac{ML} sono più soggetti all'essere realizzati attraverso linguaggi diversi.
+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:
 
-- Cat I: include 10 sistemi di \ac{ML} *multi-linguaggio*.
+- Cat I: include 10 sistemi di \acl{ML} *multi-linguaggio*.
 - Cat II: include 10 sistemi generici *multi-linguaggio*.
-- Cat III: include 7 sistemi di \ac{ML} *mono-linguaggio*.
+- Cat III: include 7 sistemi di \acl{ML} *mono-linguaggio*.
 
 Successivamente sono state scaricate le \ac{PR} di ogni progetto considerato.
-Le \ac{PR} sono state categorizzate per individuare quelle accettate e quelle rifiutate.
-Inoltre le \ac{PR} sono state categorizzate anche il base al numero di linguaggi utilizzati.
+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 \ac{PR}.
+Infine per ogni \ac{PR} è stato individuato il tempo necessario alla sua accettazione o chiusura e i difetti introdotti dalla \acl{PR}.
 
 Per quanto riguarda la percentuale di linguaggi di programmazione utilizzati i progetti della categoria I e II sono comparabili.
 La principale differenza riguarda i tipi di linguaggi utilizzati.
-Nel caso dei progetti *multi-linguaggio* di \ac{ML} l'accoppiata più comune è Python e C/C++.
+Nel caso dei progetti *multi-linguaggio* di \acl{ML} l'accoppiata più comune è Python e C/C++.
 Mentre nel caso dei progetti generici la coppia più comune è data da Java e C/C++.
-I progetti della categoria I e II sono paragonabili anche rispetto al numero di \ac{PR} e \ac{PR} *multi-linguaggio*.
+I progetti della categoria I e II sono paragonabili anche rispetto al numero di \ac{PR}s e \ac{PR}s *multi-linguaggio*.
 
-Lo studio ha evidenziato come all'interno dei progetti di \ac{ML} le \ac{PR} *mono-linguaggio* sono accettate molto più facilmente rispetto a quelle *multi-linguaggio*.
+Lo studio ha evidenziato come all'interno dei progetti di \acl{ML} le \acl{PR} *mono-linguaggio* sono accettate molto più facilmente rispetto a quelle *multi-linguaggio*.
 Inoltre anche nel caso in cui queste vengano accettate, il tempo necessario alla loro accettazione è maggiore.
-Infine si è visto anche che rispetto alle \ac{PR} *multi-linguaggio* non esistono differenze in base all'introduzione di *bug* tra i progetti della categoria I e II.
-Mentre le \ac{PR} che includono un singolo linguaggio sembrano essere più affette da *bug* nel caso dei sistemi di \ac{ML}.
+Infine si è visto anche che rispetto alle \ac{PR}s *multi-linguaggio* non esistono differenze in base all'introduzione di *bug* tra i progetti della categoria I e II.
+Mentre le \acl{PR} che includono un singolo linguaggio sembrano essere più affette da *bug* nel caso dei sistemi di \acl{ML}.
 
-\section[Problematiche caratteristiche del ML]{Problematiche caratteristiche del machine learning}
+## Problematiche caratteristiche del ML
 
-In letteratura sono presenti anche lavori che si concentrano sull'analisi delle problematiche e dei *bug* riscontrati all'interno di applicazioni di \ac{ML}.
+In letteratura sono presenti anche lavori che si concentrano sull'analisi delle problematiche e dei *bug* riscontrati all'interno di applicazioni di \acl{ML}.
 Nello studio di Zhang *et al.* [@zhang2018empiricalstudytensorflow] l'attenzione è rivolta unicamente alle problematiche correlate a `TensorFlow`.
-Per lo studio sono stati recuperati dei *bug* di `TensorFlow` sia da progetti su GitHub (88 elementi) sia da quesiti su \ac{SO} (87 elementi).
+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 recuperate dalla discussione.
@@ -140,12 +134,12 @@ Per quanto riguarda le cause è stato possibile individuarne sei:
 - *Structure Inefficiency*: questa categoria può essere vista come una versione più *soft* della prima categoria.
 Infatti in questo caso il problema nella struttura non genera un errore ma solo delle inefficienze.
 
-Anche lo studio di Humbatova *et al.* [@humbatova-2019-taxonomyrealfaults] ha come obbiettivo l'analisi delle problematiche legate al \ac{ML}.
+Anche lo studio di Humbatova *et al.* [@humbatova-2019-taxonomyrealfaults] ha come obbiettivo l'analisi delle problematiche legate al \acl{ML}.
 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 i dati sono stati recuperati sia da \ac{SO} che da GitHub.
-Inoltre per questo studio è stata anche svolta un'intervista a 20 persone tra ricercatori e sviluppatori nel campo del \ac{ML}.
+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,38 +150,38 @@ Tra le categorie di primo livello ci sono:
 - *Training*: questa categoria è la più ampia della tassonomia.
   Rientrano in questa categoria la qualità e il preprocessing dei dati utilizzati per l'apprendimento, il *tuning* degli *hyperparametri*, la scelta della funzione di perdita più appropriata ecc.
 - *GPU Usage*: in questa categoria ricadono tutti i problemi nell'uso della \ac{GPU}.
-- *API*: rientrano in questa categoria tutti i problemi generati da un non corretto utilizzo dell'\ac{API} del framework di \ac{ML}.
+- *API*: rientrano in questa categoria tutti i problemi generati da un non corretto utilizzo dell'\ac{API} del framework di \acl{ML}.
 
 Come si può notare, fatta salva la specificità del primo lavoro, esiste una forte similitudine tra le categorie di problemi individuate dai due studi.
 
-\section[Studio di discussioni Stack Overflow riguardanti il ML]{Studio di discussioni Stack Overflow riguardanti il machine learning}
+## Analisi delle discussioni di Stack Overflow riguardanti il ML
 
-Nello studio di Bangash *et al.* [@bangash2019whatdevelopersknow] viene svolta un'analisi degli argomenti di \ac{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 \ac{SO}, mentre l'altro lavoro univa le domande di \ac{SO} alla discussione generata all'interno dei repository di GitHub.
+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.
 
 In questo caso il topic più frequentemente discusso riguarda la presenza di errori all'interno del codice.
 Seguono discussioni rispetto agli algoritmi di apprendimento e al training dei dati.
-Lo studio ha evidenziato anche come molte discussioni riguardano librerie e framework di \ac{ML} come ad esempio `numpy`, `pandas`, `keras`, `Scikit-Learn`, ecc.
+Lo studio ha evidenziato anche come molte discussioni riguardano librerie e framework di \acl{ML} come ad esempio `numpy`, `pandas`, `keras`, `Scikit-Learn`, ecc.
 Tutte queste discussioni sono state inserite nel topic *framework*.
 
-Anche nel lavoro di Alshangiti *et al.* [@alshangiti2019whydevelopingmachine] vengono analizzate le domande presenti sulla piattaforma \ac{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 \ac{ML} e le altre.
+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 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 \ac{ML}.
+  L'individuazione dei post è avvenuta attraverso la definizione di una lista contente 50 tag utilizzate su \ac{SO} per le domande di \acl{ML}.
 - *Qualitative Study Sample*: contiene 684 post realizzati da 50 utenti.
   Questo campione è stato ottenuto eseguendo un ulteriore campionamento sul campione discusso al punto precedente.
-- *Baseline Sample*: si compone di post che non riguardano il \ac{ML}.
+- *Baseline Sample*: si compone di post che non riguardano il \acl{ML}.
   Questo campione viene utilizzato per comparare le domande di \ac{ML} con quelle generiche.
 
-La prima *\ac{RQ}* dello studio vuole verificare se rispondere ad una domanda inerente al \ac{ML} sia più complicato.
+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 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 \ac{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 \ac{SO} c'è una carenza di esperti di \ac{ML} [^expertise-rank].
+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].
 
 [^expertise-rank]: L'individuazione degli esperti è avvenuta secondo l'approccio *ExpertiseRank*.
 Questo approccio crea un grafo diretto, in cui gli utenti sono rappresentati dai nodi e gli archi rappresentano una relazione di aiuto, attraverso il quale è possibile determinare l'esperienza degli utenti.
@@ -196,12 +190,12 @@ 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 \ac{DL} le maggiori problematiche riguardano 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}
 
-Nello studio di Hassan [@hassan2009predictingfaultsusing] si vuole investigare in che modo la complessità del processo del cambiamento del software vada ad impattare sull'introduzione di difetti all'interno della codebase.
+Nello studio di Hassan [@hassan2009predictingfaultsusing] si vuole capire in che modo la complessità del processo del cambiamento del software vada ad impattare sull'introduzione di difetti all'interno della codebase.
 Per valutare la complessità del processo di cambiamento è stato *preso in prestito* il concetto di entropia [@shannon1948mathematicaltheorycommunication] utilizzato nella teoria della comunicazione.
 
 Lo studio è stato condotto su sei progetti open source di grandi dimensioni.

src/chapter_3.md

@@ -1,33 +1,29 @@
 # Costruzione del dataset e metodologia {#sec:methodology}
 
-L'obiettivo di questa tesi è verificare la presenza di differenza all'interno di progetti di \ac{ML} rispetto a come sono trattati gli interventi di *issue fixing* legati al \ac{ML} e quelli generici.
-L'attenzione è rivolta all'impatto degli interventi sull'architettura del sistema, alle tempistiche necessarie alla risoluzione e al livello di discussione di questi difetti.
-Inoltre si vuole anche comprendere se esistono delle fasi del processo di sviluppo che sono più critiche di altre.
-
 ## Research Questions
 
-Gli obiettivi di questa tesi sono stati racchiusi in cinque \ac{RQ} di seguito elencate.
+Gli obiettivi di questa tesi illustrati nella @sec:goals sono stati racchiusi in cinque \acl{RQ} di seguito elencate.
 
-- **RQ1**: *come il machine learning e' distribuito sull'architettura dei progetti?*
+- **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 concentrata sui file e sulle directory modificate durante interventi di *issue fixing*.
-  Obiettivo di questa domanda è anche individuare la percentuale di file che utilizzano import riconducibili a librerie e framework di \ac{ML}.
-- **RQ2**: *come sono distribuiti i bug sulle diverse fasi di machine learning?* 
+  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 \ac{ML} si compone di più fasi.
+  Il workflow tipico per lo sviluppo di un'applicazione di \acl{ML} si compone di più fasi.
   L'obiettivo di questa *\ac{RQ}* è quello di individuare le fasi più critiche per quanto riguarda l'introduzione di difetti all'interno del prodotto software.
-- **RQ3**: *esiste una differenza di entropia del cambiamento tra machine learning bug e altri bug?*
+- **RQ3**: *esiste una differenza di entropy tra \ac{ML} bug e altri bug?*
 
-  A partire dai lavori precedenti svolti sull'entropia di un cambiamento, si vuole investigare se esiste una differenza in termini di entropia generata tra le correzioni dei difetti ascrivibili al \ac{ML} e gli altri difetti.
-- **RQ4**: *come varia il livello di discussione tra machine learning bug e altri bug?*
+  A partire dai lavori precedenti svolti sull'entropia di un cambiamento, si vuole capire se esiste una differenza in termini di entropia generata tra le correzioni dei difetti ascrivibili al \acl{ML} e gli altri difetti.
+- **RQ4**: *come varia il livello di discussione tra \ac{ML} bug e altri bug?*
 
   Questa *\ac{RQ}* riguarda il livello di discussione dei *bug*.
-  In particolare si vuole comprendere se, all'interno dei progetti di \ac{ML}, i bug generici sono discussi con lo stesso livello di approfondimento di quelli specifici del \ac{ML}.
-- **RQ5**: *come varia il time-to-fix tra machine learning bug e altri bug?*
+  In particolare si vuole capire se, all'interno dei progetti di \acl{ML}, i bug generici sono discussi con lo stesso livello di approfondimento di quelli specifici del \ac{ML}.
+- **RQ5**: *come varia il time-to-fix tra \ac{ML} bug e altri bug?*
 
   Un altro aspetto caratteristico di un *fix* è il tempo necessario per poter essere attuato.
-  Questa *\ac{RQ}* ha lo scopo di verificare l'esistenza di differenze tra i *bug* generici e quelli di \ac{ML}.
+  Questa *\ac{RQ}* ha lo scopo di verificare l'esistenza di differenze tra i *bug* generici e quelli di \acl{ML}.
 
 ## Selezione dei progetti
 
@@ -37,37 +33,37 @@ In questo modo è stato possibile ottenere una lista di $26758$ repository che
 
 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 ad altri aspetti, come il numero di fork, il numero di *contributors* e il numero di issue chiuse.
+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 ad altri aspetti, come il numero di fork, il numero di *contributors* e il 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.
 
 I progetti che hanno superato questa prima selezione dovevano:
 
 - essere lavori originali, per cui sono stati esclusi tutti i fork.
-- avere almeno cento issue chiuse.
+- avere almeno cento issues chiuse.
 - avere almeno dieci contributors.
 - avere almeno venticinque fork.
 
 Alla fine di questa prima selezione il numero di repository si è ridotto a sessantasei e 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 issue e commit
+## Fetch di issues e commit
 
-Una volta individuati i progetti da analizzare si è reso necessario recuperare l'intera storia dei progetti e le issue ad essi associate.
+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 issue, essendo queste informazioni non direttamente contenute all'interno del repository `git`, è stato necessario utilizzare nuovamente l'\ac{API} di GitHub.
+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 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:
 
 - $34180$ commit.
-- $15267$ tra issue e pull request.
+- $15267$ tra issues e pull request.
 
 ## Classificazione dei dati
 
-### Classificazione delle issue {#sec:classificazione-issues}
+### Classificazione delle issues {#sec:classificazione-issues}
 
-Al fine di poter eseguire un confronto tra i *fix* di \ac{ML} e quelli *generici* è stato necessario classificare sia le issue 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.
 Il numero elevato di elementi non rende praticabile una classificazione manuale per cui si è optato per una classificazione automatica.
 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.
 A tal fine sono stati implementati ed analizzati due classificatori, uno supervisionato e uno non supervisionato.
@@ -78,12 +74,12 @@ I due modelli considerati sono:
 - un modello *naïve Bayes* [@2021naivebayesclassifier; @harrington2012machinelearningaction].
 
 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 \ac{ML} non è stata costruita da zero, ma è basata sul lavoro di Humbatova *et al.* [@humbatova-2019-taxonomyrealfaults].
-In questo modo tutte le issue che utilizzavano almeno un vocabolo tipico del \ac{ML} sono state classificate come issue di \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 issue.
-A tal scopo è stato eseguito un campionamento stratificato in base al progetto di provenienza di $376$ issue che sono state divise tra due lettori e labellate.
-La label delle *issue* è stata determinata andando ad analizzare il titolo, il corpo e i commenti associati alla *issue*.
+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 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*.
 
@@ -106,32 +102,32 @@ A partire dal dataset *labellato* è stato possibile costruire un training e un
 Mentre le performance del primo modello sono state valutate sull'intero dataset.
 
 \begin{figure}[!ht]
-\subfloat[Numero di issue rispetto al tipo\label{fig:labeling-type}]{%
+\subfloat[Numero di issues rispetto al tipo\label{fig:labeling-type}]{%
     \includegraphics[width=0.45\textwidth]{src/figures/count-type.pdf}
   }
   \hfill
-\subfloat[Numero di issue rispetto alla fase\label{fig:labeling-phases}]{%
+\subfloat[Numero di issues rispetto alla fase\label{fig:labeling-phases}]{%
     \includegraphics[width=0.45\textwidth]{src/figures/count-phases.pdf}
   }
-  \caption{Risultati della classificazione manuale delle issue}
+  \caption{Risultati della classificazione manuale delle issues}
   \label{fig:labeling}
 \end{figure}
 
 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 basato sulla lista di vocaboli è leggermente più preciso del modello bayesiano, ma presenta una *recall* decisamente più bassa.
-Dalla @fig:labeling-type si evince la natura minoritaria delle issue di \ac{ML} rispetto alle issue generiche, per questo motivo si è preferito il modello naïve Bayes in modo da perdere quante meno istanze possibili anche a costo di sacrificare leggermente la precisione.
+Dalla @fig:labeling-type si evince la natura minoritaria delle issues di \ac{ML} rispetto alle issues generiche, per questo motivo si è preferito il modello naïve Bayes in modo da perdere quante meno istanze possibili anche a costo di sacrificare leggermente la precisione.
 
 |           | Classificatore statico | naïve Bayes |
 |-----------|------------------------|-------------|
 | precision | 0.46                   | 0.41        |
 | recall    | 0.74                   | 0.94        |
 
-: Confronto dei due modelli per la classificazione delle issue. {#tbl:confronto-modelli-classificazione-issues}
+: Confronto dei due modelli per la classificazione delle issues. {#tbl:confronto-modelli-classificazione-issues}
 
 ### Classificazione dei commit {#sec:classificazione-commit}
 
 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 *issue* attraverso la notazione *"#"*.
+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à la cui distribuzione in base al tipo è riportata in @fig:count-commit.
 
 Da ogni commit sono state estratte le informazioni rilevanti per le analisi.
@@ -141,25 +137,25 @@ In particolare è stato conservato:
 - L'hash del commit.
 - La data del commit.
 - L'autore del commit.
-- La lista dei file modificati.
+- La lista dei files modificati.
 - Le linee modificate.
-- La lista delle *issue* citate.
+- La lista delle *issues* citate.
 
-\newpage
-
-A questo punto è stato possibile separare i *fix* di \ac{ML} da quelli generici.
-La classificazione è avvenuta attraverso la lista delle issue 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 \acl{ML} da 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 \acl{ML}.
 
 ![Risultato della classificazione dei commit](figures/count-commit.pdf){#fig:count-commit width=80%}
 
+\newpage
+
 ## Metodologia
 
-### RQ1: come il machine learning e' distribuito sull'architettura dei progetti?
+### RQ1: come il ML e' distribuito sull'architettura dei progetti?
 
 In questa prima domanda si vuole andare a capire quant'è ampia la *superficie* del progetto che viene modificata durante gli interventi di *fix*, facendo distinzione tra le correzioni che riguardano il \ac{ML} e quelle generiche.
-Inoltre si vuole anche comprendere quanti file importano librerie tipiche del \ac{ML}.
+Inoltre si vuole anche capire quanti file importano librerie tipiche del \acl{ML}.
 
-Per poter svolgere la prima analisi è stato necessario individuare il numero totale di file modificati per *fix* generici e per i *fix* specifici del \ac{ML}.
+Per poter svolgere la prima 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}).
 All'interno di ogni raggruppamento si è eseguita la concatenazione della lista dei file modificati.
 Poiché non si è interessati al numero di modifiche che ha subito ogni file le liste sono state trasformate in insiemi per eliminare le ripetizioni.
@@ -168,54 +164,54 @@ 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 è ottenuto l'insieme totale dei file 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 directory.
-E in modo analogo si è calcolata la percentuale di directory modificate durante interventi di \ac{ML} (`ml_dirs_ratio`) e interventi generici (`no_ml_dirs_ratio`).
+Attraverso la funzione di libreria Python `os.path.dirname` sono stati ottenuti i tre insiemi sopra citati anche per quanto riguarda le directories.
+E in modo analogo si è calcolata la percentuale di directories modificate durante interventi di \acl{ML} (`ml_dirs_ratio`) e interventi generici (`no_ml_dirs_ratio`).
 Queste distribuzioni sono state analizzate graficamente attraverso l'ausilio di boxplot.
 
 Per la seconda analisi si è reso necessario conoscere per ogni file la lista degli import utilizzati.
-Questa informazione è stata recuperata attraverso uno script, che dato in input un progetto restituisce la lista dei file affiancati dalla lista degli import utilizzati all'interno del file stesso.
-L'individuazione dei file di \ac{ML} è avvenuta mediante la definizione di due gruppi di librerie tipiche del \ac{ML}.
+Questa informazione è stata recuperata attraverso uno script, che dato in input un progetto restituisce la lista dei files affiancati dalla lista degli import utilizzati all'interno del file stesso.
+L'individuazione dei file di \acl{ML} è avvenuta mediante la definizione di due gruppi di librerie tipiche del \ac{ML}.
 
-- Gruppo 1: librerie specifiche del \ac{ML} come ad esempio `keras`, `TensorFlow` e `Pytorch`.
+- Gruppo 1: librerie specifiche del \acl{ML} come ad esempio `keras`, `TensorFlow` e `Pytorch`.
 - Gruppo 2: librerie utilizzate in ambito \ac{ML}, ma anche in altri contesti. Appartengono a questo gruppo librerie come `numpy`, `scipy` e `pandas`.
 
-Ogni file è stato classificato come di \ac{ML} o meno in base a due livelli.
-Nel primo caso, indicato con *all*, per rientrare all'interno dei file che fanno uso di librerie di \ac{ML} bastava importare almeno una libreria contenuta in uno dei due gruppi precedentemente descritti.
-Mentre nel secondo caso, indicato con *wo_pandas_numpy_scipy*, era necessario importare almeno una libreria presente nel primo gruppo.
+Ogni file è stato classificato come di \acl{ML} o meno in base a due livelli severità.
+Nel caso della severità *base* per rientrare all'interno dei file che fanno uso di librerie di \ac{ML} bastava importare almeno una libreria contenuta in uno dei due gruppi precedentemente descritti.
+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 in questo caso le distribuzioni sono state analizzate attraverso l'ausilio di un boxplot.
 
-### RQ2: come sono distribuiti i bug sulle diverse fasi di machine learning?
+### RQ2: come sono distribuiti i bug sulle diverse fasi di ML?
 
-Come illustrato nella @sec:classificazione-commit per poter determinare la natura di un *issue fix* si è fatto ricorso alla classificazione delle *issue* ad esso associate.
-La maggior parte delle *issue* è 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 *issue* 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).
+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).
 In questa *\ac{RQ}* si vuole andare a valutare come questo dato aggiuntivo sulle fasi viene *proiettato* sui commit di *fix*.
 
-Per poter svolgere questa analisi è necessario incrociare i dati sui commit di *fix* con la classificazione delle *issue*.
-A partire dal dataset delle *issue* è stato creato per ogni progetto un dizionario *issue* $\rightarrow$ fase.
+Per poter svolgere questa analisi è necessario incrociare i dati sui commit di *fix* con la classificazione delle *issues*.
+A partire dal dataset delle *issues* è stato creato per ogni progetto un dizionario *issue* $\rightarrow$ fase.
 Quindi per ogni commit si è individuata la fase attraverso questo dizionario ausiliario.
 
 In particolare un commit poteva citare:
 
-- nessuna *issue* inclusa nel dizionario. In questo caso non è possibile individuare la fase del commit.
-- una *issue* presente nel dizionario. In questo caso al commit viene assegnata la fase della *issue*.
-- più di una *issue* presente nel dizionario. In questo caso al commit venivano associate più fasi[^multi-phases].
+- nessuna *issues* inclusa nel dizionario. In questo caso non è possibile individuare la fase del commit.
+- una *issues* presente nel dizionario. In questo caso al commit viene assegnata la fase della *issue*.
+- più di una *issues* presente nel dizionario. In questo caso al commit venivano associate più fasi[^multi-phases].
 
 [^multi-phases]: Nessun commit di *fix* presente nel dataset utilizzato è rientrato in questa categoria.
 
 L'analisi quantitativa è avvenuta attraverso un barplot in cui venivano riportati unicamente i commit a cui è stato possibile assegnare almeno una fase.
 
-### RQ3: esiste una differenza di entropia del cambiamento tra machine learning bug e altri bug?
+### RQ3: esiste una differenza di entropy tra ML bug e altri bug?
 
 La successiva analisi aveva lo scopo di verificare l'esistenza di una differenza tra l'entropia del *fix* rispetto alla natura di questi.
 Il lavoro di questa analisi è basato sul modello *BCC* discusso nella @sec:entropy.
 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.
-Il dato rispetto alle linee modificate è già presente nel dataset di partenza (si veda @sec:classificazione-commit), mentre il numero di file modificati può essere ricavato dalla lista dei file modificati nel commit.
+Il dato rispetto alle linee modificate è già presente nel dataset di partenza (si veda @sec:classificazione-commit), mentre il numero di file modificati può essere ricavato dalla lista dei files modificati nel commit.
 
 Inoltre per poter calcolare la probabilità di un 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].
@@ -226,27 +222,27 @@ 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.
 
 Le due distribuzioni sono state valutate graficamente attraverso un boxplot.
-Inoltre sono stati svolti dei test statistici (*Wilcoxon ranksum* e *Cliff's delta*) per verificare la rilevanza di queste differenze.
+Inoltre sono stati svolti dei test statistici (*ranksum* e *Cliff's delta*) per verificare la rilevanza di queste differenze.
 
-### RQ4: come varia il livello di discussione tra machine learning bug e altri bug?
+### RQ4: come varia il livello di discussione tra ML bug e altri bug?
 
-Per rispondere a questa domanda è stato necessario andare a valutare il numero di commenti presenti all'interno di ogni issue.
-Questo dato non è presente nel dataset dei commit generato inizialmente (si veda @sec:classificazione-commit), ma può essere ricavato a partire dalla lista delle *issue* citate.
-Dato un commit si è considerata la lista delle *issue* citate, e per ogni *issue* citata si è calcolato il numero di commenti.
-Poiché un singolo commit può far riferimento a più *issue* è stato necessario anche calcolare il numero di commenti medi.
+Per rispondere a questa domanda è stato necessario andare a valutare il numero di commenti presenti all'interno di ogni issues.
+Questo dato non è presente nel dataset dei commit generato inizialmente (si veda @sec:classificazione-commit), ma può essere ricavato a partire dalla lista delle *issues* citate.
+Dato un commit si è considerata la lista delle *issues* citate, e per ogni *issue* citata si è calcolato il numero di commenti.
+Poiché un singolo commit può far riferimento a più *issues* è stato necessario anche calcolare il numero di commenti medi.
 
 Il livello della discussione non viene determinato solo dal numero di commenti, ma anche dalla lunghezza di questi.
 Quindi per ogni *issue* è stato calcolato anche il numero medio di parole presenti all'interno di un commento.
 
 I dati per entrambe le distribuzioni sono stati valutati graficamente attraverso l'ausilio di un boxplot e attraverso i test statistici illustrati precedentemente.
 
-### RQ5: come varia il time-to-fix tra machine learning bug e altri bug?
+### RQ5: come varia il time-to-fix tra ML bug e altri bug?
 
 In quest'ultima analisi si vuole andare a valutare se c'è differenza nel tempo necessario per eseguire il *fix*.
-Anche in questo caso, per poter rispondere alla domanda, è necessario incrociare i dati dei commit con quelli delle *issue* attraverso la lista delle *issue* citate.
+Anche in questo caso, per poter rispondere alla domanda, è necessario incrociare i dati dei commit con quelli delle *issues* attraverso la lista delle *issues* citate.
 Dato una *issue* sono stati individuate la data di apertura e di chiusura.
-Nel caso in cui ad un commit sono associate più *issue* è stata presa come data di apertura il minimo tra tutte le date di apertura delle *issue* e, in modo analogo, si è proceduto anche per la data di chiusura con la differenza che i dati sono stati aggregati attraverso la funzione `max`.
+Nel caso in cui ad un commit sono associate più *issues* è stata presa come data di apertura il minimo tra tutte le date di apertura delle *issues* e, in modo analogo, si è proceduto anche per la data di chiusura con la differenza che i dati sono stati aggregati attraverso la funzione `max`.
 
 Una volta noto il momento di apertura e di chiusura della problematica è stato possibile calcolare il numero di giorni intercorsi tra questi due istanti temporali.
-Le distribuzioni così ottenute sono state analizzate ancora una volta mediante un *boxplot*, il test *Wilcoxon ranksum* e il test *Cliff's delta*.
+Le distribuzioni così ottenute sono state analizzate ancora una volta mediante un *boxplot*, il test *ranksum* e il test *Cliff's delta*.
 

src/chapter_4.md

@@ -1,21 +1,20 @@
 # Risultati {#sec:results}
 
-\hypertarget{sec:rq1}{%
-\section[RQ1: come il ML e' distribuito sull'architettura dei progetti?]{RQ1: come il machine learning e' distribuito sull'architettura dei progetti?}\label{sec:rq1}}
+## RQ1: come il ML e' distribuito sull'architettura dei progetti? {#sec:rq1}
 
-Dalla @fig:files-directories si può notare che i cambiamenti generici vanno ad impattare su una superficie maggiore del sistema, sia che l'analisi sia svolta al livello di file che di directory.
-Un'ulteriore aspetto interessante riguarda la varianza delle distribuzioni, infatti, indipendentemente dalla granularità dell'analisi, il dato riguardante i cambiamenti di \ac{ML} è caratterizzato da una maggiore varianza.
+Dalla @fig:files-directories si può notare che i cambiamenti generici vanno ad impattare su una superficie maggiore del sistema, sia che l'analisi sia svolta al livello di files che di directories.
+Un'ulteriore aspetto interessante riguarda la varianza delle distribuzioni, infatti, indipendentemente dalla granularità dell'analisi, il dato riguardante i cambiamenti di \acl{ML} è caratterizzato da una maggiore varianza.
 
-![Percentuale di file e directory modificate in base al tipo di cambiamento](figures/files-and-directories.pdf){#fig:files-directories width=100%}
+![Percentuale di files e directories modificate in base al tipo di cambiamento](figures/files-and-directories.pdf){#fig:files-directories width=100%}
 
 Nel boxplot in @fig:imports sono invece riportati i risultati per quanto riguarda l'utilizzo di import di \ac{ML}.
-Si può notare che, indipendentemente dal livello di analisi, la percentuale di file che utilizzano librerie di \ac{ML} è caratterizzata da una forte varianza.
+Si può notare che, indipendentemente dalla severità dell'analisi, la percentuale di file che utilizzano librerie di \acl{ML} è caratterizzata da una forte varianza.
 Ciò indica che i progetti inclusi all'interno dello studio sono di varia natura e che alcuni sono più incentrati sul \ac{ML} rispetto ad altri.
-Inoltre, considerando l'analisi *strict*, è possibile osservare come solo un $25\%$ dei progetti abbia una percentuale di file di \ac{ML} superiore al $45\%$.
+Inoltre, considerando l'analisi *strict*, è possibile osservare come solo un $25\%$ dei progetti abbia una percentuale di files di \ac{ML} superiore al $45\%$.
 
 ![Percentuale di file che utilizzano librerie di ML](figures/imports.pdf){#fig:imports width=80%}
 
-In relazione all'analisi *wo_pandas_numpy_scipy* sono stati poi analizzati i cinque progetti più \ac{ML} *intensive* per valutare eventuali caratteristiche comuni rispetto al dominio applicativo.
+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 immagini.
 L'unica eccezione è data dal progetto *jdb78/pytorch-forecasting* che si occupa del *forecasting* di serie temporali.
 
@@ -31,23 +30,21 @@ L'unica eccezione è data dal progetto *jdb78/pytorch-forecasting* che si occupa
 
 \begin{tcolorbox}[colback=white, boxrule=0.3mm]
 Sia nel caso in cui l'analisi sia svolta sui file modificati, sia nel caso in cui sia svolta sugli import, il dato riguardante il \ac{ML} è caratterizzato da una forte varianza.
-Questo vuol dire che la diversa natura dei progetti considerati nello studio genera delle caratteristiche diverse per quanto riguarda l'architettura.
+Questo vuol dire che i progetti considerati nello studio sono di varia natura.
 \end{tcolorbox}
 
 \newpage
 
-\hypertarget{sec:rq2}{%
-\section[RQ2: come sono distribuiti i bug sulle diverse fasi di ML?]{RQ2: come sono distribuiti i bug sulle diverse fasi di machine learning?}\label{sec:rq2}}
+## RQ2: come sono distribuiti i bug sulle diverse fasi di ML? {#sec:rq2}
 
-Andando a confrontare la distribuzione delle fasi sui commit (@fig:count-fix-phases) rispetto alla distribuzione sulle issue (@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.
 
 ![Istanze dei fix in base alla fase](figures/count-fix-phases.pdf){#fig:count-fix-phases width=70%}
 
-\hypertarget{sec:rq3}{%
-\section[RQ3: esiste una differenza di entropia del cambiamento tra ML bug e altri bug?]{RQ3: esiste una differenza di entropia del cambiamento tra machine learning bug e altri bug?}\label{sec:rq3}}
+## RQ3: esiste una differenza di entropy tra ML bug e altri bug? {#sec:rq3}
 
 Dal boxplot[^boxplot-entropy] in @fig:files-entropy è possibile notare una distribuzione equivalente per le due tipologie di fix.
 Una situazione analoga si riscontra anche nell'analisi sulle linee (@fig:lines-entropy) anche se in questo caso è possibile notare che i valori di entropia associati ai fix di \ac{ML} sono shiftati leggermente verso l'alto.
@@ -55,7 +52,7 @@ Una situazione analoga si riscontra anche nell'analisi sulle linee (@fig:lines-e
 [^boxplot-entropy]: Per ragioni di visualizzazione è stato scelto il $95$-$esimo$ quantile come limite superiore di entrambi i grafici.
 
 \begin{figure}[!ht]
-\subfloat[Entropia calcolata sui file\label{fig:files-entropy}]{%
+\subfloat[Entropia calcolata sui files\label{fig:files-entropy}]{%
 \includegraphics[width=0.45\textwidth]{src/figures/files-entropy.pdf}
   }
   \hfill
@@ -66,29 +63,28 @@ Una situazione analoga si riscontra anche nell'analisi sulle linee (@fig:lines-e
   \label{fig:entropy}
 \end{figure}
 
-Per verificare la rilevanza statistica di questa diversità sono stati svolti il *Wilcoxon ranksum* test e il *Cliff's delta* i cui risultati sono riportati nella @tbl:test-entropy.
-Nel caso dell'entropia del cambiamento calcolata 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.
+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 segno che la complessità dell'intervento non varia in base al tipo di intervento.
 
-|      | Wilcoxon ranksum p-values | Cliff's delta |
-|------|:----------------:|:-------------:|
-| file |       0.059      |     0.044     |
-| line |     5.932e-06    |     0.105     |
+|              | ranksum p-values | Cliff's delta |
+|--------------|:----------------:|:-------------:|
+| file entropy |       0.059      |     0.044     |
+| line entropy |     5.932e-06    |     0.105     |
 
-: Risultati dei test statistici per quanto riguarda l'entropia del cambiamento {#tbl:test-entropy}
+: Risultati dei test statistici per quanto riguarda l'entropia {#tbl:test-entropy}
 
 \begin{tcolorbox}[colback=white, boxrule=0.3mm]
 Non sono emerse differenze statisticamente rilevanti per quanto riguarda la complessità del processo di cambiamento.
 \end{tcolorbox}
 
-\hypertarget{sec:rq4}{%
-\section[RQ4: come varia la discussione tra ML bug e altri bug?]{RQ4: come varia il livello di discussione tra machine learning bug e altri bug?}\label{sec:rq4}}
+## 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.
 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 issue o non presenta commenti o ne presenta uno solo.
-Mentre la differenza interquartile dei *fix* di \ac{ML} è compreso tra uno e cinque, quindi nel $50\%$ interno tutte le issue hanno almeno un commento di risposta.
+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.
 
 [^boxplot-discussion]: In questo caso il limite superiore è pari al $97$-$esimo$ quantile.
 
@@ -108,13 +104,13 @@ Mentre la differenza interquartile dei *fix* di \ac{ML} è compreso tra uno e ci
 
 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 \ac{ML} c'è maggiore discussione, ma la discussione è anche più *densa*.
+Per cui non solo nei *fix* di \acl{ML} c'è maggiore discussione, ma la discussione è anche più *densa*.
 
 Anche in questo caso sono stati svolti i test statistici.
 In @tbl:test-discussion è possibile vedere come per entrambe le metriche considerate il *p-value* sia abbondantemente inferiore alla soglia di $0.05$ quindi abbiamo una conferma della diversità delle due distribuzioni riscontrata dal boxplot.
 Inoltre, per entrambe le metriche, abbiamo un *effect size* medio.
 
-|                     | Wilcoxon ranksum p-values | Cliff's delta |
+|                     | ranksum p-values | Cliff's delta |
 |---------------------|:----------------:|:-------------:|
 | commenti medi       |     9.053e-75    |     0.425     |
 | parole per commento |     2.889e-59    |     0.377     |
@@ -126,26 +122,25 @@ Nel caso della issue numero 96 del progetto *BrikerMan/Kashgari* la problematica
 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 *ljvmiranda921/pyswarms* è una richiesta di aiuto da parte dell'autore per migliorare l'implementazione della ricerca per il tuning degli hyperparametri.
+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 issue che presentano un alto numero di parole medie per commento.
+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.
 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{issue} di \ac{ML} sono caratterizzata da una maggiore discussione.
+Le \emph{issues} di \acl{ML} sono caratterizzata da una maggiore discussione.
 Un valore molto elevato di parole per commento può indicare uno scambio massiccio all'interno della discussione di \emph{snippet} di codice, di log d'errore e configurazioni dell'ambiente.
 \end{tcolorbox}
 
-\hypertarget{sec:rq5}{%
-\section[RQ5: come varia il time-to-fix tra ML bug e altri bug?]{RQ5: come varia il time-to-fix tra machine learning bug e altri bug?}\label{sec:rq5}}
+## 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.
-In particolare i bug di \ac{ML} necessitano, mediamente, di maggior tempo per essere risolti e sono caratterizzati da una varianza maggiore.
+In particolare i bug di \acl{ML} necessitano, mediamente, di maggior tempo per essere risolti e sono caratterizzati da una varianza maggiore.
 Inoltre è possibile vedere come la mediana non sia centrata, bensì spostata verso il basso.
 Questo vuol dire che il $50\%$ basso dei *bug* di \ac{ML} viene comunque risolto in tempi brevi (due giorni circa), mentre l'altro $50\%$ può richiedere una quantità di tempo decisamente superiore.
 
@@ -153,7 +148,7 @@ 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 \ac{ML} per essere considerato outlier una *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.
@@ -162,7 +157,7 @@ Per quanto riguarda i *fix* che hanno richiesto un tempo estremamente lungo la c
 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 issue invece hanno necessitato di molto tempo per essere risolte in quanto venivano considerate a bassa priorità.
+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 *issue* 98 del progetto *mittagessen/kraken* che invece ha necessitato di quasi due anni.
@@ -171,26 +166,23 @@ Anche per quest'ultima *RQ* sono stati svolti i test statistici illustrati prece
 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.
 
-|            | Wilcoxon ranksum p-values | Cliff's delta |
+|            | ranksum p-values | Cliff's delta |
 |------------|:----------------:|:-------------:|
 | day-to-fix |     7.354e-53    |     0.355     |
 
 : Risultati dei test statistici per quanto riguarda il time-to-fix {#tbl:test-time-to-fix}
 
 \begin{tcolorbox}[colback=white, boxrule=0.3mm]
-Le problematiche di \ac{ML} richiedono più tempo per essere risolte.
+Le problematiche di \acl{ML} richiedono più tempo per essere risolte.
 La bassa priorità di una \emph{issue} e la presenza di \emph{work around} sono fattori che contribuiscono a ritardare l'intervento di \emph{fix}.
 \end{tcolorbox}
 
 ## Threats to validity
 
-La *threats to validity* più critica per il lavoro svolto è di tipo *construct* e riguarda la classificazione delle *issue*.
+La *threats to validity* più critica per il lavoro svolto riguarda la classificazione delle *issues*.
 La classificazione è avvenuta in modo automatico attraverso un modello *naïve Bayes*.
-Il classificatore, sebbene sia caratterizzato da una *recall* molto elevata, presenta una *precision* discreta per cui è molto probabile che all'interno tra le *issue* di \ac{ML} siano state incluse anche *issue* generiche.
-Inoltre, poiché la classificazione degli interventi di *issue fixing* dipende dalla classificazione degli *issue*, gli eventi di *misclassification* sono stati propagati anche su questa seconda classificazione.
+Il classificatore, sebbene sia caratterizzato da una *recall* molto elevata, presenta una *precision* discreta per cui è molto probabile che all'interno tra le *issues* di \ac{ML} siano state incluse anche *issues* generiche.
+Inoltre, poiché la classificazione degli interventi di *issue fixing* dipende dalla classificazione degli *issues*, gli eventi di *misclassification* sono stati propagati anche su questa seconda classificazione.
 
-Per quanto riguarda le *threat to validity* interne bisogna segnalare l'interpretazione data al *time-to-fix*.
-Infatti in questo lavoro il dato del *time-to-fix* è stato calcolato come la differenza tra l'istante di chiusura e di apertura della *issue*.
-Questa approssimazione è sicuramente semplicistica in quanto comprende altri sotto intervalli come *time-to-response*, *time-to-assign*, ecc.
-Mentre per quanto riguarda le *threat to validity* esterne va sicuramente segnalato che i risultati di questo lavoro si generalizzano unicamente per i trenta progetti inclusi nel dataset.
+Per quanto riguarda le *threat to validity* esterne va sicuramente segnalato che i risultati di questo lavoro si generalizzano unicamente per i trenta progetti inclusi nel dataset.
 

src/chapter_5.md

@@ -1,26 +1,21 @@
 # Conclusioni {#sec:conclusions}
 
 La *RQ1* (@sec:rq1) ci ha permesso di inquadrare la natura dei progetti considerati per questo studio.
-Attraverso l'analisi degli import si è mostrato come l'utilizzo di librerie di \ac{ML} vari a seconda del progetto.
-Da questo dato si può comprendere che i progetti all'interno del dataset sono diversi tra di loro e che alcuni sono più incentrati sul \ac{ML} rispetto ad altri.
-Si è anche visto che la percentuale di progetti con un numero di *source file* di \ac{ML} superiore al $45\%$ sia molto limitata.
+Attraverso l'analisi degli import si è mostrato come l'utilizzo di librerie di \acl{ML} vari a seconda del progetto.
+Da questo dato si può capire che i progetti all'interno del dataset sono diversi tra di loro e che alcuni sono più incentrati sul \ac{ML} rispetto ad altri.
+Si è anche visto che la percentuale di progetti con un numero di *source files* di \acl{ML} superiore al $45\%$ sia molto limitata.
 Inoltre andando ad analizzare la porzione di sistema impattata dai cambiamenti si è visto come anche in questo caso il dato sia caratterizzato da una forte variabilità.
 
-Le *RQ3*, *RQ4* e *RQ5* (da @sec:rq3) sono andate a valutare nello specifico le differenze in termini di entropia, discussione e *time-to-fix* tra gli interventi di *issue fixing* generici e quelli specifici del \ac{ML}.
+Le *RQ3*, *RQ4* e *RQ5* (da @sec:rq3) sono andate a valutare nello specifico le differenze in termini di entropia, discussione e *time-to-fix* tra gli interventi di *issue fixing* generici e quelli specifici del \acl{ML}.
 Da queste analisi si evince che tra i due tipi di interventi ci sono sia similitudini che differenze.
 Nel caso dell'entropia e della complessità del processo di cambiamento del software non sono emerse differenze rilevanti.
 Questo ci porta a pensare che il processo di cambiamento non varia in base al tipo di intervento, ma sia costante.
 
 Nel caso del livello di discussione e del *time-to-fix* sono emerse delle differenze confermate anche dai test statistici effettuati.
-In entrambi i casi l'essere un *fix* legato al \ac{ML} ha spinto la metrica verso l'alto.
+In entrambi i casi l'essere un *fix* legato al \acl{ML} ha spinto la metrica verso l'alto.
 Nel caso dei messaggi scambiati non solo si è riscontrato un numero medio di messaggi più elevato, ma si è visto anche che questi mediamente sono più lunghi.
 Questo dato potrebbe dipendere sia dal maggiore tempo richiesto per d'individuazione e correzione delle problematiche legate al \ac{ML}, sia da un maggiore interesse per queste problematiche rispetto alle altre.
 
-In sintesi questo lavoro ha fatto emergere sia delle similitudini che delle differenze per quanto riguarda gli interventi di *fix* all'interno di progetti di \ac{ML}.
-Le principali differenze sono state riscontrate per quanto riguarda il livello di discussione, decisamente più alto nel caso di *issue* di \ac{ML}, e il tempo necessario alla correzione dei difetti, anche in questo caso maggiore nel caso del \ac{ML}.
-Non sono emerse differenze rilevanti invece per quanto riguarda l'entropia generata dai cambiamenti.
-Infine si è visto come l'impatto delle componenti di \ac{ML} sull'architettura vada a riflettere la natura dei progetti.
-
 ## Sviluppi futuri
 
 Nella *RQ2* sfortunatamente non è stato possibile svolgere un'analisi più approfondita per la carenza di dati.
@@ -32,7 +27,3 @@ Per quanto riguarda la valutazione dell'entropia si è scelto come intervallo te
 Utilizzando questa configurazione non si è riscontrata nessuna differenza degna di nota.
 Un possibile sviluppo futuro potrebbe consistere nell'andare a valutare l'entropia considerando dei riferimenti temporali più ampi e verificare in questo caso la presenza di differenze.
 
-Infine un aspetto non considerato in questo lavoro riguarda i *contributors*.
-Una prima analisi potrebbe andare a valutare se esiste una sovrapposizione o meno tra chi effettua interventi di *fix* generici e chi si occupa di quelli legati al \ac{ML}.
-Inoltre si potrebbero andare a ricercare anche differenze in base al tipo di contributore (interno, esterno).
-

src/metadata.yaml

@@ -12,21 +12,6 @@ supervisor:
 cosupervisor:
   title: Dott.ssa
   name: Vittoria Nardone
-abstract: |
-  Negli ultimi anni lo sviluppo di progetti di machine learning (ML) ha subito una forte crescita che si è riflessa anche nell'ambito della ricerca.
-  In letteratura sono presenti diversi lavori che vanno a comparare progetti di ML con progetti generici o che confrontano progetti di ML realizzati con diversi tool e framework.
-  In questa tesi si vuole indagare l'esistenza di differenze tra issue fixing di ML e issue generiche all'interno di progetti open source di ML realizzati in Python.
-
-  In particolare l'attenzione è rivolta:
-
-  - all'impatto dei cambiamenti sull'architettura del sistema.
-  - alla distribuzione delle issue lungo le vari fasi di un workflow di ML.
-  - all'entropia del cambiamento generata dai fix.
-  - al livello di discussione delle issue.
-  - al time-to-fix delle problematiche.
-
-  Questo studio mostra come non esistano differenze rilevanti in termini di entropia del cambiamento, ma sono presenti differenze significative per quanto riguarda il time-to-fix e il livello di discussione.
-  Inoltre si è visto che la diversa natura dei progetti si riflette sull'architettura dei sistemi considerati.
 #############
 babel: italian
 lang: it-IT

util/.idea/.gitignore

@@ -1,8 +0,0 @@
-# Default ignored files
-/shelf/
-/workspace.xml
-# Datasource local storage ignored files
-/dataSources/
-/dataSources.local.xml
-# Editor-based HTTP Client requests
-/httpRequests/

util/.idea/inspectionProfiles/Project_Default.xml

@@ -1,162 +0,0 @@
-<component name="InspectionProjectProfileManager">
-  <profile version="1.0">
-    <option name="myName" value="Project Default" />
-    <inspection_tool class="PyPep8Inspection" enabled="true" level="WEAK WARNING" enabled_by_default="true">
-      <option name="ignoredErrors">
-        <list>
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-          <option value="W29" />
-          <option value="E501" />
-        </list>
-      </option>
-    </inspection_tool>
-    <inspection_tool class="PyPep8NamingInspection" enabled="true" level="WEAK WARNING" enabled_by_default="true">
-      <option name="ignoredErrors">
-        <list>
-          <option value="N806" />
-        </list>
-      </option>
-    </inspection_tool>
-  </profile>
-</component>

util/.idea/inspectionProfiles/profiles_settings.xml

@@ -1,6 +0,0 @@
-<component name="InspectionProjectProfileManager">
-  <settings>
-    <option name="USE_PROJECT_PROFILE" value="false" />
-    <version value="1.0" />
-  </settings>
-</component>

util/.idea/misc.xml

@@ -1,4 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<project version="4">
-  <component name="ProjectRootManager" version="2" project-jdk-name="Python 3.8" project-jdk-type="Python SDK" />
-</project>

util/.idea/modules.xml

@@ -1,8 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<project version="4">
-  <component name="ProjectModuleManager">
-    <modules>
-      <module fileurl="file://$PROJECT_DIR$/.idea/util.iml" filepath="$PROJECT_DIR$/.idea/util.iml" />
-    </modules>
-  </component>
-</project>

util/.idea/util.iml

@@ -1,11 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<module type="PYTHON_MODULE" version="4">
-  <component name="NewModuleRootManager">
-    <content url="file://$MODULE_DIR$" />
-    <orderEntry type="inheritedJdk" />
-    <orderEntry type="sourceFolder" forTests="false" />
-  </component>
-  <component name="TestRunnerService">
-    <option name="PROJECT_TEST_RUNNER" value="Nosetests" />
-  </component>
-</module>

util/.idea/vcs.xml

@@ -1,6 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<project version="4">
-  <component name="VcsDirectoryMappings">
-    <mapping directory="$PROJECT_DIR$/.." vcs="Git" />
-  </component>
-</project>

util/.ipynb_checkpoints/l2-checkpoint.ipynb

@@ -1,126 +0,0 @@
-{
- "cells": [
-  {
-   "cell_type": "code",
-   "execution_count": 21,
-   "metadata": {
-    "collapsed": true
-   },
-   "outputs": [
-    {
-     "data": {
-      "text/plain": [
-       "model training         128\n",
-       "model evaluation        91\n",
-       "model deployment        75\n",
-       "data cleaning           59\n",
-       "model requirements      47\n",
-       "feature engineering     36\n",
-       "data collection         25\n",
-       "Name: classification, dtype: int64"
-      ]
-     },
-     "execution_count": 21,
-     "metadata": {},
-     "output_type": "execute_result"
-    }
-   ],
-   "source": [
-    "import pandas as pd\n",
-    "\n",
-    "data = pd.read_csv('sampling_nb - sampling_nb.csv')\n",
-    "\n",
-    "data.drop(['second', 'url'], inplace=True, axis=1)\n",
-    "\n",
-    "data = data[~data['classification'].isin(['?', '', 'no pipeline', 'page not found', 'chinese', 'data labeling'])]\n",
-    "\n",
-    "data['classification'].value_counts()"
-   ]
-  },
-  {
-   "cell_type": "code",
-   "execution_count": 22,
-   "metadata": {
-    "pycharm": {
-     "name": "#%%\n"
-    }
-   },
-   "outputs": [
-    {
-     "data": {
-      "text/plain": [
-       "classification       L2 class\n",
-       "data cleaning        DP-DF        8\n",
-       "                     DP-LD        1\n",
-       "                     DP-O        17\n",
-       "                     DP-P         3\n",
-       "                     DP-R        13\n",
-       "                     DP-TE        9\n",
-       "                     DP-TM        2\n",
-       "                     DP-UT        6\n",
-       "data collection      DC-DC       13\n",
-       "                     DC-DF        4\n",
-       "                     DC-F         3\n",
-       "                     DC-NS        1\n",
-       "                     DC-O         1\n",
-       "                     DC-S         3\n",
-       "feature engineering  FE-BC        8\n",
-       "                     FE-CP        8\n",
-       "                     FE-H        10\n",
-       "                     FE-O         4\n",
-       "                     FE-T         6\n",
-       "model deployment     MD-CI       44\n",
-       "                     MD-LR        6\n",
-       "                     MD-O        10\n",
-       "                     MD-SM       14\n",
-       "                     ME-O         1\n",
-       "model evaluation     ME-AR       30\n",
-       "                     ME-C        29\n",
-       "                     ME-O        20\n",
-       "                     ME-RQ        8\n",
-       "                     ME-TP        4\n",
-       "model requirements   MR-AM       18\n",
-       "                     MR-FR       25\n",
-       "                     MR-NM        2\n",
-       "                     MR-O         2\n",
-       "model training       MT-BL       28\n",
-       "                     MT-GPU      19\n",
-       "                     MT-O        49\n",
-       "                     MT-RU       10\n",
-       "                     MT-TT       16\n",
-       "                     loss         6\n",
-       "dtype: int64"
-      ]
-     },
-     "execution_count": 22,
-     "metadata": {},
-     "output_type": "execute_result"
-    }
-   ],
-   "source": [
-    "data.groupby(['classification', 'L2 class']).size()"
-   ]
-  }
- ],
- "metadata": {
-  "kernelspec": {
-   "display_name": "Python 3",
-   "language": "python",
-   "name": "python3"
-  },
-  "language_info": {
-   "codemirror_mode": {
-    "name": "ipython",
-    "version": 3
-   },
-   "file_extension": ".py",
-   "mimetype": "text/x-python",
-   "name": "python",
-   "nbconvert_exporter": "python",
-   "pygments_lexer": "ipython3",
-   "version": "3.9.5"
-  }
- },
- "nbformat": 4,
- "nbformat_minor": 1
-}

util/barplot-commit.py

@@ -1,25 +0,0 @@
-import pandas as pd
-import seaborn as sns
-import matplotlib.pyplot as plt
-
-if __name__ == '__main__':
-    data = pd.read_csv('commit.csv')
-
-    data['type'] = data['is_ml'].apply(lambda x: 'ML' if x else 'No ML')
-
-    g = sns.catplot(x="type", kind="count", data=data)\
-        .set(title='Istanze dei commit in base al tipo')\
-        .set(xlabel='tipo')
-
-    ax = g.facet_axis(0, 0)
-    for p in ax.patches:
-        ax.text(
-            p.get_x() + p.get_width() * 0.39,
-            p.get_height() + 10,
-            p.get_height(),
-            color='black', rotation='horizontal', size='large')
-
-    plt.tight_layout()
-    #plt.show()
-    plt.savefig('../src/figures/count-commit.pdf')
-

util/barplot-issues-labelled.py

@@ -1,47 +0,0 @@
-import pandas as pd
-import seaborn as sns
-import matplotlib.pyplot as plt
-
-if __name__ == '__main__':
-    data = pd.read_csv('sampling_all.csv')
-
-    data['label'] = data['Classification'].apply(lambda x: x.split(';')[0].strip())
-    data = data[~data['label'].isin(['?', 'chinese', 'page not found'])]
-    data['on_pipe'] = data['label'].apply(lambda x: 'No ML' if x == 'no pipeline' else 'ML')
-
-    g = sns.catplot(x="on_pipe", kind="count", data=data)\
-        .set(title='Istanze delle issues in base al tipo')\
-        .set(xlabel='tipo')
-
-    ax = g.facet_axis(0, 0)
-    for p in ax.patches:
-        ax.text(
-            p.get_x() + p.get_width() * 0.43,
-            p.get_height() + 3,
-            p.get_height(),
-            color='black', rotation='horizontal', size='large')
-
-    plt.tight_layout()
-    plt.savefig('../src/figures/count-type.pdf')
-    #plt.show()
-
-    exit()
-    plt.close()
-
-    data = data[data['label'] != 'no pipeline']
-    g = sns.catplot(y='label', kind='count', data=data, color='green')\
-        .set(title='Istanze delle issues in base alla fase') \
-        .set(ylabel='fase')
-
-    ax = g.facet_axis(0, 0)
-    for p in ax.patches:
-        ax.text(
-            p.get_width() + 0.25,
-            p.get_y() + p.get_height() / 2,
-            p.get_width(),
-            color='black', rotation='horizontal', size='large')
-
-    plt.tight_layout()
-    plt.savefig('../src/figures/count-phases.pdf')
-
-

util/cliffsDelta.py

@@ -1,49 +0,0 @@
-from __future__ import division
-
-
-def cliffsDelta(lst1, lst2, **dull):
-
-    """Returns delta and true if there are more than 'dull' differences"""
-    if not dull:
-        dull = {'small': 0.147, 'medium': 0.33, 'large': 0.474} # effect sizes from (Hess and Kromrey, 2004)
-    m, n = len(lst1), len(lst2)
-    lst2 = sorted(lst2)
-    j = more = less = 0
-    for repeats, x in runs(sorted(lst1)):
-        while j <= (n - 1) and lst2[j] < x:
-            j += 1
-        more += j*repeats
-        while j <= (n - 1) and lst2[j] == x:
-            j += 1
-        less += (n - j)*repeats
-    d = (more - less) / (m*n)
-    size = lookup_size(d, dull)
-    return d, size
-
-
-def lookup_size(delta: float, dull: dict) -> str:
-    """
-    :type delta: float
-    :type dull: dict, a dictionary of small, medium, large thresholds.
-    """
-    delta = abs(delta)
-    if delta < dull['small']:
-        return 'negligible'
-    if dull['small'] <= delta < dull['medium']:
-        return 'small'
-    if dull['medium'] <= delta < dull['large']:
-        return 'medium'
-    if delta >= dull['large']:
-        return 'large'
-
-
-def runs(lst):
-    """Iterator, chunks repeated values"""
-    for j, two in enumerate(lst):
-        if j == 0:
-            one, i = two, 0
-        if one != two:
-            yield j - i, one
-            i = j
-        one = two
-    yield j - i + 1, two

util/count-phases-on-commit.py

@@ -1,25 +0,0 @@
-import pandas as pd
-import seaborn as sns
-import matplotlib.pyplot as plt
-
-if __name__ == '__main__':
-    data = pd.read_csv('commit_analysis.csv')
-    data.dropna(inplace=True)
-
-    x = data.groupby('phases').size().reset_index()
-
-    g = sns.catplot(y="phases", kind="count", data=data, color='green') \
-        .set(title='Istanze dei fix in base alla fase') \
-        .set(ylabel='fase')
-
-    ax = g.facet_axis(0, 0)
-    for p in ax.patches:
-        ax.text(
-            p.get_width() + 0.2,
-            p.get_y() + p.get_height() / 2,
-            p.get_width(),
-            color='black', rotation='horizontal', size='large')
-
-    plt.tight_layout()
-    plt.savefig('../src/figures/count-fix-phases.pdf')
-    #plt.show()

util/discussion.py

@@ -1,29 +0,0 @@
-import pandas as pd
-import seaborn as sns
-import matplotlib.pyplot as plt
-from scipy.stats import pearsonr
-
-if __name__ == '__main__':
-    data = pd.read_csv('commit_analysis.csv')
-
-    data['type'] = data['is_ml'].apply(lambda x: 'ML' if x else 'No ML')
-
-    ylim = data['n_comments'].quantile(0.97)
-    sns.catplot(x='type', y='n_comments', kind='box', data=data) \
-        .set(title='Commenti in base al tipo di issue') \
-        .set(xlabel='tipo') \
-        .set(ylabel='numero di commenti') \
-        .set(ylim=(0, ylim))
-    plt.tight_layout()
-    plt.savefig('../src/figures/comments.pdf')
-
-    plt.close()
-
-    ylim = data['words_mean'].quantile(0.97)
-    sns.catplot(x='type', y='words_mean', kind='box', data=data) \
-        .set(title='Parole medie in un commento') \
-        .set(xlabel='tipo') \
-        .set(ylabel='parole medie') \
-        .set(ylim=(0, ylim))
-    plt.tight_layout()
-    plt.savefig('../src/figures/words.pdf')

util/entropy.py

@@ -1,28 +0,0 @@
-import pandas as pd
-import seaborn as sns
-import matplotlib.pyplot as plt
-
-if __name__ == '__main__':
-    data = pd.read_csv('commit_analysis.csv')
-
-    data['type'] = data['is_ml'].apply(lambda x: 'ML' if x else 'No ML')
-
-    ylim = data['file_entropy'].quantile(0.95)
-    sns.catplot(x='type', y='file_entropy', kind='box', data=data) \
-        .set(title='Entropia del cambiamento calcolata sui file') \
-        .set(xlabel='tipo') \
-        .set(ylabel='entropia') \
-        .set(ylim=(0, ylim))
-    plt.tight_layout()
-    plt.savefig('../src/figures/files-entropy.pdf')
-
-    plt.close()
-
-    ylim = data['line_entropy'].quantile(0.95)
-    sns.catplot(x='type', y='line_entropy', kind='box', data=data) \
-        .set(title='Entropia del cambiamento calcolata sulle linee') \
-        .set(xlabel='tipo') \
-        .set(ylabel='entropia') \
-        .set(ylim=(0, ylim))
-    plt.tight_layout()
-    plt.savefig('../src/figures/lines-entropy.pdf')

util/files-and-dirs.py

@@ -1,35 +0,0 @@
-import pandas as pd
-import seaborn as sns
-import matplotlib.pyplot as plt
-
-if __name__ == '__main__':
-    data = pd.read_csv('commit_files.csv')
-
-    help_df = pd.DataFrame(columns=['project', 'tipo', 'files/dirs', 'value'])
-
-    for i, row in data.iterrows():
-        project = row['project']
-
-        help_df = help_df.append(
-            {'project': project, 'tipo': 'No ML', 'files/dirs': 'Files', 'value': row['no_ml_files_ratio']},
-            ignore_index=True
-        )
-        help_df = help_df.append(
-            {'project': project, 'tipo': 'ML', 'files/dirs': 'Files', 'value': row['ml_files_ratio']},
-            ignore_index=True
-        )
-        help_df = help_df.append(
-            {'project': project, 'tipo': 'No ML', 'files/dirs': 'Directories', 'value': row['no_ml_dirs_ratio']},
-            ignore_index=True
-        )
-        help_df = help_df.append(
-            {'project': project, 'tipo': 'ML', 'files/dirs': 'Directories', 'value': row['ml_dirs_ratio']},
-            ignore_index=True
-        )
-
-    plot = sns.boxplot(x='files/dirs', y='value', hue='tipo', data=help_df)
-    plot.set_title('Percentuali di files e directories modificate')
-    plot.set_ylabel('')
-
-    plt.tight_layout()
-    plt.savefig('../src/figures/files-and-directories.pdf')

util/import.py

@@ -1,44 +0,0 @@
-import pandas as pd
-import seaborn as sns
-import matplotlib.pyplot as plt
-
-
-def get(project, series) -> int:
-    try:
-        return series[(project, True)]
-    except Exception:
-        return 0
-
-
-if __name__ == '__main__':
-    data = pd.read_csv('imports_data.csv')
-
-    total_files = data.groupby('project').size()
-    ml = data.groupby(['project', 'is_ml']).size()
-    ml_strict = data.groupby(['project', 'is_ml_strict']).size()
-
-    help_df = pd.DataFrame(columns=['project', 'type', 'value'])
-
-    for project in data['project'].unique():
-        tot_files = total_files[project]
-
-        help_df = help_df.append(
-            {'project': project, 'type': 'all', 'value': get(project, ml)/tot_files},
-            ignore_index=True
-        )
-        help_df = help_df.append(
-            {'project': project, 'type': 'wo_pandas_numpy_scipy', 'value': get(project, ml_strict) / tot_files},
-            ignore_index=True
-        )
-
-    colors = ['#cab2d6', '#6a3d9a']
-    sns.set_palette(sns.color_palette(colors))
-
-    sns.catplot(x='type', y='value', kind='box', data=help_df)\
-        .set(title='Percentuale di file con import di ML') \
-        .set(xlabel='Librerie ML') \
-        .set(ylabel='')
-    plt.tight_layout()
-    plt.savefig('../src/figures/imports.pdf')
-    #plt.show()
-

util/l2.ipynb

@@ -1,126 +0,0 @@
-{
- "cells": [
-  {
-   "cell_type": "code",
-   "execution_count": 21,
-   "metadata": {
-    "collapsed": true
-   },
-   "outputs": [
-    {
-     "data": {
-      "text/plain": [
-       "model training         128\n",
-       "model evaluation        91\n",
-       "model deployment        75\n",
-       "data cleaning           59\n",
-       "model requirements      47\n",
-       "feature engineering     36\n",
-       "data collection         25\n",
-       "Name: classification, dtype: int64"
-      ]
-     },
-     "execution_count": 21,
-     "metadata": {},
-     "output_type": "execute_result"
-    }
-   ],
-   "source": [
-    "import pandas as pd\n",
-    "\n",
-    "data = pd.read_csv('sampling_nb - sampling_nb.csv')\n",
-    "\n",
-    "data.drop(['second', 'url'], inplace=True, axis=1)\n",
-    "\n",
-    "data = data[~data['classification'].isin(['?', '', 'no pipeline', 'page not found', 'chinese', 'data labeling'])]\n",
-    "\n",
-    "data['classification'].value_counts()"
-   ]
-  },
-  {
-   "cell_type": "code",
-   "execution_count": 22,
-   "metadata": {
-    "pycharm": {
-     "name": "#%%\n"
-    }
-   },
-   "outputs": [
-    {
-     "data": {
-      "text/plain": [
-       "classification       L2 class\n",
-       "data cleaning        DP-DF        8\n",
-       "                     DP-LD        1\n",
-       "                     DP-O        17\n",
-       "                     DP-P         3\n",
-       "                     DP-R        13\n",
-       "                     DP-TE        9\n",
-       "                     DP-TM        2\n",
-       "                     DP-UT        6\n",
-       "data collection      DC-DC       13\n",
-       "                     DC-DF        4\n",
-       "                     DC-F         3\n",
-       "                     DC-NS        1\n",
-       "                     DC-O         1\n",
-       "                     DC-S         3\n",
-       "feature engineering  FE-BC        8\n",
-       "                     FE-CP        8\n",
-       "                     FE-H        10\n",
-       "                     FE-O         4\n",
-       "                     FE-T         6\n",
-       "model deployment     MD-CI       44\n",
-       "                     MD-LR        6\n",
-       "                     MD-O        10\n",
-       "                     MD-SM       14\n",
-       "                     ME-O         1\n",
-       "model evaluation     ME-AR       30\n",
-       "                     ME-C        29\n",
-       "                     ME-O        20\n",
-       "                     ME-RQ        8\n",
-       "                     ME-TP        4\n",
-       "model requirements   MR-AM       18\n",
-       "                     MR-FR       25\n",
-       "                     MR-NM        2\n",
-       "                     MR-O         2\n",
-       "model training       MT-BL       28\n",
-       "                     MT-GPU      19\n",
-       "                     MT-O        49\n",
-       "                     MT-RU       10\n",
-       "                     MT-TT       16\n",
-       "                     loss         6\n",
-       "dtype: int64"
-      ]
-     },
-     "execution_count": 22,
-     "metadata": {},
-     "output_type": "execute_result"
-    }
-   ],
-   "source": [
-    "data.groupby(['classification', 'L2 class']).size()"
-   ]
-  }
- ],
- "metadata": {
-  "kernelspec": {
-   "display_name": "Python 3",
-   "language": "python",
-   "name": "python3"
-  },
-  "language_info": {
-   "codemirror_mode": {
-    "name": "ipython",
-    "version": 3
-   },
-   "file_extension": ".py",
-   "mimetype": "text/x-python",
-   "name": "python",
-   "nbconvert_exporter": "python",
-   "pygments_lexer": "ipython3",
-   "version": "3.9.5"
-  }
- },
- "nbformat": 4,
- "nbformat_minor": 1
-}

util/sampling_all.csv

@@ -1,376 +0,0 @@
-Project,Issue,Url,Labels,Classification,Is ML
-davidsandberg/facenet,951,https://github.com/davidsandberg/facenet/issues/951,,no pipeline,False
-deepfakes/faceswap,964,https://github.com/deepfakes/faceswap/issues/964,,no pipeline,False
-junyanz/pytorch-CycleGAN-and-pix2pix,968,https://github.com/junyanz/pytorch-CycleGAN-and-pix2pix/issues/968,,no pipeline,True
-Tianxiaomo/pytorch-YOLOv4,136,https://github.com/Tianxiaomo/pytorch-YOLOv4/pull/136,,model evaluation,True
-mittagessen/kraken,146,https://github.com/mittagessen/kraken/issues/146,,no pipeline,False
-1adrianb/face-alignment,148,https://github.com/1adrianb/face-alignment/issues/148,,no pipeline,False
-Linzaer/Ultra-Light-Fast-Generic-Face-Detector-1MB,82,https://github.com/Linzaer/Ultra-Light-Fast-Generic-Face-Detector-1MB/issues/82,,model requirements,False
-suragnair/alpha-zero-general,175,https://github.com/suragnair/alpha-zero-general/issues/175,,feature engineering;model training,True
-deepfakes/faceswap,176,https://github.com/deepfakes/faceswap/issues/176,,no pipeline,True
-BrikerMan/Kashgari,88,https://github.com/BrikerMan/Kashgari/issues/88,question,model requirements,True
-BrikerMan/Kashgari,374,https://github.com/BrikerMan/Kashgari/pull/374,,model deployment,False
-deepfakes/faceswap,443,https://github.com/deepfakes/faceswap/pull/443,,no pipeline,False
-hanxiao/bert-as-service,561,https://github.com/hanxiao/bert-as-service/issues/561,,no pipeline,True
-jhpyle/docassemble,325,https://github.com/jhpyle/docassemble/issues/325,,no pipeline,False
-1adrianb/face-alignment,111,https://github.com/1adrianb/face-alignment/issues/111,,no pipeline,True
-deepfakes/faceswap,7,https://github.com/deepfakes/faceswap/issues/7,dev;opencv,data cleaning,True
-jrkerns/pylinac,67,https://github.com/jrkerns/pylinac/pull/67,,no pipeline,True
-nextgenusfs/funannotate,180,https://github.com/nextgenusfs/funannotate/issues/180,,data cleaning,False
-gboeing/osmnx,515,https://github.com/gboeing/osmnx/issues/515,,no pipeline,False
-thtrieu/darkflow,876,https://github.com/thtrieu/darkflow/issues/876,,model training,True
-regel/loudml,544,https://github.com/regel/loudml/issues/544,,no pipeline,False
-davidsandberg/facenet,786,https://github.com/davidsandberg/facenet/issues/786,,no pipeline,False
-davidsandberg/facenet,772,https://github.com/davidsandberg/facenet/issues/772,,feature engineering;model training;data collection,True
-tianzhi0549/FCOS,230,https://github.com/tianzhi0549/FCOS/issues/230,,feature engineering;model training,True
-regel/loudml,370,https://github.com/regel/loudml/issues/370,,model deployment,False
-deepfakes/faceswap,431,https://github.com/deepfakes/faceswap/pull/431,,no pipeline,True
-regel/loudml,334,https://github.com/regel/loudml/pull/334,dependencies,no pipeline,False
-emedvedev/attention-ocr,143,https://github.com/emedvedev/attention-ocr/issues/143,,no pipeline,True
-nextgenusfs/funannotate,290,https://github.com/nextgenusfs/funannotate/issues/290,,data cleaning,True
-thtrieu/darkflow,1193,https://github.com/thtrieu/darkflow/issues/1193,,no pipeline,False
-thtrieu/darkflow,332,https://github.com/thtrieu/darkflow/pull/332,,model requirements;model training,True
-suragnair/alpha-zero-general,177,https://github.com/suragnair/alpha-zero-general/pull/177,,no pipeline,True
-dpinney/omf,345,https://github.com/dpinney/omf/pull/345,,no pipeline,False
-thtrieu/darkflow,1081,https://github.com/thtrieu/darkflow/issues/1081,,no pipeline,False
-thtrieu/darkflow,330,https://github.com/thtrieu/darkflow/issues/330,,model training,True
-Tianxiaomo/pytorch-YOLOv4,129,https://github.com/Tianxiaomo/pytorch-YOLOv4/issues/129,,chinese,False
-nicodv/kmodes,105,https://github.com/nicodv/kmodes/issues/105,,data collection,False
-deepfakes/faceswap,273,https://github.com/deepfakes/faceswap/issues/273,,data cleaning,False
-tianzhi0549/FCOS,287,https://github.com/tianzhi0549/FCOS/issues/287,,model evaluation,True
-Tianxiaomo/pytorch-YOLOv4,162,https://github.com/Tianxiaomo/pytorch-YOLOv4/issues/162,,no pipeline,False
-junyanz/pytorch-CycleGAN-and-pix2pix,2,https://github.com/junyanz/pytorch-CycleGAN-and-pix2pix/issues/2,,no pipeline,True
-davidsandberg/facenet,997,https://github.com/davidsandberg/facenet/issues/997,,no pipeline,False
-hanxiao/bert-as-service,350,https://github.com/hanxiao/bert-as-service/issues/350,,model deployment,False
-hanxiao/bert-as-service,157,https://github.com/hanxiao/bert-as-service/pull/157,,no pipeline,False
-junyanz/pytorch-CycleGAN-and-pix2pix,761,https://github.com/junyanz/pytorch-CycleGAN-and-pix2pix/issues/761,,model training;data cleaning,False
-dpinney/omf,218,https://github.com/dpinney/omf/issues/218,,no pipeline,False
-CamDavidsonPilon/lifelines,177,https://github.com/CamDavidsonPilon/lifelines/pull/177,,no pipeline,False
-junyanz/pytorch-CycleGAN-and-pix2pix,641,https://github.com/junyanz/pytorch-CycleGAN-and-pix2pix/issues/641,,no pipeline,False
-junyanz/pytorch-CycleGAN-and-pix2pix,360,https://github.com/junyanz/pytorch-CycleGAN-and-pix2pix/issues/360,,no pipeline,True
-SeanNaren/deepspeech.pytorch,5,https://github.com/SeanNaren/deepspeech.pytorch/pull/5,,no pipeline,False
-regel/loudml,82,https://github.com/regel/loudml/pull/82,,no pipeline,False
-gboeing/osmnx,156,https://github.com/gboeing/osmnx/issues/156,,no pipeline,True
-SeanNaren/deepspeech.pytorch,275,https://github.com/SeanNaren/deepspeech.pytorch/issues/275,stale,no pipeline,False
-junyanz/pytorch-CycleGAN-and-pix2pix,949,https://github.com/junyanz/pytorch-CycleGAN-and-pix2pix/issues/949,,model evaluation,False
-davidsandberg/facenet,206,https://github.com/davidsandberg/facenet/issues/206,,model training;data cleaning,True
-davidsandberg/facenet,683,https://github.com/davidsandberg/facenet/issues/683,,no pipeline,False
-thtrieu/darkflow,938,https://github.com/thtrieu/darkflow/issues/938,,no pipeline,False
-CamDavidsonPilon/lifelines,764,https://github.com/CamDavidsonPilon/lifelines/issues/764,next minor release 🤞,no pipeline,False
-Linzaer/Ultra-Light-Fast-Generic-Face-Detector-1MB,47,https://github.com/Linzaer/Ultra-Light-Fast-Generic-Face-Detector-1MB/issues/47,,chinese,True
-emedvedev/attention-ocr,171,https://github.com/emedvedev/attention-ocr/issues/171,,no pipeline,True
-deepfakes/faceswap,818,https://github.com/deepfakes/faceswap/pull/818,,no pipeline,False
-deepfakes/faceswap,123,https://github.com/deepfakes/faceswap/issues/123,code to integrate,model requirements;data cleaning,True
-SeanNaren/deepspeech.pytorch,420,https://github.com/SeanNaren/deepspeech.pytorch/issues/420,,data cleaning,True
-deeppomf/DeepCreamPy,16,https://github.com/deeppomf/DeepCreamPy/issues/16,,page not found,False
-thtrieu/darkflow,431,https://github.com/thtrieu/darkflow/issues/431,,feature engineering;model training,True
-ljvmiranda921/pyswarms,384,https://github.com/ljvmiranda921/pyswarms/pull/384,,no pipeline,True
-thtrieu/darkflow,234,https://github.com/thtrieu/darkflow/issues/234,,no pipeline,True
-CamDavidsonPilon/lifelines,320,https://github.com/CamDavidsonPilon/lifelines/pull/320,,no pipeline,False
-jantic/DeOldify,237,https://github.com/jantic/DeOldify/issues/237,,no pipeline,False
-thtrieu/darkflow,424,https://github.com/thtrieu/darkflow/issues/424,,no pipeline,False
-1adrianb/face-alignment,78,https://github.com/1adrianb/face-alignment/issues/78,invalid,no pipeline,False
-jantic/DeOldify,265,https://github.com/jantic/DeOldify/issues/265,,no pipeline,True
-junyanz/pytorch-CycleGAN-and-pix2pix,265,https://github.com/junyanz/pytorch-CycleGAN-and-pix2pix/pull/265,,no pipeline,False
-robertmartin8/PyPortfolioOpt,18,https://github.com/robertmartin8/PyPortfolioOpt/issues/18,,no pipeline,False
-ZQPei/deep_sort_pytorch,124,https://github.com/ZQPei/deep_sort_pytorch/issues/124,,no pipeline,False
-junyanz/pytorch-CycleGAN-and-pix2pix,956,https://github.com/junyanz/pytorch-CycleGAN-and-pix2pix/issues/956,,no pipeline,False
-nextgenusfs/funannotate,237,https://github.com/nextgenusfs/funannotate/issues/237,,no pipeline,True
-hanxiao/bert-as-service,242,https://github.com/hanxiao/bert-as-service/issues/242,,no pipeline,False
-CamDavidsonPilon/lifelines,867,https://github.com/CamDavidsonPilon/lifelines/issues/867,enhancement,no pipeline,False
-afeinstein20/eleanor,27,https://github.com/afeinstein20/eleanor/pull/27,,no pipeline,False
-davidsandberg/facenet,891,https://github.com/davidsandberg/facenet/issues/891,,feature engineering;model training,True
-jdb78/pytorch-forecasting,327,https://github.com/jdb78/pytorch-forecasting/pull/327,documentation,no pipeline,False
-tianzhi0549/FCOS,64,https://github.com/tianzhi0549/FCOS/pull/64,,no pipeline,False
-CamDavidsonPilon/lifelines,944,https://github.com/CamDavidsonPilon/lifelines/pull/944,,no pipeline,False
-thtrieu/darkflow,889,https://github.com/thtrieu/darkflow/issues/889,,feature engineering;model training,True
-SeanNaren/deepspeech.pytorch,345,https://github.com/SeanNaren/deepspeech.pytorch/pull/345,,no pipeline,False
-namisan/mt-dnn,105,https://github.com/namisan/mt-dnn/pull/105,,no pipeline,False
-BrikerMan/Kashgari,308,https://github.com/BrikerMan/Kashgari/pull/308,,no pipeline,False
-mittagessen/kraken,95,https://github.com/mittagessen/kraken/issues/95,,no pipeline,False
-deepfakes/faceswap,221,https://github.com/deepfakes/faceswap/issues/221,,model requirements,True
-gboeing/osmnx,169,https://github.com/gboeing/osmnx/issues/169,question,no pipeline,True
-ljvmiranda921/pyswarms,431,https://github.com/ljvmiranda921/pyswarms/pull/431,,no pipeline,False
-junyanz/pytorch-CycleGAN-and-pix2pix,425,https://github.com/junyanz/pytorch-CycleGAN-and-pix2pix/issues/425,,no pipeline,False
-mravanelli/pytorch-kaldi,120,https://github.com/mravanelli/pytorch-kaldi/issues/120,,model requirements;data cleaning,True
-CamDavidsonPilon/lifelines,1059,https://github.com/CamDavidsonPilon/lifelines/issues/1059,docs,no pipeline,False
-nextgenusfs/funannotate,158,https://github.com/nextgenusfs/funannotate/issues/158,,no pipeline,False
-BrikerMan/Kashgari,342,https://github.com/BrikerMan/Kashgari/issues/342,wontfix,no pipeline,False
-davidsandberg/facenet,440,https://github.com/davidsandberg/facenet/issues/440,,no pipeline,False
-namisan/mt-dnn,91,https://github.com/namisan/mt-dnn/issues/91,,no pipeline,False
-CamDavidsonPilon/lifelines,515,https://github.com/CamDavidsonPilon/lifelines/issues/515,docs,no pipeline,False
-deeppomf/DeepCreamPy,226,https://github.com/deeppomf/DeepCreamPy/issues/226,,page not found,False
-CamDavidsonPilon/lifelines,391,https://github.com/CamDavidsonPilon/lifelines/issues/391,enhancement;next minor release 🤞,no pipeline,False
-davidsandberg/facenet,813,https://github.com/davidsandberg/facenet/issues/813,,model requirements,True
-nicodv/kmodes,23,https://github.com/nicodv/kmodes/issues/23,bug,no pipeline,False
-ljvmiranda921/pyswarms,427,https://github.com/ljvmiranda921/pyswarms/issues/427,,model training,True
-jdb78/pytorch-forecasting,163,https://github.com/jdb78/pytorch-forecasting/issues/163,question,model deployment,True
-junyanz/pytorch-CycleGAN-and-pix2pix,206,https://github.com/junyanz/pytorch-CycleGAN-and-pix2pix/issues/206,,data collection;model training,True
-junyanz/pytorch-CycleGAN-and-pix2pix,601,https://github.com/junyanz/pytorch-CycleGAN-and-pix2pix/issues/601,,no pipeline,True
-Tianxiaomo/pytorch-YOLOv4,119,https://github.com/Tianxiaomo/pytorch-YOLOv4/issues/119,,no pipeline,True
-hanxiao/bert-as-service,513,https://github.com/hanxiao/bert-as-service/issues/513,,no pipeline,False
-Tianxiaomo/pytorch-YOLOv4,275,https://github.com/Tianxiaomo/pytorch-YOLOv4/issues/275,,model training,True
-regel/loudml,37,https://github.com/regel/loudml/issues/37,,no pipeline,True
-SeanNaren/deepspeech.pytorch,522,https://github.com/SeanNaren/deepspeech.pytorch/pull/522,,model training,True
-BrikerMan/Kashgari,254,https://github.com/BrikerMan/Kashgari/pull/254,,no pipeline,False
-deepfakes/faceswap,491,https://github.com/deepfakes/faceswap/issues/491,feature;feedback wanted,data cleaning,False
-junyanz/pytorch-CycleGAN-and-pix2pix,1156,https://github.com/junyanz/pytorch-CycleGAN-and-pix2pix/issues/1156,,data cleaning;model training,True
-CamDavidsonPilon/lifelines,804,https://github.com/CamDavidsonPilon/lifelines/issues/804,docs,no pipeline,False
-junyanz/pytorch-CycleGAN-and-pix2pix,798,https://github.com/junyanz/pytorch-CycleGAN-and-pix2pix/issues/798,,no pipeline,False
-suragnair/alpha-zero-general,8,https://github.com/suragnair/alpha-zero-general/pull/8,,no pipeline,True
-regel/loudml,163,https://github.com/regel/loudml/issues/163,,no pipeline,False
-hanxiao/bert-as-service,337,https://github.com/hanxiao/bert-as-service/issues/337,,no pipeline,False
-robertmartin8/PyPortfolioOpt,169,https://github.com/robertmartin8/PyPortfolioOpt/pull/169,,no pipeline,False
-jdb78/pytorch-forecasting,394,https://github.com/jdb78/pytorch-forecasting/pull/394,,no pipeline,False
-davidsandberg/facenet,1166,https://github.com/davidsandberg/facenet/issues/1166,,model deployment,False
-CamDavidsonPilon/lifelines,318,https://github.com/CamDavidsonPilon/lifelines/pull/318,,no pipeline,False
-jantic/DeOldify,278,https://github.com/jantic/DeOldify/issues/278,,no pipeline,False
-deepfakes/faceswap,457,https://github.com/deepfakes/faceswap/pull/457,,no pipeline,False
-CamDavidsonPilon/lifelines,594,https://github.com/CamDavidsonPilon/lifelines/pull/594,,no pipeline,False
-jrkerns/pylinac,89,https://github.com/jrkerns/pylinac/issues/89,,no pipeline,False
-ljvmiranda921/pyswarms,292,https://github.com/ljvmiranda921/pyswarms/issues/292,,no pipeline,False
-CamDavidsonPilon/lifelines,919,https://github.com/CamDavidsonPilon/lifelines/pull/919,,no pipeline,False
-Tianxiaomo/pytorch-YOLOv4,178,https://github.com/Tianxiaomo/pytorch-YOLOv4/issues/178,,no pipeline,True
-robertmartin8/PyPortfolioOpt,294,https://github.com/robertmartin8/PyPortfolioOpt/issues/294,bug,no pipeline,False
-BrikerMan/Kashgari,350,https://github.com/BrikerMan/Kashgari/pull/350,,model requirements,True
-junyanz/pytorch-CycleGAN-and-pix2pix,27,https://github.com/junyanz/pytorch-CycleGAN-and-pix2pix/issues/27,,feature engineering,True
-junyanz/pytorch-CycleGAN-and-pix2pix,1046,https://github.com/junyanz/pytorch-CycleGAN-and-pix2pix/issues/1046,,feature engineering;model training,False
-jrkerns/pylinac,267,https://github.com/jrkerns/pylinac/issues/267,,no pipeline,False
-SeanNaren/deepspeech.pytorch,80,https://github.com/SeanNaren/deepspeech.pytorch/pull/80,,model deployment,True
-dpinney/omf,235,https://github.com/dpinney/omf/issues/235,PNNL,no pipeline,True
-thtrieu/darkflow,538,https://github.com/thtrieu/darkflow/issues/538,,model training,True
-ljvmiranda921/pyswarms,12,https://github.com/ljvmiranda921/pyswarms/pull/12,,no pipeline,False
-regel/loudml,36,https://github.com/regel/loudml/issues/36,,no pipeline,True
-deepfakes/faceswap,639,https://github.com/deepfakes/faceswap/issues/639,,model training,True
-junyanz/pytorch-CycleGAN-and-pix2pix,305,https://github.com/junyanz/pytorch-CycleGAN-and-pix2pix/issues/305,,model training,True
-junyanz/pytorch-CycleGAN-and-pix2pix,1234,https://github.com/junyanz/pytorch-CycleGAN-and-pix2pix/issues/1234,,model training;data collection,False
-ZQPei/deep_sort_pytorch,67,https://github.com/ZQPei/deep_sort_pytorch/issues/67,,no pipeline,False
-thtrieu/darkflow,1189,https://github.com/thtrieu/darkflow/issues/1189,,model training,True
-thtrieu/darkflow,771,https://github.com/thtrieu/darkflow/issues/771,,model training,True
-CamDavidsonPilon/lifelines,619,https://github.com/CamDavidsonPilon/lifelines/issues/619,docs;enhancement,no pipeline,False
-jantic/DeOldify,298,https://github.com/jantic/DeOldify/issues/298,,no pipeline,False
-junyanz/pytorch-CycleGAN-and-pix2pix,915,https://github.com/junyanz/pytorch-CycleGAN-and-pix2pix/issues/915,,no pipeline,False
-BrikerMan/Kashgari,339,https://github.com/BrikerMan/Kashgari/issues/339,question,chinese,False
-Linzaer/Ultra-Light-Fast-Generic-Face-Detector-1MB,18,https://github.com/Linzaer/Ultra-Light-Fast-Generic-Face-Detector-1MB/issues/18,,no pipeline,False
-deepfakes/faceswap,169,https://github.com/deepfakes/faceswap/issues/169,,no pipeline,True
-jhpyle/docassemble,23,https://github.com/jhpyle/docassemble/issues/23,,no pipeline,False
-tianzhi0549/FCOS,107,https://github.com/tianzhi0549/FCOS/issues/107,,no pipeline,False
-jantic/DeOldify,250,https://github.com/jantic/DeOldify/issues/250,,no pipeline,False
-Tianxiaomo/pytorch-YOLOv4,223,https://github.com/Tianxiaomo/pytorch-YOLOv4/issues/223,,?,True
-junyanz/pytorch-CycleGAN-and-pix2pix,73,https://github.com/junyanz/pytorch-CycleGAN-and-pix2pix/issues/73,,no pipeline,False
-BrikerMan/Kashgari,62,https://github.com/BrikerMan/Kashgari/issues/62,question,chinese,False
-robertmartin8/PyPortfolioOpt,158,https://github.com/robertmartin8/PyPortfolioOpt/issues/158,enhancement,no pipeline,False
-CamDavidsonPilon/lifelines,357,https://github.com/CamDavidsonPilon/lifelines/pull/357,,no pipeline,False
-Tianxiaomo/pytorch-YOLOv4,249,https://github.com/Tianxiaomo/pytorch-YOLOv4/issues/249,,no pipeline,True
-SeanNaren/deepspeech.pytorch,197,https://github.com/SeanNaren/deepspeech.pytorch/issues/197,,no pipeline,True
-deepfakes/faceswap,90,https://github.com/deepfakes/faceswap/pull/90,,no pipeline,False
-thtrieu/darkflow,466,https://github.com/thtrieu/darkflow/issues/466,,model training,True
-junyanz/pytorch-CycleGAN-and-pix2pix,675,https://github.com/junyanz/pytorch-CycleGAN-and-pix2pix/issues/675,,no pipeline,False
-davidsandberg/facenet,417,https://github.com/davidsandberg/facenet/issues/417,,model evaluation,True
-gboeing/osmnx,601,https://github.com/gboeing/osmnx/issues/601,question,no pipeline,False
-regel/loudml,95,https://github.com/regel/loudml/issues/95,help wanted,no pipeline,False
-davidsandberg/facenet,480,https://github.com/davidsandberg/facenet/issues/480,,model deployment,False
-davidsandberg/facenet,175,https://github.com/davidsandberg/facenet/issues/175,,model training;data cleaning,True
-robertmartin8/PyPortfolioOpt,58,https://github.com/robertmartin8/PyPortfolioOpt/pull/58,,no pipeline,False
-nextgenusfs/funannotate,119,https://github.com/nextgenusfs/funannotate/pull/119,,no pipeline,False
-CamDavidsonPilon/lifelines,1186,https://github.com/CamDavidsonPilon/lifelines/issues/1186,,no pipeline,True
-deeppomf/DeepCreamPy,118,https://github.com/deeppomf/DeepCreamPy/issues/118,,page not found,True
-hanxiao/bert-as-service,203,https://github.com/hanxiao/bert-as-service/pull/203,,no pipeline,False
-junyanz/pytorch-CycleGAN-and-pix2pix,839,https://github.com/junyanz/pytorch-CycleGAN-and-pix2pix/issues/839,,no pipeline,False
-hanxiao/bert-as-service,236,https://github.com/hanxiao/bert-as-service/pull/236,,no pipeline,False
-CamDavidsonPilon/lifelines,1025,https://github.com/CamDavidsonPilon/lifelines/issues/1025,enhancement,no pipeline,False
-deeppomf/DeepCreamPy,32,https://github.com/deeppomf/DeepCreamPy/issues/32,,page not found,False
-jrkerns/pylinac,104,https://github.com/jrkerns/pylinac/issues/104,,no pipeline,False
-davidsandberg/facenet,1086,https://github.com/davidsandberg/facenet/issues/1086,,no pipeline,True
-deepfakes/faceswap,580,https://github.com/deepfakes/faceswap/issues/580,,no pipeline,False
-nextgenusfs/funannotate,326,https://github.com/nextgenusfs/funannotate/issues/326,,model training,True
-nextgenusfs/funannotate,215,https://github.com/nextgenusfs/funannotate/issues/215,,no pipeline,True
-regel/loudml,388,https://github.com/regel/loudml/issues/388,,no pipeline,True
-regel/loudml,137,https://github.com/regel/loudml/issues/137,CentOS,no pipeline,False
-davidsandberg/facenet,1087,https://github.com/davidsandberg/facenet/issues/1087,,model evaluation,True
-CamDavidsonPilon/lifelines,1197,https://github.com/CamDavidsonPilon/lifelines/pull/1197,,no pipeline,False
-hanxiao/bert-as-service,257,https://github.com/hanxiao/bert-as-service/issues/257,,no pipeline,False
-SeanNaren/deepspeech.pytorch,282,https://github.com/SeanNaren/deepspeech.pytorch/issues/282,stale,model evaluation,True
-davidsandberg/facenet,171,https://github.com/davidsandberg/facenet/issues/171,,no pipeline,False
-SeanNaren/deepspeech.pytorch,391,https://github.com/SeanNaren/deepspeech.pytorch/pull/391,stale,no pipeline,False
-emedvedev/attention-ocr,85,https://github.com/emedvedev/attention-ocr/issues/85,,feature engineering,True
-jrkerns/pylinac,47,https://github.com/jrkerns/pylinac/issues/47,,no pipeline,True
-Tianxiaomo/pytorch-YOLOv4,74,https://github.com/Tianxiaomo/pytorch-YOLOv4/issues/74,,chinese,True
-davidsandberg/facenet,902,https://github.com/davidsandberg/facenet/issues/902,,model deployment,True
-afeinstein20/eleanor,130,https://github.com/afeinstein20/eleanor/issues/130,,no pipeline,False
-davidsandberg/facenet,848,https://github.com/davidsandberg/facenet/pull/848,,no pipeline,False
-mittagessen/kraken,239,https://github.com/mittagessen/kraken/issues/239,,feature engineering,True
-afeinstein20/eleanor,57,https://github.com/afeinstein20/eleanor/issues/57,,no pipeline,False
-gboeing/osmnx,201,https://github.com/gboeing/osmnx/issues/201,installation,no pipeline,False
-suragnair/alpha-zero-general,132,https://github.com/suragnair/alpha-zero-general/pull/132,,no pipeline,False
-CamDavidsonPilon/lifelines,630,https://github.com/CamDavidsonPilon/lifelines/issues/630,,feature engineering,False
-regel/loudml,301,https://github.com/regel/loudml/pull/301,dependencies,no pipeline,False
-jantic/DeOldify,99,https://github.com/jantic/DeOldify/pull/99,,no pipeline,False
-thtrieu/darkflow,950,https://github.com/thtrieu/darkflow/issues/950,,model training,True
-deepfakes/faceswap,756,https://github.com/deepfakes/faceswap/pull/756,,no pipeline,True
-davidsandberg/facenet,890,https://github.com/davidsandberg/facenet/issues/890,,model training,True
-mittagessen/kraken,156,https://github.com/mittagessen/kraken/issues/156,,no pipeline,False
-ljvmiranda921/pyswarms,378,https://github.com/ljvmiranda921/pyswarms/pull/378,,no pipeline,False
-davidsandberg/facenet,105,https://github.com/davidsandberg/facenet/issues/105,,model training,True
-davidsandberg/facenet,612,https://github.com/davidsandberg/facenet/issues/612,,no pipeline,True
-CamDavidsonPilon/lifelines,881,https://github.com/CamDavidsonPilon/lifelines/issues/881,,no pipeline,False
-junyanz/pytorch-CycleGAN-and-pix2pix,158,https://github.com/junyanz/pytorch-CycleGAN-and-pix2pix/issues/158,,no pipeline,True
-gboeing/osmnx,623,https://github.com/gboeing/osmnx/issues/623,bug,no pipeline,False
-suragnair/alpha-zero-general,37,https://github.com/suragnair/alpha-zero-general/issues/37,,no pipeline,True
-ljvmiranda921/pyswarms,440,https://github.com/ljvmiranda921/pyswarms/pull/440,,no pipeline,True
-deepfakes/faceswap,38,https://github.com/deepfakes/faceswap/issues/38,bug;performance,no pipeline,False
-suragnair/alpha-zero-general,217,https://github.com/suragnair/alpha-zero-general/issues/217,,no pipeline,False
-jrkerns/pylinac,281,https://github.com/jrkerns/pylinac/pull/281,,no pipeline,False
-1adrianb/face-alignment,230,https://github.com/1adrianb/face-alignment/pull/230,,no pipeline,False
-mittagessen/kraken,30,https://github.com/mittagessen/kraken/issues/30,,no pipeline,True
-davidsandberg/facenet,398,https://github.com/davidsandberg/facenet/issues/398,,model evaluation,False
-SeanNaren/deepspeech.pytorch,152,https://github.com/SeanNaren/deepspeech.pytorch/pull/152,,no pipeline,False
-tianzhi0549/FCOS,49,https://github.com/tianzhi0549/FCOS/issues/49,,no pipeline,True
-BrikerMan/Kashgari,218,https://github.com/BrikerMan/Kashgari/issues/218,question,chinese,True
-mravanelli/pytorch-kaldi,54,https://github.com/mravanelli/pytorch-kaldi/issues/54,,model training;model deployment,True
-jdb78/pytorch-forecasting,227,https://github.com/jdb78/pytorch-forecasting/pull/227,dependencies,no pipeline,False
-junyanz/pytorch-CycleGAN-and-pix2pix,598,https://github.com/junyanz/pytorch-CycleGAN-and-pix2pix/pull/598,,no pipeline,True
-gboeing/osmnx,592,https://github.com/gboeing/osmnx/pull/592,,no pipeline,False
-deepfakes/faceswap,567,https://github.com/deepfakes/faceswap/issues/567,,no pipeline,False
-mravanelli/pytorch-kaldi,223,https://github.com/mravanelli/pytorch-kaldi/issues/223,stalled,feature engineering,True
-nextgenusfs/funannotate,327,https://github.com/nextgenusfs/funannotate/issues/327,,no pipeline,True
-SeanNaren/deepspeech.pytorch,561,https://github.com/SeanNaren/deepspeech.pytorch/issues/561,stale,no pipeline,False
-thtrieu/darkflow,512,https://github.com/thtrieu/darkflow/issues/512,,model evaluation,True
-nextgenusfs/funannotate,409,https://github.com/nextgenusfs/funannotate/issues/409,,model training,True
-tianzhi0549/FCOS,285,https://github.com/tianzhi0549/FCOS/issues/285,,model evaluation,True
-junyanz/pytorch-CycleGAN-and-pix2pix,482,https://github.com/junyanz/pytorch-CycleGAN-and-pix2pix/pull/482,,no pipeline,False
-Tianxiaomo/pytorch-YOLOv4,15,https://github.com/Tianxiaomo/pytorch-YOLOv4/issues/15,,chinese,False
-thtrieu/darkflow,1047,https://github.com/thtrieu/darkflow/issues/1047,,no pipeline,False
-gboeing/osmnx,206,https://github.com/gboeing/osmnx/pull/206,,no pipeline,False
-jrkerns/pylinac,185,https://github.com/jrkerns/pylinac/issues/185,,no pipeline,False
-junyanz/pytorch-CycleGAN-and-pix2pix,1187,https://github.com/junyanz/pytorch-CycleGAN-and-pix2pix/issues/1187,,no pipeline,True
-davidsandberg/facenet,1078,https://github.com/davidsandberg/facenet/pull/1078,,no pipeline,False
-davidsandberg/facenet,483,https://github.com/davidsandberg/facenet/issues/483,,no pipeline,True
-jhpyle/docassemble,283,https://github.com/jhpyle/docassemble/issues/283,,no pipeline,False
-CamDavidsonPilon/lifelines,282,https://github.com/CamDavidsonPilon/lifelines/issues/282,,model deployment,False
-deepfakes/faceswap,80,https://github.com/deepfakes/faceswap/issues/80,,no pipeline,True
-1adrianb/face-alignment,45,https://github.com/1adrianb/face-alignment/issues/45,,model training;model evaluation,True
-thtrieu/darkflow,969,https://github.com/thtrieu/darkflow/issues/969,,feature engineering,True
-hanxiao/bert-as-service,373,https://github.com/hanxiao/bert-as-service/issues/373,,no pipeline,True
-hanxiao/bert-as-service,310,https://github.com/hanxiao/bert-as-service/issues/310,,data cleaning,False
-dpinney/omf,57,https://github.com/dpinney/omf/issues/57,,no pipeline,False
-jantic/DeOldify,30,https://github.com/jantic/DeOldify/issues/30,,no pipeline,False
-ljvmiranda921/pyswarms,197,https://github.com/ljvmiranda921/pyswarms/pull/197,,no pipeline,False
-namisan/mt-dnn,156,https://github.com/namisan/mt-dnn/issues/156,,no pipeline,True
-BrikerMan/Kashgari,413,https://github.com/BrikerMan/Kashgari/pull/413,,no pipeline,False
-Linzaer/Ultra-Light-Fast-Generic-Face-Detector-1MB,109,https://github.com/Linzaer/Ultra-Light-Fast-Generic-Face-Detector-1MB/issues/109,,no pipeline,False
-deepfakes/faceswap,130,https://github.com/deepfakes/faceswap/pull/130,,no pipeline,False
-gboeing/osmnx,273,https://github.com/gboeing/osmnx/issues/273,enhancement,no pipeline,False
-jhpyle/docassemble,320,https://github.com/jhpyle/docassemble/pull/320,,no pipeline,False
-jhpyle/docassemble,158,https://github.com/jhpyle/docassemble/issues/158,,no pipeline,False
-jhpyle/docassemble,38,https://github.com/jhpyle/docassemble/issues/38,,no pipeline,False
-davidsandberg/facenet,407,https://github.com/davidsandberg/facenet/issues/407,,no pipeline,False
-dpinney/omf,338,https://github.com/dpinney/omf/issues/338,,no pipeline,False
-CamDavidsonPilon/lifelines,350,https://github.com/CamDavidsonPilon/lifelines/issues/350,convergence issue,data cleaning,True
-jdb78/pytorch-forecasting,352,https://github.com/jdb78/pytorch-forecasting/issues/352,question,no pipeline,True
-gboeing/osmnx,431,https://github.com/gboeing/osmnx/pull/431,,no pipeline,False
-jhpyle/docassemble,24,https://github.com/jhpyle/docassemble/issues/24,,no pipeline,False
-nextgenusfs/funannotate,257,https://github.com/nextgenusfs/funannotate/issues/257,,no pipeline,False
-SeanNaren/deepspeech.pytorch,517,https://github.com/SeanNaren/deepspeech.pytorch/issues/517,,no pipeline,True
-thtrieu/darkflow,78,https://github.com/thtrieu/darkflow/pull/78,,no pipeline,False
-ljvmiranda921/pyswarms,272,https://github.com/ljvmiranda921/pyswarms/pull/272,,no pipeline,False
-deepfakes/faceswap,356,https://github.com/deepfakes/faceswap/issues/356,,data cleaning;feature engineering,False
-jdb78/pytorch-forecasting,354,https://github.com/jdb78/pytorch-forecasting/issues/354,dependencies,no pipeline,True
-gboeing/osmnx,584,https://github.com/gboeing/osmnx/pull/584,,no pipeline,True
-ZQPei/deep_sort_pytorch,15,https://github.com/ZQPei/deep_sort_pytorch/issues/15,,chinese,False
-dpinney/omf,81,https://github.com/dpinney/omf/issues/81,,no pipeline,False
-junyanz/pytorch-CycleGAN-and-pix2pix,1006,https://github.com/junyanz/pytorch-CycleGAN-and-pix2pix/issues/1006,,no pipeline,False
-deepfakes/faceswap,861,https://github.com/deepfakes/faceswap/issues/861,,no pipeline,True
-afeinstein20/eleanor,198,https://github.com/afeinstein20/eleanor/pull/198,,model evaluation,True
-nextgenusfs/funannotate,537,https://github.com/nextgenusfs/funannotate/issues/537,,no pipeline,True
-gboeing/osmnx,123,https://github.com/gboeing/osmnx/issues/123,question,no pipeline,True
-thtrieu/darkflow,428,https://github.com/thtrieu/darkflow/issues/428,,data collection,True
-gboeing/osmnx,495,https://github.com/gboeing/osmnx/pull/495,,no pipeline,False
-nextgenusfs/funannotate,439,https://github.com/nextgenusfs/funannotate/issues/439,,no pipeline,True
-deepfakes/faceswap,375,https://github.com/deepfakes/faceswap/issues/375,,no pipeline,True
-emedvedev/attention-ocr,141,https://github.com/emedvedev/attention-ocr/issues/141,,data collection ,True
-gboeing/osmnx,58,https://github.com/gboeing/osmnx/issues/58,bug,no pipeline,False
-davidsandberg/facenet,99,https://github.com/davidsandberg/facenet/issues/99,,no pipeline,True
-deepfakes/faceswap,502,https://github.com/deepfakes/faceswap/pull/502,,no pipeline,False
-namisan/mt-dnn,88,https://github.com/namisan/mt-dnn/pull/88,,no pipeline,False
-1adrianb/face-alignment,37,https://github.com/1adrianb/face-alignment/issues/37,,no pipeline,True
-thtrieu/darkflow,959,https://github.com/thtrieu/darkflow/pull/959,,no pipeline,False
-hanxiao/bert-as-service,160,https://github.com/hanxiao/bert-as-service/issues/160,,no pipeline,True
-hanxiao/bert-as-service,213,https://github.com/hanxiao/bert-as-service/issues/213,discussion;feel free to contribute;help wanted,model requirements,True
-tianzhi0549/FCOS,165,https://github.com/tianzhi0549/FCOS/pull/165,,no pipeline,False
-deepfakes/faceswap,820,https://github.com/deepfakes/faceswap/issues/820,,no pipeline,True
-jdb78/pytorch-forecasting,43,https://github.com/jdb78/pytorch-forecasting/pull/43,,no pipeline,True
-tianzhi0549/FCOS,46,https://github.com/tianzhi0549/FCOS/issues/46,,no pipeline,True
-junyanz/pytorch-CycleGAN-and-pix2pix,128,https://github.com/junyanz/pytorch-CycleGAN-and-pix2pix/issues/128,,data cleaning,False
-deeppomf/DeepCreamPy,119,https://github.com/deeppomf/DeepCreamPy/issues/119,,page not found,True
-CamDavidsonPilon/lifelines,913,https://github.com/CamDavidsonPilon/lifelines/issues/913,,no pipeline,False
-regel/loudml,60,https://github.com/regel/loudml/issues/60,bug,no pipeline,False
-gboeing/osmnx,369,https://github.com/gboeing/osmnx/pull/369,,no pipeline,True
-afeinstein20/eleanor,223,https://github.com/afeinstein20/eleanor/issues/223,,no pipeline,False
-CamDavidsonPilon/lifelines,248,https://github.com/CamDavidsonPilon/lifelines/issues/248,,no pipeline,False
-dpinney/omf,321,https://github.com/dpinney/omf/issues/321,,no pipeline,False
-ljvmiranda921/pyswarms,394,https://github.com/ljvmiranda921/pyswarms/issues/394,,no pipeline,True
-deepfakes/faceswap,183,https://github.com/deepfakes/faceswap/pull/183,,no pipeline,False
-davidsandberg/facenet,49,https://github.com/davidsandberg/facenet/issues/49,,feature engineering,False
-ZQPei/deep_sort_pytorch,153,https://github.com/ZQPei/deep_sort_pytorch/issues/153,,no pipeline,True
-jdb78/pytorch-forecasting,147,https://github.com/jdb78/pytorch-forecasting/pull/147,dependencies,no pipeline,False
-SeanNaren/deepspeech.pytorch,188,https://github.com/SeanNaren/deepspeech.pytorch/issues/188,,no pipeline,False
-junyanz/pytorch-CycleGAN-and-pix2pix,209,https://github.com/junyanz/pytorch-CycleGAN-and-pix2pix/issues/209,,model evaluation,True
-mravanelli/pytorch-kaldi,245,https://github.com/mravanelli/pytorch-kaldi/issues/245,,no pipeline,True
-nextgenusfs/funannotate,44,https://github.com/nextgenusfs/funannotate/pull/44,,no pipeline,False
-Linzaer/Ultra-Light-Fast-Generic-Face-Detector-1MB,131,https://github.com/Linzaer/Ultra-Light-Fast-Generic-Face-Detector-1MB/issues/131,,no pipeline,True
-jdb78/pytorch-forecasting,72,https://github.com/jdb78/pytorch-forecasting/pull/72,,no pipeline,False
-CamDavidsonPilon/lifelines,117,https://github.com/CamDavidsonPilon/lifelines/issues/117,,no pipeline,False
-nicodv/kmodes,12,https://github.com/nicodv/kmodes/pull/12,,no pipeline,False
-deepfakes/faceswap,806,https://github.com/deepfakes/faceswap/issues/806,,no pipeline,True
-afeinstein20/eleanor,112,https://github.com/afeinstein20/eleanor/issues/112,,no pipeline,False
-hanxiao/bert-as-service,412,https://github.com/hanxiao/bert-as-service/issues/412,,no pipeline,False
-gboeing/osmnx,522,https://github.com/gboeing/osmnx/pull/522,enhancement,no pipeline,True
-jhpyle/docassemble,258,https://github.com/jhpyle/docassemble/pull/258,,no pipeline,False
-CamDavidsonPilon/lifelines,447,https://github.com/CamDavidsonPilon/lifelines/issues/447,,model evaluation,True
-nextgenusfs/funannotate,188,https://github.com/nextgenusfs/funannotate/issues/188,,no pipeline,False
-robertmartin8/PyPortfolioOpt,62,https://github.com/robertmartin8/PyPortfolioOpt/issues/62,packaging,no pipeline,False
-dpinney/omf,292,https://github.com/dpinney/omf/issues/292,NotAnIssue,no pipeline,False
-thtrieu/darkflow,105,https://github.com/thtrieu/darkflow/issues/105,,no pipeline,True
-junyanz/pytorch-CycleGAN-and-pix2pix,132,https://github.com/junyanz/pytorch-CycleGAN-and-pix2pix/pull/132,,no pipeline,False
-thtrieu/darkflow,484,https://github.com/thtrieu/darkflow/issues/484,bug,no pipeline,False
-hanxiao/bert-as-service,587,https://github.com/hanxiao/bert-as-service/issues/587,,no pipeline,True
-namisan/mt-dnn,98,https://github.com/namisan/mt-dnn/issues/98,,model deployment,True
-thtrieu/darkflow,501,https://github.com/thtrieu/darkflow/issues/501,,data collection;model training,False
-thtrieu/darkflow,337,https://github.com/thtrieu/darkflow/issues/337,,model requirements,True
-mravanelli/pytorch-kaldi,86,https://github.com/mravanelli/pytorch-kaldi/issues/86,,no pipeline,True
-emedvedev/attention-ocr,177,https://github.com/emedvedev/attention-ocr/pull/177,,no pipeline,False
-nicodv/kmodes,36,https://github.com/nicodv/kmodes/issues/36,easy;enhancement,no pipeline,False
-jhpyle/docassemble,66,https://github.com/jhpyle/docassemble/issues/66,,no pipeline,False
-regel/loudml,336,https://github.com/regel/loudml/pull/336,dependencies,no pipeline,False
-mravanelli/pytorch-kaldi,108,https://github.com/mravanelli/pytorch-kaldi/issues/108,,no pipeline,False
-gboeing/osmnx,530,https://github.com/gboeing/osmnx/issues/530,,no pipeline,True
-jdb78/pytorch-forecasting,32,https://github.com/jdb78/pytorch-forecasting/pull/32,,no pipeline,False
-deeppomf/DeepCreamPy,156,https://github.com/deeppomf/DeepCreamPy/issues/156,,page not found,False
-thtrieu/darkflow,973,https://github.com/thtrieu/darkflow/issues/973,,no pipeline,True
-CamDavidsonPilon/lifelines,7,https://github.com/CamDavidsonPilon/lifelines/issues/7,bug,no pipeline,False
-thtrieu/darkflow,109,https://github.com/thtrieu/darkflow/issues/109,,no pipeline,False
-robertmartin8/PyPortfolioOpt,247,https://github.com/robertmartin8/PyPortfolioOpt/pull/247,,no pipeline,False
-SeanNaren/deepspeech.pytorch,111,https://github.com/SeanNaren/deepspeech.pytorch/issues/111,,model evaluation,True
-robertmartin8/PyPortfolioOpt,258,https://github.com/robertmartin8/PyPortfolioOpt/issues/258,question,no pipeline,True
-thtrieu/darkflow,278,https://github.com/thtrieu/darkflow/issues/278,,model requirements,False
-ljvmiranda921/pyswarms,145,https://github.com/ljvmiranda921/pyswarms/pull/145,,no pipeline,False
-dpinney/omf,217,https://github.com/dpinney/omf/issues/217,,no pipeline,False
-mittagessen/kraken,161,https://github.com/mittagessen/kraken/issues/161,,model training,True
-junyanz/pytorch-CycleGAN-and-pix2pix,233,https://github.com/junyanz/pytorch-CycleGAN-and-pix2pix/issues/233,,no pipeline,True
-ZQPei/deep_sort_pytorch,1,https://github.com/ZQPei/deep_sort_pytorch/issues/1,,chinese,True
-SeanNaren/deepspeech.pytorch,412,https://github.com/SeanNaren/deepspeech.pytorch/issues/412,,no pipeline,True
-regel/loudml,275,https://github.com/regel/loudml/pull/275,dependencies,no pipeline,False
-CamDavidsonPilon/lifelines,173,https://github.com/CamDavidsonPilon/lifelines/issues/173,,no pipeline,False
-junyanz/pytorch-CycleGAN-and-pix2pix,334,https://github.com/junyanz/pytorch-CycleGAN-and-pix2pix/issues/334,,data cleaning,True
-dpinney/omf,216,https://github.com/dpinney/omf/issues/216,,no pipeline,True
-davidsandberg/facenet,127,https://github.com/davidsandberg/facenet/issues/127,,model training,True
-jantic/DeOldify,273,https://github.com/jantic/DeOldify/issues/273,,no pipeline,True
-deepfakes/faceswap,414,https://github.com/deepfakes/faceswap/issues/414,,model evaluation,False
-thtrieu/darkflow,161,https://github.com/thtrieu/darkflow/issues/161,,no pipeline,True
-Linzaer/Ultra-Light-Fast-Generic-Face-Detector-1MB,227,https://github.com/Linzaer/Ultra-Light-Fast-Generic-Face-Detector-1MB/issues/227,,chinese,False
-CamDavidsonPilon/lifelines,406,https://github.com/CamDavidsonPilon/lifelines/issues/406,,no pipeline,False
-CamDavidsonPilon/lifelines,843,https://github.com/CamDavidsonPilon/lifelines/pull/843,,no pipeline,True
-BrikerMan/Kashgari,167,https://github.com/BrikerMan/Kashgari/issues/167,bug;wontfix,model deployment,True
-davidsandberg/facenet,34,https://github.com/davidsandberg/facenet/issues/34,,model deployment,True
-CamDavidsonPilon/lifelines,901,https://github.com/CamDavidsonPilon/lifelines/pull/901,,no pipeline,False

util/tests.py

@@ -1,20 +0,0 @@
-import pandas as pd
-from scipy.stats import ranksums
-from cliffsDelta import cliffsDelta
-
-def evaluate(feature: str):
-    print(f'====={feature}=====')
-    print(ranksums(ml_data[feature], no_ml_data[feature]))
-    print(cliffsDelta(ml_data[feature], no_ml_data[feature]))
-
-if __name__ == '__main__':
-    data = pd.read_csv('commit_analysis.csv')
-    ml_data = data[data['is_ml']]
-    no_ml_data = data[~data['is_ml']]
-
-    evaluate('file_entropy')
-    evaluate('line_entropy')
-    evaluate('n_comments')
-    evaluate('words_mean')
-    evaluate('day_to_fix')
-

util/time-to-fix.py

@@ -1,16 +0,0 @@
-import pandas as pd
-import seaborn as sns
-import matplotlib.pyplot as plt
-
-if __name__ == '__main__':
-    data = pd.read_csv('commit_analysis.csv')
-    data['type'] = data['is_ml'].apply(lambda x: 'ML' if x else 'No ML')
-
-    ylim = data['day_to_fix'].quantile(0.95)
-    sns.catplot(x='type', y='day_to_fix', kind='box', data=data) \
-        .set(title='Giorni necessari per un fix') \
-        .set(xlabel='tipo') \
-        .set(ylabel='giorni') \
-        .set(ylim=(0, ylim))
-    plt.tight_layout()
-    plt.savefig('../src/figures/day-to-fix.pdf')