刚才发生了什么事？
当然，我不是真的想要更改文档上。如果那个开发人员接受了我的吓唬并且修改了文档而不是代码，由于不可否认得已经做了改进，我将标记这个错误为已修复。然后我会在提交另外一个抱怨由于欺骗的错误影响系统可用性的bug report，或许我会报告一个改进的要求。在这一点上，我只是期望只要一会就可以修复错误，但是我知道我自己至少是尽力了。
应该提及的是如果你没有好的最终用户文档这个方法是不起作用的。我曾经花了大量的时间测试特别为开发人员编写的，详细的应用系统编程的接口（API）。和我一起工作的开发同事想用这个API文档代替功能说明，所以这个额外的动机能够使其保持准确。如果你还没有最终用户的文档，你仍然要去查找其他可能提及这个行为的文档－可能是设计文档或者是错误信息本身。
让他们思考
例如，我报告了一个关于开源字处理器的工具－AbiWord的＃3639错误（更多信息参考在表1中的 “Triggering Change”错误的主要描述）。在一个早前的bug report中（＃3619），我已经抱怨了AbiWord不能够导入各种类型的html文档。由于AbiWord只期望导入xhtml文件，因此它不能够导入html格式的文件，除非安装另外的插件，所以这个错误作为无效的错误被关闭了。
作为一个bug的拥护者，我应该为这个结果感到高兴吗？当然不是！我瞄准了容易产生误解的错误信息。作为一个不知道导入html插件的用户，我找到了引起混淆的错误信息：