Cosa fare con i problemi abbandonati in GitHub?

Se qualcuno apre un problema su GitHub ma vengono richieste e mai fornite ulteriori informazioni per riprodurre l'errore, qual è la normale procedura? Esempio .

Qui l'autore afferma che la "nave si rompe". Anche se credo che sia stato risolto, vorrei che l'autore parlasse della stessa cosa. Ma a volte il giornalista del problema scompare. È una pratica buona / comune stabilire una data di scadenza per i problemi abbandonati?

Qualcosa come queste condizioni:

• Viene sollevata una domanda sulla questione per poter eseguire il debug.
• Sono trascorsi più di 2-6 mesi dall'ultima domanda / commento senza risposta da parte del team di sviluppo.
• I bug non possono essere riprodotti al momento della chiusura (per qualsiasi motivo, forse non potrebbero mai essere riprodotti).
• Un avviso viene emesso 2 settimane prima di chiuderlo.

Cosa fanno normalmente i progetti? Non sono riuscito a trovare nulla su Google. Inoltre, come dovrei documentarlo? È sufficiente una semplice nota in README.md che dettaglia i punti sopra e un commento nel problema che spiega perché è chiuso?

Nota: è diverso da questa domanda poiché il bug potrebbe essere ancora rilevante (o meno), tuttavia mancano le informazioni.

Questo è un dilemma: non è possibile chiudere il problema come "risolto", perché in realtà non si sa se è stato risolto, o almeno anche se qualche problema è stato risolto, in realtà non si sa se questo era il problema del giornalista stava parlando. D'altra parte, non vuoi lasciare un problema che potrebbe essere stato risolto aperto, soprattutto se non sarai mai in grado di chiuderlo perché non otterrai mai la conferma.

Quindi, dovresti chiuderlo, ma probabilmente non come "risolto". Potresti inventare un motivo di chiusura personalizzato "forse corretto" o "non confermato" se vuoi essere positivo o "reportervanito" se non lo fai. Potresti anche semplicemente dire "impossibile riprodurre" e attendere che lo stesso bug venga visualizzato per un giornalista più reattivo.

Tuttavia, non dovresti spendere risorse per un bug per il quale non saprai mai se è stato effettivamente corretto o meno.

Alla tua domanda principale è già stata data una risposta, ma hai anche chiesto di documentare il processo e anche questo deve rispondere.

La soluzione che ho visto in molti progetti non è quella di inserirla nel progetto README.md, ma in uno speciale contributo README - un file README per i collaboratori. Questo file descrive tutto ciò che vuoi che le persone che contribuiscono al tuo progetto sappiano: che si tratti del codice (convenzioni di denominazione, organizzazione dei moduli ecc.) O del processo (come scrivere i commit, come gestire i ticket, ecc.). Questo file può essere un altro .MDfile nel progetto o inserito in un repository completamente diverso (quindi può essere condiviso tra tutti i tuoi progetti). Basta non dimenticare di collegarsi ad esso dal principale README.md!

Il punto di separazione di tali informazioni dal README principale è che di solito solo una parte dell'utente del progetto contribuisce direttamente ad esso. La maggior parte degli utenti non ha bisogno di annoiarsi con queste informazioni: devono solo sapere cosa fa il progetto e come usarlo, ed è quello che dovrebbe contenere il README principale. Nel caso del tuo progetto, la sezione dei contributi è molto piccola, quindi non ingombra il README principale, ma se documenti tutti i flussi di lavoro che vuoi che i collaboratori seguano, non si adatteranno più bene ...

Si noti che qualsiasi utente può aprire un bug, quindi se si dispone di requisiti speciali per l'apertura dei bug, è necessario inserirli nel README principale (cercare di mantenerlo comunque) - a differenza dei contributori di codice, i reporter di bug saranno probabilmente meno disposti a fare di tutto studiare e conformarsi alle tue regole). Tuttavia, la persona che risolve effettivamente il bug e chiude il ticket (che tu sia o uno dei collaboratori che hai confermato) è un contributore diretto e ci si può aspettare che legga il contributo README - quindi il processo di chiusura dei biglietti quando il giornalista lo fa non rispondere dovrebbe essere descritto lì.

