Cosa fare con i problemi abbandonati in GitHub?

Questo è un dilemma: non puoi chiudere il problema come "risolto", perché in realtà non sai se è stato corretto, o almeno anche se alcuni problema è stato risolto, in realtà non si sa se questo era il problema di cui parlava il giornalista. D'altra parte, non vuoi lasciare un problema che potrebbe essere stato risolto, soprattutto se non sarai mai in grado di chiuderlo perché non riceverai mai la conferma.

Quindi dovrebbe chiuderlo, ma probabilmente non come "risolto". Potresti inventare un motivo di chiusura personalizzato "maybefixed" o "unconfirmedfix" se vuoi essere positivo o "reportervanished" se non lo fai. Potresti anche solo dire "impossibile riprodurre" e attendere che lo stesso bug venga visualizzato per un reporter più reattivo.

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

La tua domanda principale aveva già una risposta, ma hai anche chiesto di documentare il processo e anche questo ha bisogno di risposta.

La soluzione che ho visto in molti progetti non è di metterla nel README.md del progetto, ma in uno speciale README di contributo - un file README per i contributori. Questo file descrive tutto quello che vuoi che le persone che contribuiscono al tuo progetto sappiano: sul codice (convenzioni di denominazione, organizzazione dei moduli, ecc.) O sul processo (come scrivere commit, come gestire i ticket, ecc.). Questo file può essere un altro .MD file nel progetto o inserito in un repository completamente diverso (in modo che possa essere condiviso tra tutti i tuoi progetti). Non dimenticare di collegarti ad esso dal README.md principale!

Il punto di separare le informazioni dal README principale è che di solito solo una frazione degli utenti del progetto contribuisce direttamente ad esse. La maggior parte degli utenti non ha bisogno di annoiarsi con queste informazioni: devono solo sapere cosa fa il tuo progetto e come usarlo, e questo è ciò che il README principale dovrebbe contenere. Nel caso del progetto la sezione contributo è molto piccola, quindi non ingombrante il README principale - ma se si documentano tutti i flussi di lavoro che si desidera che i contributori seguano, non si adatteranno a questo modo più bene. .

Nota che ogni utente può aprire un bug, quindi se hai dei requisiti speciali sull'apertura del bug dovresti metterli nel README principale (prova a tenerlo bene però - a differenza dei contributori del codice, i segnalatori di bug saranno meno disposti ad andare a grandi lunghezze per studiare e conformarsi alle vostre regole). Tuttavia, la persona che effettivamente corregge il bug e chiude il ticket (sia tu che uno dei contributori che hai confermato) è un contributore diretto e ci si può aspettare che legga il contributo README - quindi il processo di chiusura dei ticket quando il reporter fa non rispondere dovrebbe essere descritto lì.

Ho letto questo come più una domanda sulle pratiche su come gestire un bug non verificato (usando il tracker dei problemi di github) più di qualsiasi altra cosa.

Per me, questa è una risposta piuttosto semplice basata su altri tracker di problemi che ho usato. Github non impone a nessuno di utilizzare 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:

Indicheremoquiunacosamoltoimportante-ottienerisoltocomecorrettoprimachediventichiusodopoesserestatoverificato.IlflussodilavorodiGithubdibasemostrasologlistatirosso(aperto)everde(chiuso).

Pertanto,unapproccioèutilizzareleetichetteall'internodiGithub( etichette della tua applicazione ) per provare a mostrare le informazioni aggiuntive. Puoi creare una coppia di etichette "non verificate" e "verificate" da applicare una volta chiuso il problema. Nota che questo è solo un approccio: se cerchi, puoi trovare dozzine di approcci diversi all'uso delle etichette. Qui, 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. Applicare l'etichetta 'non verificato' ad esso. Una volta che qualcuno ha familiarizzato con il bug nella versione precedente dice "sì, questo è stato risolto" puoi cambiare l'etichetta in "verificato". Se dicono di no, lo riapri.

Si noti inoltre che ci sono altri stati risolti oltre a "fisso". C'è 'wontfix' (la correzione è qualcosa che non può essere fatto con la struttura corrente) e 'worksforme' (il bug non può essere riprodotto) e 'invalid' (si sta registrando un bug sul sistema operativo, non l'applicazione tipo cose).

Vorrei prendere una delle due viste, a seconda di quanto ero sicuro che stavo parlando della stessa cosa del reporter originale:

1) Poiché il reporter non è più disponibile, ritengo che il bug in questione significhi qualunque cosa sia stata risolta. Se aiuta, allegare i casi di test per chiarire quali errori hai trovato. Descrivi dettagliatamente nel bug report cosa è stato risolto e lascia una nota del tipo: "Credo che questo sia il significato di" nav interr ", per favore riapri o sollevi un nuovo bug se non è quello che intendevi". Segna il bug come risolto.

2) Poiché il reporter non è più disponibile, si ritiene che il bug non possa essere (noto per essere) riprodotto, poiché solo la parola del reporter per esso confermerebbe che è la stessa cosa che hanno segnalato. Solleva un nuovo bug per descrivere la cosa che hai aggiustato, per il merito di menzione del fatto che è stata osservata nelle condizioni descritte dal giornalista assente, nota che entrambi possono essere duplicati, contrassegnare il nuovo bug corretto e contrassegnato come invalido o non riproducibile con una nota del tipo "Non riesco a capire cosa intendessi per 'nav break', ma ho risolto il problema che ho trovato. Riapri o genera un nuovo bug se il nav si rompe ancora, descrivendo più in dettaglio cosa non va ".

Per quanto riguarda i tempi, penso che dovrebbe dipendere dal progetto. Se sei molto reattivo e stai affrontando questo bug entro pochi giorni dal suo innalzamento, allora le persone dovrebbero capire che non attenderete settimane prima di una risposta prima di risolvere il problema. D'altra parte, se è sul tuo slushpile da mesi, può rimanere aperto per un altro mese o due senza causare problemi.

Per questo motivo non penso che ci sia un limite di tempo specifico che costituisce una "buona pratica", o che è necessario pubblicare la tua politica e attenerci ad essa. Certamente non vorrai registrare che il giornalista non può essere contattato fino a quando non hai fatto uno sforzo per contattarli. Ma non vedo alcun punto che lasci più avvertimenti per il conto alla rovescia: o rivisiteranno il bug e vorranno dire qualcosa, altrimenti non lo faranno.