Perché citare gli ID bug nelle note della patch potrebbe essere considerato una cattiva pratica?

28

Sulla base di un commento e dei successivi voti da Bug riaperti rispetto a nuovi :

Citando gli ID dei bug nelle note della patch è solo ... molto ostile. - Krelp

Sembra che almeno alcune persone ritengano che fare riferimento agli ID dei bug nelle note della patch non sia una buona idea. Sono uno sviluppatore abbastanza inesperto, quindi mi chiedo perché sia così.

issue-tracking bug-report software-patches

— Travis Northcutt
fonte

27

non citare gli ID dei bug nelle note della patch è solo ... molto poco professionale. Un po 'di trasgressione il punto di avere un tracker di problemi

— moscerino del

Lo stesso motivo per cui la pubblicazione di collegamenti solo come risposte StackExchange è disapprovato - se pubblichi solo un collegamento, su SE è un male perché (1) richiede di seguire per ottenere una spiegazione e (2) potrebbe diventare non valido in futuro se il il collegamento si interrompe o il contenuto cambia. Allo stesso modo, inserire solo gli ID bug nelle note patch (1) richiede di andare al tracker bug per ottenere una spiegazione e (2) potrebbe diventare non valido in futuro se il sistema di tracker bug cambia. Includere un collegamento in una risposta SE o un ID bug in una nota della patch va bene (e in realtà è una buona pratica) come aggiunta a una spiegazione regolare.

— Ben Lee,

51

Secondo me, è una buona pratica, supponendo che i tuoi utenti abbiano accesso in lettura al tuo database di bug. Ci sono molte volte in cui le persone sono in attesa di correggere un determinato bug per decidere quando eseguire l'aggiornamento.

Penso che ciò che è disapprovato sia solo citando l'id bug e nient'altro. Dovresti sempre fornire anche una descrizione comprensibile senza andare al bug tracker. Ciò consente anche di cambiare il tracker dei bug in futuro senza invalidare completamente le note di rilascio precedenti.

— Karl Bielefeldt
fonte

Puoi citare tramite un risolutore di riferimenti astratto, noto anche come reindirizzamento URL.

— Donal Fellows,

Come dici tu, la sezione "Bug corretti" (o simili) dovrebbe includere l'ID e il titolo in modo che il lettore non debba cercare il bug per capire esattamente cosa è incluso e cosa no.

— Stuper:

5

@StuperUser - Id e titolo, come minimo .

— Oded,

Ciò che è fastidioso è trovare le annotazioni dell'ID bug solo nei commenti quando il sistema ID bug / requisito referenziato non è più in uso.

— jfrankcarr,

14

È, come detto nel commento citato ... ostile.

Scostante con te stesso

Immagina il seguente scenario. Stai visualizzando i log nel controllo del codice sorgente. Ti stai chiedendo cosa sia cambiato un commit. Invece di spiegarlo in un inglese semplice, ti dice:

Risolto # 1307

Gestisci il sistema di tracciamento dei bug, sperando di avere qualcosa di utile. Il bug n. 1307 è stato risolto. Nella descrizione, vedi:

Stesso bug del n. 1284

Grazie, è molto utile. Devi ora passare alla segnalazione bug # 1284 per leggere che è un duplicato del bug # 1113 che si riferisce ai bug # 1112, # 1065 e # 1067.

Cinque minuti dopo, non hai idea di cosa cerchi all'inizio.

Un messaggio di registro di controllo versione molto più utile sarebbe:

