一個有趣的問題最近發生的，我一直在思考的「最佳」的方式（爲「最佳」給定值）來實現這一點。源核心庫和便籤
從本質上講，它是對源代碼的跟蹤音符之一。舉例來說，這是一個在SLA中實時解決的問題，以及如何最好地實現這一點。沒有深入所有的細節，它找到了一個功能，在一些地方使用，可能會或可能不是越野車，但問題是隻在一個位置報告。
滿足服務水平協議的修復只是增加一個檢查到哪裏的問題報告，而不是調整的通用代碼，並有測試觸及該函數一切的位置。
有趣的問題是上游。然後，「正確」方法將返回並檢查原始函數，在所調用的每個位置驗證它是否正確，然後在確定庫函數錯誤時進行「正確」更改。
問題是這需要時間，所以上游可能只是採取解決方法，等等。但是，如果問題再次發生（例如六個月後）在另一個位置調用相同的庫函數，有沒有一種簡單的方法將這兩個問題聯繫在一起。您可以搜索錯誤跟蹤數據庫，但這無法幫助 - 這取決於是否添加了一條註釋，說明「此庫函數需要更徹底的檢查，但現在沒有時間進行調查」。
所以問題是這樣的：在一個龐大的開發團隊（30多人，分成支持和正在進行的開發團隊）內，您使用什麼方法來管理（有效的）「粘滯便箋」源代碼，缺少添加評論到可疑功能的源代碼說「這可能有點狡猾」？
與commiting評論的問題是處理中的一個：變化是發生變化，從而提交了零變化的變化（即，一個其中加入剛剛評論）是不理想;開發者甚至可以在添加註釋時發生錯誤（碰到流浪的鍵或其他東西），因此只有在進行實際更改時纔會提交（）總是（IMO）更好。
現在一個wiki可以用來跟蹤每個文件的註釋，但是我們至少有四個分支和幾百個文件（SQL對象，源代碼，XML文件等），所以一個wiki會很快變得不可用。
這是一種很好的事情，如果SCM能夠支持 - 元數據針對僅僅是筆記的文件，但不會添加到SCM的版本歷史記錄 - 可以在做（比如說）一個svn update，或手動查看。
有可能已經在那裏的解決方案 - 那麼你如何管理這種類型的知識共享？