Etichetta di tracciamento dei bug - Necromancy o Duplicate?

L'unica cosa che può rispondere adeguatamente a questo è il processo della tua organizzazione. Se questa situazione non è definita, dovrebbe essere definita in modo che sia coerente ogni volta che accade.

Suggerirei di riaprire quello vecchio e aggiungere nuove informazioni nel modo appropriato. Da un punto di vista metrico / misurazioni, questo sarebbe probabilmente il meno dannoso: la novità non è un nuovo difetto o miglioramento, ma piuttosto la rivisitazione di uno vecchio. Ci dovrebbe essere uno stato per le richieste di cambiamento in entrata che indica che deve essere esaminato da chiunque sia la parte responsabile. Cambiando lo stato su questo, possono vedere la cronologia (il fatto che è stata differita una volta in precedenza), ma anche le nuove informazioni facilmente.

Quello che farei (e ho fatto in passato) è creare un nuovo bug (per renderlo pertinente), annotare la possibile / nuova correzione e collegarsi a quello vecchio per riferimento storico / tracciamento.

dipende anche dal bug ... quel bug potrebbe essere una "caratteristica" ora, o ha un work-around consolidato che le persone usano da 2 anni e che sarebbe stato risolto da una correzione.

Fondamentalmente, devi davvero scavare e indagare sul bug e sulla potenziale soluzione, e se pensi ancora che dovrebbe essere corretto, allora registra il bug.

Come programmatore, penso che la duplicazione delle informazioni sia generalmente una cosa negativa e dovrebbe essere evitata quando possibile. Immagina una tabella "Problemi" nel database bug-tracker. Ogni record in questa tabella dovrebbe rappresentare un problema univoco. Quando aggiungi il secondo record per lo stesso bug, in realtà inizia a rappresentare non un bug in sé, ma il fatto che alcuni utenti lo abbiano scoperto e pubblicato in data e ora. Quello che è successo in realtà è che hai postato alcune informazioni aggiuntive sul problema esistente. Queste informazioni dovrebbero essere archiviate in luoghi diversi, come la tabella "IssueComments" o qualcosa del genere.

Dal mio punto di vista, la negromanzia è meno cattiva. Se la negromanzia è un problema, dovremmo combattere con qualcosa che causa un problema, non con la necromanzia stessa (se hai trovato qualche nuova informazione sul vecchio bug, cosa c'è di sbagliato in questo? È totalmente naturale). Ad esempio, se qualcuno pubblica commenti sul vecchio bug chiuso, questo dovrebbe in qualche modo catturare l'attenzione di tutti gli utenti interessati.

Forse potresti aprire una nuova segnalazione di bug e collegarla a quella vecchia. Giustifica le tue ragioni per voler risolverlo. Potrebbe essere il caso che la correzione interrompa il comportamento esistente (compatibilità binaria o modifica del modo in cui devono funzionare con l'applicazione) e risolverlo potrebbe causare più problemi di quanti ne valga. Se la correzione avrebbe un impatto minimo, potrebbero non esserci obiezioni alla sua risoluzione.

Devi vedere esattamente perché è stato deciso di non risolvere in primo luogo.

Direi che differisce tra bug e richiesta di funzionalità.

Quando crei una segnalazione di bug in bugtracker, di solito descrivi i sintomi. Tuttavia, non significa che la causa sottostante sia uguale o addirittura simile. Soprattutto se gli interni sono ben nascosti all'utente finale e tutto quello che ottieni è un errore generico quando qualcosa è andato storto. In questi casi la negromanzia non è la strada da percorrere, in quanto, sebbene i sintomi esterni possano sembrare simili, è molto probabilmente un bug completamente diverso. Se riaprirai un vecchio bug, lo sviluppatore probabilmente inizierà a indagare sulla vecchia causa, che potrebbe portarlo in una direzione sbagliata e in un tempo libero.

Per la richiesta di funzionalità che è stata respinta e i motivi di rigetto non sono più validi, direi che la negromanzia è la strada da percorrere. In questo caso sai che creando un nuovo ticket creerai un duplicato esatto.