Come distinguere i veri progetti di codice collaborativo dal rumore su GitHub?

GitHub ospita più di 10 milioni di repository: è una miniera d’oro per chi studia il software, ma anche un campo minato di progetti “rumorosi”. Sono repository creati per scopi personali, come file di configurazione o collezioni di script, che non partecipano a collaborazioni vere. Quando i ricercatori scelgono i progetti da analizzare, mescolare questi “rumori” con veri progetti collaborativi (ad esempio framework di machine learning) può falsare i risultati. Per risolvere il problema, gli autori hanno migliorato il Semi‑Automatic Decision Tree Method (SADTM), una tecnica già usata per classificare i progetti collaborativi. Il nuovo approccio è più generale e più preciso: è stato testato sul dataset GHTorrent (2012‑2020) e ha mostrato una stabilità superiore, mantenendo risultati coerenti su diversi set di dati. Inoltre, la precisione è alta, con un F‑measure che varia tra 0,78 e 0,89. In pratica, il metodo filtra meglio il “rumore” e seleziona i progetti davvero collaborativi, permettendo agli studiosi di costruire campioni di alta qualità senza temere bias. Questo significa che le future ricerche su GitHub potranno basarsi su dati più puliti e affidabili, accelerando la scoperta di nuove tendenze nel mondo del software open‑source.

Il metodo SADTM si basa su un albero decisionale semi‑automatico: combina regole predefinite con apprendimento supervisionato. Le regole includono metriche come il numero di collaboratori unici, la frequenza di commit, la presenza di file tipici di progetti di sviluppo (README, LICENSE, file di build) e la distribuzione temporale delle attività. Il modello addestra un classificatore (ad esempio Random Forest) su un campione etichettato manualmente di repository noti come collaborativi o rumorosi. Durante la fase di predizione, l’albero applica prima le regole “hard” (es. più di 5 collaboratori attivi) per filtrare rapidamente i casi evidenti, poi passa al classificatore per i casi borderline. L’ottimizzazione proposta introduce una normalizzazione dei conteggi per tenere conto della crescita esponenziale dei repository nel tempo, riducendo il bias verso progetti più recenti. Inoltre, è stato aggiunto un meccanismo di cross‑validation a 10‑fold per valutare la stabilità del modello su diversi slice temporali del dataset GHTorrent. I risultati mostrano un F‑measure medio di 0,84, con una varianza inferiore rispetto ai metodi precedenti, indicando una maggiore robustezza. L’approccio è scalabile: può essere eseguito su milioni di repository usando infrastrutture di calcolo distribuito (Spark o Hadoop), mantenendo tempi di elaborazione accettabili (circa 2‑3 ore per l’intero dataset 2012‑2020). Questo rende il metodo pratico per chiunque voglia costruire dataset puliti per analisi di mining del software o studi di evoluzione dei progetti open‑source.