Toward Linking Declined Proposals and Source Code: An Exploratory Study on the Go Repository

1. Il Problema

Nello sviluppo del software, la tracciabilità (il collegamento esplicito tra artefatti come issue, documenti di design e codice sorgente) è fondamentale per la manutenzione, la comprensione del codice e l'analisi dell'impatto dei cambiamenti.
La ricerca esistente si è concentrata prevalentemente sulle proposte accettate (quelle che sono state implementate nel codice), ignorando le proposte declinate (quelle discusse ma rifiutate). Tuttavia, le discussioni sulle proposte declinate contengono informazioni preziose:

• Razionali di design e criteri decisionali impliciti.
• Alternative scartate e compromessi rifiutati.
• Motivazioni per cui una funzionalità non è stata implementata.

Il problema centrale è che queste proposte declinate non hanno un collegamento diretto con il codice sorgente (poiché il codice non è stato scritto), rendendo difficile per gli sviluppatori futuri accedere a queste conoscenze. L'obiettivo dello studio è colmare questo gap creando un sistema automatico per stabilire link di tracciabilità tra le proposte declinate e le parti rilevanti del codice sorgente (anche se il codice non è stato modificato), permettendo di recuperare la conoscenza implicita contenuta nelle discussioni.

2. Metodologia

Gli autori hanno proposto un pipeline guidata da Large Language Models (LLM) per recuperare i link di tracciabilità. Il processo è diviso in tre fasi principali, ispirato ai metodi di recupero dei link basati su Retrieval-Augmented Generation (RAG), ma adattato per gestire la natura non implementata delle proposte declinate.

A. Input e Dati

• Dataset: Proposte (issue) dal repository ufficiale di Go (golang/go).
• Soggetto: 341 proposte declinate (dopo filtraggio).
• Contesto: Il repository contiene directory, file e funzioni/metodi.

B. Pipeline LLM-Driven

Il sistema opera in tre fasi sequenziali:

1. Fase 0: Decisione della Granularità (Granularity Decision)

   • L'LLM analizza il testo della proposta declinata per determinare il livello di granularità più appropriato del codice da collegare.
   • Livelli definiti:
     • Directory: Modifiche alla struttura dei pacchetti (creazione/rimozione file/cartelle).
     • File: Modifiche all'interno di file esistenti (aggiunta funzioni, tipi, costanti).
     • Funzione: Modifiche alla logica interna di funzioni o metodi esistenti.
   • Questa decisione guida le fasi successive.

2. Fase 1: Localizzazione (Localization)

   • Invece di usare metodi basati su embedding (che calcolano la similarità testuale), il sistema utilizza l'LLM per una localizzazione contestuale.
   • L'approccio è gerarchico (ispirato a Agentless):
     • Se la granularità è Directory: L'LLM analizza la struttura ad albero del repository per identificare le cartelle rilevanti.
     • Se la granularità è File: L'LLM identifica i file specifici all'interno delle directory candidate.
     • Se la granularità è Funzione: L'LLM analizza le firme delle funzioni (signature) all'interno dei file candidati per trovare quelle pertinenti.
   • Questo approccio supera i limiti dei metodi IR tradizionali che potrebbero fallire quando il codice discusso non esiste nel repository.

3. Fase 2: Decisione del Link (Link Decision)

   • L'LLM riceve la proposta e l'elemento di codice localizzato (directory, file o funzione) e deve classificarlo come binario: Sì/No (il codice è rilevante per la proposta?).
   • Questo evita soglie arbitrarie di similarità.

C. Valutazione

• Metriche: Accuratezza nella scelta della granularità, Precisione, Recall e F1-score.
• Ground Truth: Costruito manualmente dagli autori tramite criteri di validazione rigorosi (poiché non esiste un codice implementato da cui derivare automaticamente i link).
• Confronto: La pipeline è stata confrontata con un baseline basato su RAG (metodo LiSSA) su proposte accettate per validare l'efficacia dell'approccio LLM rispetto ai metodi basati su embedding.

3. Contributi Chiave

1. Nuovo Task di Ricerca: Primo studio che tenta di stabilire link di tracciabilità tra proposte declinate e codice sorgente, rendendo accessibile la conoscenza "nascosta" nelle discussioni non implementate.
2. Approccio LLM-Driven: Progettazione e valutazione di una pipeline che utilizza gli LLM non solo per la decisione del link, ma anche per la localizzazione gerarchica e la scelta della granularità, superando i limiti dei metodi basati su similarità testuale pura.
3. Analisi dei Fallimenti: Un'analisi dettagliata che identifica perché il sistema fallisce, fornendo una tassonomia dei pattern di discussione che ostacolano il recupero dei link (es. mancanza di dettagli implementativi, informazioni nascoste).
4. Dataset e Riproducibilità: Pubblicazione di un pacchetto di replicazione completo con dati, prompt e script.

4. Risultati

Lo studio ha risposto a due domande di ricerca (RQ):

• RQ1: Fino a che punto la pipeline può generare link con successo?

  • Accuratezza della Granularità: La pipeline ha selezionato la granularità corretta con un'accuratezza media di 0.836.
    • File-level: 0.887 (migliore).
    • Directory-level: 0.696.
    • Function-level: 0.407 (più difficile).
  • Precisione dei Link: La precisione media nella generazione di link corretti è stata di 0.643.
    • File-level: 0.688.
    • Directory-level: 0.529.
    • Function-level: 0.253 (bassa, principalmente dovuta a errori nella selezione della granularità).
  • Confronto Baseline: La pipeline LLM ha superato il metodo basato su RAG/embedding (LiSSA) sia in precisione che in F1-score anche su proposte accettate, dimostrando la validità dell'architettura.

• RQ2: Perché la pipeline fallisce?

  • Lunghezza della discussione: Non è un fattore determinante (nessuna correlazione significativa tra lunghezza e performance).
  • Fattori critici di fallimento:
    1. Mancanza di dettagli implementativi: Le discussioni descrivono cosa fare ma non come o dove farlo (42.9% dei fallimenti nella scelta della granularità).
    2. Informazioni oscurate: Il contenuto rilevante è nascosto in discussioni lunghe o confuse da suggerimenti contraddittori.
    3. Riferimenti espliciti: Quando la granularità è corretta, la precisione dipende fortemente da quanto esplicitamente il codice target è menzionato nel testo (Livello 1: menzione diretta > Livello 3: inferenza implicita).

5. Significato e Implicazioni

Questo lavoro è significativo perché:

• Valorizza il "Fallimento": Trasforma le proposte rifiutate da "rifiuti" a risorse di conoscenza, aiutando gli sviluppatori a evitare errori passati e a comprendere le decisioni di design.
• Migliora la Manutenibilità: Fornisce un modo per tracciare il "perché" dietro certe scelte, anche se non implementate, riducendo i costi di manutenzione a lungo termine.
• Indirizza la Ricerca Futura: Suggerisce che per migliorare i sistemi di tracciabilità su proposte non implementate, è necessario:
  • Arricchire l'input con contesti esterni (es. commenti, proposte correlate) quando i dettagli mancano.
  • Utilizzare tecniche di riassunto per isolare le informazioni chiave quando il testo è troppo rumoroso.
• Valida l'uso degli LLM: Dimostra che gli LLM sono superiori ai metodi tradizionali di Information Retrieval per compiti di tracciabilità che richiedono ragionamento contestuale e gerarchico, specialmente in scenari dove il codice target non è fisicamente presente nel repository.