Valutazione dei bug e cura dei problemi #

Il tracker dei problemi è importante per la comunicazione nel progetto perché funge da posizione centralizzata per effettuare richieste di funzionalità, segnalare bug, identificare i principali progetti su cui lavorare e discutere le priorità. Per questo motivo, è importante curare l'elenco dei problemi, aggiungendo etichette ai problemi e chiudendo i problemi risolti o irrisolvibili.

Il triage dei problemi non richiede alcuna competenza particolare all'interno di Matplotlib, è estremamente prezioso per il progetto e diamo il benvenuto a chiunque partecipi al triage dei problemi! Tuttavia, le persone che non fanno parte dell'organizzazione Matplotlib non dispongono delle autorizzazioni per modificare le pietre miliari, aggiungere etichette o chiudere il problema . Se non disponi di autorizzazioni GitHub sufficienti per fare qualcosa (ad es. aggiungere un'etichetta, chiudere un problema), lascia un commento taggando @matplotlib/triageteamcon i tuoi consigli!

Lavorare sui problemi per migliorarli #

Migliorare i problemi aumenta le loro possibilità di essere risolti con successo. Le linee guida sull'invio di buoni problemi possono essere trovate qui . Una terza parte può fornire un feedback utile o persino aggiungere commenti sul problema. Le seguenti azioni sono in genere utili:

  • documentare i problemi in cui mancano elementi per riprodurre il problema, ad esempio esempi di codice

  • suggerendo un uso migliore della formattazione del codice (ad esempio triple back ticks nel markdown).

  • suggerendo di riformulare il titolo e la descrizione per renderli più espliciti sul problema da risolvere

  • collegarsi a questioni o discussioni correlate mentre si descrive brevemente come sono correlati, ad esempio "Vedi anche #xyz per un tentativo simile" o "Vedi anche #xyz dove è stata segnalata la stessa cosa" fornisce contesto e aiuta la discussione

  • verificare che il problema sia riproducibile

  • classificare il problema come una richiesta di funzionalità, un bug di vecchia data o una regressione

Squadra di triage #

Se vuoi entrare a far parte del team di triage:

  1. Valuta correttamente 2-3 problemi.

  2. Chiedi a qualcuno del team di triage (pubblicamente o privatamente) di raccomandarti al team di triage . Se hai lavorato con qualcuno sulla questione del triage, sarebbe una brava persona a cui chiedere.

  3. Esercita responsabilmente il tuo nuovo potere!

Chiunque disponga dei diritti di commit o triage può anche nominare un utente da invitare a far parte del team di triage.

Operazioni di triage per i membri dei team core e triage #

Oltre a quanto sopra, i membri del core team e del triage team possono svolgere le seguenti importanti attività:

  • Aggiorna etichette per problemi e PR: consulta l'elenco delle etichette github disponibili .

  • Problemi di triage:

    • riproduci il problema , se il codice postato è un bug etichetta il problema con "status: bug confermato".

    • identifica le regressioni , determina se il bug segnalato funzionava come previsto in una versione recente di Matplotlib e, in tal caso, determina l'ultima versione funzionante. Le regressioni dovrebbero essere segnate per la prossima versione di correzione dei bug e potrebbero essere etichettate come "Release critical".

    • chiudi le domande sull'utilizzo e invita educatamente il giornalista a utilizzare invece il discorso o Stack Overflow ed etichetta come "supporto della comunità".

    • chiudere i problemi duplicati , dopo aver verificato che siano effettivamente duplicati. Idealmente, il mittente originale sposta la discussione sul problema più vecchio e duplicato

    • chiudere i problemi che non possono essere replicati , dopo aver lasciato il tempo (almeno una settimana) per aggiungere ulteriori informazioni

Un flusso di lavoro tipico per la valutazione dei problemi #

Il seguente flusso di lavoro [ 1 ] è un buon modo per affrontare la valutazione dei problemi:

  1. Ringrazio il giornalista per aver aperto un problema

    Il tracker dei problemi è la prima interazione di molte persone con il progetto Matplotlib stesso, oltre al semplice utilizzo della libreria. In quanto tale, vogliamo che sia un'esperienza accogliente e piacevole.

  2. È una domanda sull'uso? Se è così chiudilo con un messaggio educato.

  3. Vengono fornite le informazioni necessarie?

    Verificare che il poster abbia compilato il modello di problema. Se mancano informazioni cruciali (la versione di Python, la versione di Matplotlib utilizzata, il sistema operativo e il backend), chiedi cortesemente al poster originale di fornire le informazioni.

  4. Il problema è minimo e riproducibile?

    Per le segnalazioni di bug, chiediamo al segnalatore di fornire un esempio minimo riproducibile. Vedi questo utile post di Matthew Rocklin per una buona spiegazione. Se l'esempio non è riproducibile, o se chiaramente non è minimo, sentiti libero di chiedere al giornalista se può fornire un esempio o semplificare quello fornito. Riconosci che scrivere esempi riproducibili minimi è un duro lavoro. Se il giornalista è in difficoltà, puoi provare a scriverne uno tu stesso.

    Se viene fornito un esempio riproducibile, ma vedi una semplificazione, aggiungi il tuo esempio riproducibile più semplice.

    Se non riesci a riprodurre il problema, segnalalo insieme alle versioni del tuo sistema operativo, Python e Matplotlib.

    Se abbiamo bisogno di ulteriori informazioni da questo passaggio o da quello precedente, etichetta il problema con "status: necessita di chiarimenti".

  5. Si tratta di una regressione?

    Mentre ci impegniamo per una libreria priva di bug, le regressioni hanno la massima priorità. Se abbiamo rotto il codice utente che prima funzionava, dovremmo sistemarlo nella prossima versione della patch!

    Prova a determinare quando si è verificata la regressione eseguendo il codice di riproduzione su versioni precedenti di Matplotlib. Questo può essere fatto dalle versioni rilasciate di Matplotlib (per ottenere l'ultima versione in cui ha funzionato) o usando git bisect per trovare il primo commit in cui è stato rotto.

  6. Si tratta di un problema duplicato?

    Abbiamo molte questioni aperte. Se un nuovo numero sembra essere un duplicato, indica il problema originale. Se si tratta di un chiaro duplicato o se il consenso è che è ridondante, chiuderlo. Assicurati di ringraziare ancora il giornalista e incoraggialo a intervenire sul problema originale e magari provare a risolverlo.

    Se il nuovo numero fornisce informazioni pertinenti, come un esempio migliore o leggermente diverso, aggiungilo al numero originale come commento o come modifica al post originale.

    Etichetta il problema chiuso con "status: duplicato"

  7. Assicurati che il titolo rispecchi accuratamente il problema. Se disponi delle autorizzazioni necessarie, modificalo tu stesso se non è chiaro.

  8. Aggiungi le etichette pertinenti, ad esempio "Documentazione" quando il problema riguarda la documentazione, "Bug" se si tratta chiaramente di un bug, "Nuova funzionalità" se si tratta di una nuova richiesta di funzionalità, ...

    Se il problema è chiaramente definito e la correzione sembra relativamente semplice, etichetta il problema come "Buon primo problema" (e possibilmente una descrizione della correzione o un suggerimento su dove cercare nella base di codice per iniziare).

    Un ulteriore passaggio utile può essere quello di contrassegnare il modulo corrispondente, ad esempio l'etichetta "GUI/Qt", se pertinente.

Lavorare su PR per aiutare a rivedere #

Anche la revisione del codice è incoraggiata. I contributori e gli utenti sono invitati a partecipare al processo di revisione seguendo le nostre linee guida per la revisione .

Ringraziamenti #

Questa pagina è leggermente adattata dal progetto scikit-learn .