Risolto il problema per cui gli utenti non potevano accedere con una password più lunga di 25 caratteri (vedi # 1307), rimuovendo l'applicazione dello stesso criterio di lunghezza della password al livello di accesso ai dati di quello utilizzato nel sito Web stesso.

Allo stesso modo, nel sistema di tracciamento dei bug, il rapporto n. 1307 potrebbe essere più autoesplicativo , ricordando di cosa trattava il rapporto sui bug n. 1284 e in che modo quello nuovo è diverso da quello vecchio.

Inospitale con i clienti

Questo non è l'unico problema di amicizia.

Un secondo è che facendo riferimento a troppo senza informazioni aggiuntive, si rendono inutilizzabili le note sulle patch / i registri di controllo della versione / i rapporti sul sistema di tracciamento dei bug per qualcuno che non ha molta familiarità con tali sistemi . Quando ti occupi quotidianamente di un sistema di tracciamento dei bug, sai come navigare rapidamente tra i rapporti, visualizzare più rapporti fianco a fianco, ecc. Quando sei un cliente senza background tecnico, puoi facilmente perderti.

Anche in questo caso, messaggi più dettagliati sono molto utili di un semplice riferimento. Nota che vuoi comunque conservare i riferimenti: niente è più sbagliato di un bug che è lo stesso di un bug che hai riscontrato due settimane fa, ma non ricordare il suo ID.

Come nota, lo stesso problema esiste in molte giurisdizioni. In Francia, ad esempio, non è insolito che una legislazione faccia riferimento a più fonti, che potrebbero cambiare nel frattempo. Ciò significa che per comprenderlo completamente, a volte devi trascorrere ore in una biblioteca, alla ricerca di dozzine di testi citati, ognuno dei quali ha i suoi riferimenti ad altri.

— Arseni Mourzenko
fonte

5

Questo non è un problema con il documento di rilascio; questo è un problema con il livello di dettaglio nei bug. Un titolo dovrebbe descrivere il problema reale e il corpo di ciascun bug ha il risultato atteso e il risultato effettivo. I bug come hai descritto non dovrebbero essere chiusi come duplicati?

— Stuper:

Basato sulla tua modifica. Hai citato l'ID nel tuo messaggio molto più utile. Nel tuo commento originale intendevi dire che citare SOLO gli ID senza ulteriori informazioni non è utile, mentre una spiegazione corretta E l'id è utile?

— Stuper:

1

@StuperUser: esattamente. Fornire spiegazioni aiuta le persone che vogliono solo sapere di cosa tratta il registro di commit / la nota della patch / la segnalazione di bug, senza spendere dieci minuti a leggere il contenuto a cui si fa riferimento. Gli ID sono ancora necessari per il monitoraggio e le persone che necessitano di informazioni molto dettagliate, precise e complete.

— Arseni Mourzenko,

2

Non c'è nulla di sbagliato nel citare i numeri di problema nelle note della patch, a condizione che gli utenti possano leggere il problema che viene citato. Se il tuo database di bug consente a chiunque di leggere, citare il numero di bug può essere davvero molto utile. (Ancora meglio, se le note della patch sono in un formato che consente i collegamenti, fare in modo che tali ID dei problemi siano collegamenti al problema in questione.) Ciò non significa che è necessario esporre tutti i problemi al pubblico; può ancora essere utile avere quelli che sono protetti (ad esempio, dove hanno password live!)

Citando un numero di problema in cui la persona che legge non può andare a cercare i dettagli e la cronologia del bug, è abbastanza ostile. Non è molto più facile citare tali problemi senza l'ID problema.

— Donal Fellows
fonte

"dove la persona che legge non può andare a cercare i dettagli" come una persona che è stata una tale persona , non la definirei davvero ostile. Ho usato l'ID problema per comunicare con il team di supporto / sviluppo che a sua volta aveva accesso al tracker dei problemi. Il fatto che fosse invisibile per me personalmente era solo un piccolo fastidio

— moscerino del

2

Dipende ovviamente da chi sono le persone che leggeranno le note della patch e dagli utenti target del software.

Ma nella maggior parte dei casi, la stragrande maggioranza dei tuoi utenti semplicemente non si preoccupa di quale sia l'ID bug. A loro non importa perché sia stato risolto, quale sia la correzione o qualcos'altro: vogliono solo sapere cosa è cambiato con una descrizione testuale molto concisa senza dover passare a un'altra pagina per ogni modifica.

Citare gli ID dei bug mi fa fermare e pensare, e io - come utente - non voglio pensare. È una specie di problema di usabilità.

Date un'occhiata ad esempio al registro delle modifiche Visual Assist X . Tutti quegli ID bug collegati sono solo rumori che mi distraggono dalla comprensione di ciò che è cambiato. E questo è un componente aggiuntivo per Visual Studio, destinato ai programmatori. E sono un programmatore. Se questo mi disturba, immagina l'utente medio che non sa nemmeno cosa sia un tracker di bug.

PS: sono stato l'autore del commento che ha suscitato la domanda

— Thomas Bonini
fonte

1

Onestamente trovo utile la documentazione alla fine di quel link. Si inizia con un riepilogo e poi mi indirizza ai dettagli. Microsoft fa spesso un collegamento simile negli articoli KB, non che il loro farlo lo renda una buona pratica, ma è certamente molto diffuso e apparentemente fornisce valore a molti utenti.

— Joshua Drake,

1

Un ID bug è obbligatorio per un punto di riferimento . Le ragioni:

Prevenire l'ambiguità: due o più bug potrebbero avere descrizioni simili. Quindi sarebbe necessario un po 'di ancoraggio per distinguerli.
Convenienza : quando si discute di un bug, con un cliente o internamente, l'ID bug viene spesso utilizzato come forma abbreviata. Se l'ID verrà omesso dalle note della patch, sarà difficile discuterne:

Il 3052 era già stato riparato, funzionando ancora sul 3077

è più conveniente di:

Il "crash dell'applicazione sul pulsante Applica" è stato corretto, funzionando ancora su "NullReferenceException facendo clic su cambia utente"

— KMoraz
fonte

(1) Cosa ti impedisce di combinarlo, come suggerito da MainMa? (2) Perché commetti un bug e mezzo risolto? Perché non ti impegni dopo che il 3052 è stato corretto, prima ancora di iniziare a lavorare sul 3077?

— JensG,

0

Direi che dipende dal tuo sistema: sono fortunato che quello che uso rilevi automaticamente tali riferimenti nei messaggi di commit e aggiunga un link al ticket memorizzato nel bug tracker, quindi non è un problema.

Ma se fossi su un sistema in cui non è disponibile, menzionerei comunque l'ID del biglietto (in questo modo puoi cercare rapidamente nei registri per ID del biglietto ) insieme a una breve descrizione di ciò che il bug è.

— wildpeaks
fonte