Etichetta di tracciamento dei bug - Negromanzia o duplicati?

Mi sono imbattuto in un problema di richiesta di funzionalità molto vecchio (2+ anni) in un tracker di bug per un progetto open source che è stato contrassegnato come "risolto (non risolto)" a causa della mancanza di strumenti necessari per apportare il miglioramento richiesto. Nel tempo trascorso da quando è stata presa quella determinazione, sono stati sviluppati nuovi strumenti che gli permetterebbero di essere risolti e vorrei portarlo all'attenzione della comunità per quella applicazione.

Tuttavia, non sono sicuro di quale sia l'etichetta generalmente accettata per il bug tracking in casi come questo. Ovviamente, se il sistema afferma esplicitamente di non duplicare e contrassegna attivamente nuovi elementi come duplicati (molto nel modo in cui lo fanno i siti SE), la risposta sarebbe seguire ciò che dice il sistema. Ma che dire quando il sistema non lo dice esplicitamente, o un nuovo utente non riesce a trovare facilmente un posto che dice con le preferenze del sistema? È generalmente considerato meglio sbagliare dal punto di vista della duplicazione o della negromanzia? Questo differisce a seconda che si tratti di un bug o di una richiesta di funzionalità?

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.

Consiglierei di riaprire quello vecchio e aggiungere nuove informazioni ad esso come appropriato. Dal punto di vista delle misurazioni / metriche, questo sarebbe probabilmente il meno dannoso: la nuova cosa non è un nuovo difetto o miglioramento, ma piuttosto rivisitare uno vecchio. Dovrebbe esserci uno stato per le richieste di modifica in arrivo che indica che deve essere esaminato da chiunque sia la parte responsabile. Riportando lo stato su questo, possono vedere la storia (il fatto che era stato rinviato una volta prima) ma anche le nuove informazioni facilmente.

Quello che farei (e l'avrei fatto in passato) è creare un nuovo bug (per dargli rilevanza), annotare la possibile / nuova correzione e collegarlo a quello vecchio per riferimento / tracciamento storico.

dipende anche dal bug ... quel bug potrebbe essere una "caratteristica" ora, o avere delle soluzioni ben consolidate che le persone usano da 2 anni e che sarebbero state interrotte da una correzione.

Fondamentalmente, devi davvero scavare e investigare il bug e la potenziale correzione, e se pensi ancora che debba essere corretto, 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 unico. Quando aggiungi il secondo record per lo stesso bug, in realtà inizia a rappresentare non un bug stesso, ma il fatto che alcuni utenti lo abbiano scoperto e pubblicato in una data e ora. Quello che è realmente accaduto è che hai pubblicato 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 malvagia. Se la negromanzia è un problema, dovremmo combattere con qualcosa che causa un problema, non con la negromanzia stessa (se hai trovato alcune nuove informazioni sul vecchio bug, cosa c'è che non va? È del tutto naturale). Ad esempio, se qualcuno pubblica commenti su vecchi bug chiusi, 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 precedente. Giustifica le tue ragioni per voler risolverlo. È possibile che la correzione rompa il comportamento esistente (compatibilità binaria o cambi il modo in cui devono lavorare con l'applicazione) e correggerla potrebbe causare più problemi di quanto valga la pena. Se la correzione avrebbe un impatto minimo, potrebbero non esserci obiezioni alla sua correzione.

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

Direi che questo differisce tra bug e richiesta di funzionalità.

Quando crei un bug report in bugtracker, di solito descrivi i sintomi. Tuttavia, ciò non significa che la causa sottostante sia uguale o addirittura simile. Soprattutto se gli interni sono ben nascosti all'utente finale e tutto ciò che si ottiene è un errore generico quando qualcosa è andato storto. In questi casi la negromanzia non è la strada da percorrere, poiché un evento, sebbene i sintomi esterni possano sembrare simili, molto probabilmente è un bug completamente diverso. Se riaprissi un vecchio bug, lo sviluppatore probabilmente inizierebbe a indagare sulla vecchia causa, il che potrebbe condurlo nella direzione completamente sbagliata e nel tempo perso.

Per la richiesta di funzionalità che è stata respinta e le ragioni del rifiuto non sono più valide, direi che la negromanzia è la strada da percorrere. In questo caso sai che creando un nuovo ticket creerai un duplicato esatto.