Ho letto questo come più una domanda sulle pratiche di come gestire un bug non verificato (usando il tracker dei problemi di Github) che altro.

Per me, questa è una risposta piuttosto semplice basata su altri tracker di problemi che ho usato. Github non obbliga nessuno a usare alcun flusso di lavoro e questo lo rende molto flessibile ... e piuttosto inutile nella sua configurazione predefinita.

Osservando il flusso di lavoro predefinito di Bugzilla otteniamo:

Ho intenzione di sottolineare una cosa molto importante lì: viene risolto come riparato prima che venga chiuso dopo essere stato verificato . Il flusso di lavoro di base di Github mostra solo gli stati rosso (aperto) e verde (chiuso).

Pertanto, un approccio è utilizzare le etichette in Github ( le etichette dell'applicazione ) per provare a mostrare le informazioni aggiuntive. È possibile creare una coppia di etichette "non verificate" e "verificate" da applicare una volta chiuso il problema. Nota che questo è solo un approccio: se esegui una ricerca puoi trovare dozzine di approcci diversi all'uso delle etichette. Ecco la domanda Come gestire i problemi di github per (priorità, ecc.)? risolve questo problema.

L'hai risolto, dal punto di vista di uno sviluppatore è fatto. Chiudi il problema su Github. Applica l'etichetta 'non verificato'. Una volta che qualcuno che ha familiarità con il bug nella versione precedente dice "sì, è stato risolto" è possibile modificare l'etichetta in "verificato". Se dicono che non è così, allora lo riapri.

Si noti inoltre che esistono altri stati risolti oltre a "fixed". C'è 'wontfix' (la correzione è qualcosa che non può essere fatta con la struttura attuale) e 'worksforme' (il bug non può essere riprodotto) e 'non valido' (stai archiviando un bug sul sistema operativo, non il tipo di applicazione cose).

Vorrei prendere una delle due opinioni, a seconda di quanto fossi sicuro di parlare della stessa cosa del giornalista originale:

1) Dato che il reporter non è più disponibile, ritiene che il bug in questione significhi qualunque cosa tu abbia risolto. Se aiuta, collega i casi di test per chiarire quali errori hai riscontrato. Descrivi dettagliatamente il bug report su ciò che è stato corretto e lascia una nota del tipo "Credo che questo sia ciò che significa" interruzioni navali ", riapri o solleva un nuovo bug se non è quello che intendevi". Contrassegna il bug come corretto.

2) Poiché il reporter non è più disponibile, ritengono che il bug non possa essere (noto per essere) riprodotto, poiché solo la parola del reporter per confermare confermerebbe che è la stessa cosa che hanno segnalato. Solleva un nuovo bug per descrivere la cosa che hai risolto, per amor di merito, è stato osservato che è stato osservato nelle condizioni descritte dal giornalista assente, nota su entrambi che possono essere duplicati, contrassegna il nuovo bug corretto e contrassegna questo non valido o non riproducibile con una nota del tipo "Non riesco a capire cosa intendevi con" nav break ", ma ho risolto il problema che ho riscontrato. Riapri o solleva un nuovo bug se il nav si rompe ancora, descrivendo in più in dettaglio cosa non va ".

Per quanto riguarda i tempi, penso che dovrebbe dipendere dal progetto. Se sei molto reattivo e hai a che fare con questo bug entro pochi giorni dal momento in cui è stato sollevato, le persone dovrebbero capire che non aspetterai settimane per una risposta prima di risolvere il problema. D'altra parte, se è stato nella tua granita per mesi, può rimanere aperto per un altro mese o due senza causare problemi.

Per questo motivo non credo che ci sia un limite di tempo particolare che costituisce una "buona pratica" o che è necessario pubblicare la propria politica e attenersi ad essa. Certamente non vorrai registrare che il giornalista non può essere contattato fino a quando non avrai fatto uno sforzo per contattarlo. Inoltre, non vedo alcun punto che lasci il conto alla rovescia di più avvisi fino a una scadenza: o rivisiteranno il bug e vorranno dire qualcosa, oppure non lo faranno.