一个有趣的问题最近发生的，我一直在思考的“最佳”的方式（为“最佳”给定值）来实现这一点。源核心库和便签
从本质上讲，它是对源代码的跟踪音符之一。举例来说，这是一个在SLA中实时解决的问题，以及如何最好地实现这一点。没有深入所有的细节，它找到了一个功能，在一些地方使用，可能会或可能不是越野车，但问题是只在一个位置报告。
满足服务水平协议的修复只是增加一个检查到哪里的问题报告，而不是调整的通用代码，并有测试触及该函数一切的位置。
有趣的问题是上游。然后，“正确”方法将返回并检查原始函数，在所调用的每个位置验证它是否正确，然后在确定库函数错误时进行“正确”更改。
问题是这需要时间，所以上游可能只是采取解决方法，等等。但是，如果问题再次发生（例如六个月后）在另一个位置调用相同的库函数，有没有一种简单的方法将这两个问题联系在一起。您可以搜索错误跟踪数据库，但这无法帮助 - 这取决于是否添加了一条注释，说明“此库函数需要更彻底的检查，但现在没有时间进行调查”。
所以问题是这样的：在一个庞大的开发团队（30多人，分成支持和正在进行的开发团队）内，您使用什么方法来管理（有效的）“粘滞便笺”源代码，缺少添加评论到可疑功能的源代码说“这可能有点狡猾”？
与commiting评论的问题是处理中的一个：变化是发生变化，从而提交了零变化的变化（即，一个其中加入刚刚评论）是不理想;开发者甚至可以在添加注释时发生错误（碰到流浪的键或其他东西），因此只有在进行实际更改时才会提交（）总是（IMO）更好。
现在一个wiki可以用来跟踪每个文件的注释，但是我们至少有四个分支和几百个文件（SQL对象，源代码，XML文件等），所以一个wiki会很快变得不可用。
这是一种很好的事情，如果SCM能够支持 - 元数据针对仅仅是笔记的文件，但不会添加到SCM的版本历史记录 - 可以在做（比如说）一个svn update，或手动查看。
有可能已经在那里的解决方案 - 那么你如何管理这种类型的知识共享？