剛才發生了什么事？
當然，我不是真的想要更改文檔上。如果那個開發人員接受了我的嚇唬并且修改了文檔而不是代碼，由于不可否認得已經做了改進，我將標記這個錯誤為已修復。然后我會在提交另外一個抱怨由于欺騙的錯誤影響系統可用性的bug report，或許我會報告一個改進的要求。在這一點上，我只是期望只要一會就可以修復錯誤，但是我知道我自己至少是盡力了。
應該提及的是如果你沒有好的最終用戶文檔這個方法是不起作用的。我曾經花了大量的時間測試特別為開發人員編寫的，詳細的應用系統編程的接口（API）。和我一起工作的開發同事想用這個API文檔代替功能說明，所以這個額外的動機能夠使其保持準確。如果你還沒有最終用戶的文檔，你仍然要去查找其他可能提及這個行為的文檔－可能是設計文檔或者是錯誤信息本身。
讓他們思考
例如，我報告了一個關于開源字處理器的工具－AbiWord的＃3639錯誤（更多信息參考在表1中的 “Triggering Change”錯誤的主要描述）。在一個早前的bug report中（＃3619），我已經抱怨了AbiWord不能夠導入各種類型的html文檔。由于AbiWord只期望導入xhtml文件，因此它不能夠導入html格式的文件，除非安裝另外的插件，所以這個錯誤作為無效的錯誤被關閉了。
作為一個bug的擁護者，我應該為這個結果感到高興嗎？當然不是！我瞄準了容易產生誤解的錯誤信息。作為一個不知道導入html插件的用戶，我找到了引起混淆的錯誤信息：