In un progetto che sta facendo un uso attivo del tracciatore di bug, c'è sempre un pericolo che il tracciatore si trasformi esso stesso in un forum di discussione, anche se la mailing list sarebbe in realtà migliore. Di solito si incomincia abbastanza innocentemente: qualcuno annota un problema con una, diciamo, soluzione proposta, e fa seguire un altra annotazione che indica problemi. La prima persona risponde, ancora aggiungendosi al problema...e va così.
Il problema con questo è, primo, che il tracciatore di bug è un luogo piuttosto ingombrante per tenervi una discussione, e secondo, che altre persone possono non farvi attenzione—dopotutto essi si aspettano che che la discussione dello sviluppo avvengano sulla mailing list dello sviluppo, così è lì che guardano per essa. Essi possono non essere per nulla iscritti alla mailing list dei cambiamenti dei problemi, e anche se lo sono, possono non seguirla molto da vicino.
Ma esattamente dove nel processo è andata sbagliata qualcosa? Fu quando la persona d'origine aggiunse la sua soluzione al problema—dovrebbe aver postato nella mailing list invece? O fu quando la seconda persona rispose nel problema, invece che sulla mailing list?
Non esiste una risposta giusta, ma c'è un principio generale: se state appunto aggiungendo dati a un problema, allora fatelo nel tracciatore, ma se state incominciando una conversazione, allora fatelo nella mailing list. Potete non essere sempre in grado di dire quale è il caso, ma usate appunto il miglior giudizio. Per esempio, quando state aggiungendo una patch con una soluzione potenzialmente controversa, potreste essere in grado di anticipare che la gente sta per avere una domanda su di essa. Così anche se normalmente aggiungereste la patch al problema (ipotizzando che non volete o non potete fare l'invio del cambiamento direttamente), in questo caso potreste invece scegliere di postarla alla mailing list. In ogni caso, alla fine lì verrà il momento nello scambio in cui una parte o l'altra può dire che è sul punto di passare dalla sola aggiunta di dati a una reale conversazione—nell'esempio che incominciò questa sezione, che sarebbe la seconda persona che risponde, colui che si rendeva conto che c'erano problemi con la patch, poté predire che stava per seguire una conversazione reale, e che quindi avrebbe dovuto essere tenuta sul mezzo appropriato.
Per usare una analogia matematica, se sembra che l'informazione sarà rapidamente convergente, allora mettetela direttamente nel tracciatore di bug; se sembra che sarà divergente allora una mailing list o un canale IRC può essere un posto migliore.
Ciò non significa che non ci dovrebbe mai essere scambio nel tracciatore di bug. Chiedere maggiori dettagli per la ricetta di riproduzione da chi ha fatto il report all'origine tende ad essere un processo altamente convergente, per esempio. E' improbabile che la risposta della persona sollevi nuovi problemi; è semplicemente fornire maggiori dettagli sull'informazione già archiviata. Non c'è bisogno di distrarre la mailing list con quel procedimento. Abbiate cura con ogni mezzo di ciò con una serie di commenti nel tracciatore. Allo stesso modo, se siete abbastanza sicuri che il bug è stato riportato male (cioè, non è un bug), allora potete semplicemente dirlo così bene nel problema. Anche indicare un problema minore con una soluzione proposta è bene, nell'ipotesi che il problema non sia un pezzo di una rappresentazione che suscita applausi per la risoluzione completa.
D'altra parte, se state sollevando dei problemi filosofici sulla portata del bug o sull'appropriato comportamento del software, potete essere abbastanza sicuri che gli altri sviluppatori vorranno essere coinvolti. Sembra che la discussione diverga per un momento prima di convergere, così tenetela nella mailing list.
Linkate sempre all'argomento della mailing list dal problema, quando scegliete di postare alla mailing list. E anche importante per qualcuno che sta seguendo il problema essere capace di raggiungere la discussione. La persona che inizia il thread può trovare ciò laborioso, ma l'open source è fondamentalmente una responsabilità di chi scrive. E' molto più importante rendere facili le cose per le decine di centinaia di persone che possono leggere il bug, che per le tre o cinque persone che scrivono intorno ad esso.
E' bene trarre importanti conclusioni o sommari dalla discussione sulla mailing list e incollarle nel problema, se ciò renderà le cose convenienti per i lettori. Deve iniziare una discussione sulla mailing list un comune idioma, mettete un link al thread nel problema, e poi quando la discussione finisce, incollate il sommario finale nel problema (insieme con un link al messaggio contenente il sommario), così chi osserva il problema possa vedere quale conclusione sia stata raggiunta senza dover cliccare da qualche altra parte. Notate che di solito il problema della duplicazione dei dati da ”due capi” non esiste qui, perché ambedue gli archivi e i commenti al problema di solito sono statici, dati che non è possibile cambiare in nessun modo.