对于积极使用bug跟踪系统的项目，要小心它变成讨论论坛，虽然邮件列表可能更好。通常情况下，它总是很无辜的开始的：某人评论了某个问题，例如提出了一个解决方案或部分补丁。另一个人注意到这个，认为这个方案有些问题，所以附加了另一个评论指出这个问题。第一个人再次回应，对问题作出补充，就这样一直继续下去。

这样做的问题是，首先，bug跟踪系统用于讨论时非常的笨拙，其次，其他人可能不会投入关注—毕竟，他们希望在邮件列表中进行开发讨论，这也是他们查找问题的地方。他们可能没有订阅问题变更列表，即使订阅了，也不可能紧跟所有的变化。

但是这个过程中到底何时出了差错？是不是那个人将自己的解决方案附加到问题时—她是不是应该发布到列表中？或者是当第二个人直接回复这个问题，而不是在列表回复时。

这里没有正确的答案，但是有一般的原理：如果你仅仅是为问题添加数据，那么请在跟踪系统中操作，但是如果你想发起一次对话，那么请到邮件列表。不是每次都能判断出是哪种情况，但是你要作出最佳的判断。例如，当你提交的补丁会包含反对的解决方案时，你应当会预期有人会对此发出质疑。所以，即使你会自然的为该问题附加这个补丁（假定你不希望或者不能直接提交修改），也应当选择将其发布到邮件列表。有一定的可能性，整个交流最终会有得出结果，某一方可能会说应该不仅仅是追加数据，而应该开始一场讨论了—在本小节开头的例子中，也就是第二个回复者，他认识到了补丁的问题，预测到将会有真实的交流发生，因而应该通过更合适的媒介完成。

用数学模拟来说，如果根据信息显示问题将会很快收敛，那么直接在bug跟踪系统中发布；如果看起来将会发散，那么邮件列表或IRC频道将会是更好的地方。

并不是说在bug跟踪系统中不能有任何交流。例如，向原报告者询问重现的步骤细节就一般是一个很容易收敛的过程。人们的回应并不是提出新的问题，而仅仅是澄清已经记录的问题。没有必要分散邮件列表的注意力；并不一定要通过小心跟踪系统中一系列的评论实现。同样的，如果你认为这个bug是误报的（例如，根本就不是一个bug），你只需要在问题中说出来。甚至指出解决方案中的些许缺陷也没有问题，只要该缺陷不会影响整个解决方案。

另一方面，如果你会在bug的范围或软件正确行为方式方面，指出哲学问题，你肯定会认为将有其他开发者参与。讨论也许会发散一段时间，那么请在邮件列表中完成。

如果选择了邮件列表，就一直要在问题中保存到邮件列表讨论的链接。对于查看问题的人，能看到对应的讨论是非常重要的，即使问题本身不是讨论的场所。发起这个线索的人会发现有点牵强，但是开源从根本上说就是一种撰写-回应的文化：让成千上万的人读起bug来更容易，远比三五个编写者的麻烦重要的多。

如果可以让读者更便利，可以将重要的结论或总结从邮件列表中粘贴到问题中。一个常见的习俗是开始一个列表讨论，在问题中附加讨论线索的链接，然后是讨论结束的时间，粘贴最终的总结（以及包含总结信息的链接），这样浏览此问题的人就可以轻松的看到已经得出的结论，而无需点击到其他地方。需要注意的是，这里不存在重复数据的问题，因为归档和问题回复都是通常是静态的，不会改变的数据。