# Bug跟蹤系統中無對話 對于積極使用bug跟蹤系統的項目，要小心它變成討論論壇，雖然郵件列表可能更好。通常情況下，它總是很無辜的開始的：某人評論了某個問題，例如提出了一個解決方案或部分補丁。另一個人注意到這個，認為這個方案有些問題，所以附加了另一個評論指出這個問題。第一個人再次回應，對問題作出補充，就這樣一直繼續下去。 這樣做的問題是，首先，bug跟蹤系統用于討論時非常的笨拙，其次，其他人可能不會投入關注—畢竟，他們希望在郵件列表中進行開發討論，這也是他們查找問題的地方。他們可能沒有訂閱問題變更列表，即使訂閱了，也不可能緊跟所有的變化。 但是這個過程中到底何時出了差錯？是不是那個人將自己的解決方案附加到問題時—她是不是應該發布到列表中？或者是當第二個人直接回復這個問題，而不是在列表回復時。 這里沒有正確的答案，但是有一般的原理：如果你僅僅是為問題添加數據，那么請在跟蹤系統中操作，但是如果你想發起一次*對話*，那么請到郵件列表。不是每次都能判斷出是哪種情況，但是你要作出最佳的判斷。例如，當你提交的補丁會包含反對的解決方案時，你應當會預期有人會對此發出質疑。所以，即使你會自然的為該問題附加這個補丁（假定你不希望或者不能直接提交修改），也應當選擇將其發布到郵件列表。有一定的可能性，整個交流最終會有得出結果，某一方可能會說應該不僅僅是追加數據，而應該開始一場討論了—在本小節開頭的例子中，也就是第二個回復者，他認識到了補丁的問題，預測到將會有真實的交流發生，因而應該通過更合適的媒介完成。 用數學模擬來說，如果根據信息顯示問題將會很快收斂，那么直接在bug跟蹤系統中發布；如果看起來將會發散，那么郵件列表或IRC頻道將會是更好的地方。 并不是說在bug跟蹤系統中不能有任何交流。例如，向原報告者詢問重現的步驟細節就一般是一個很容易收斂的過程。人們的回應并不是提出新的問題，而僅僅是澄清已經記錄的問題。沒有必要分散郵件列表的注意力；并不一定要通過小心跟蹤系統中一系列的評論實現。同樣的，如果你認為這個bug是誤報的（例如，根本就不是一個bug），你只需要在問題中說出來。甚至指出解決方案中的些許缺陷也沒有問題，只要該缺陷不會影響整個解決方案。 另一方面，如果你會在bug的范圍或軟件正確行為方式方面，指出哲學問題，你肯定會認為將有其他開發者參與。討論也許會發散一段時間，那么請在郵件列表中完成。 如果選擇了郵件列表，就一直要在問題中保存到郵件列表討論的鏈接。對于查看問題的人，能看到對應的討論是非常重要的，即使問題本身不是討論的場所。發起這個線索的人會發現有點牽強，但是開源從根本上說就是一種撰寫-回應的文化：讓成千上萬的人讀起bug來更容易，遠比三五個編寫者的麻煩重要的多。 如果可以讓讀者更便利，可以將重要的結論或總結從郵件列表中粘貼到問題中。一個常見的習俗是開始一個列表討論，在問題中附加討論線索的鏈接，然后是討論結束的時間，粘貼最終的總結（以及包含總結信息的鏈接），這樣瀏覽此問題的人就可以輕松的看到已經得出的結論，而無需點擊到其他地方。需要注意的是，這里不存在重復數據的問題，因為歸檔和問題回復都是通常是靜態的，不會改變的數據。