不论你是否把它们称作bug、缺陷、设计副作用，你都无法摆脱它们。知道如何提交一个优秀的bug反馈以及在某方面需要什么，是保持项目顺利推进的关键技能。
一个优秀的bug反馈需要做到三件事：
- 如何复现bug，尽可能地清晰描述，以及它出现的频率。
- 理论上应该发生什么，起码在你看来会发生什么。
- 实际上又发生了什么，或者至少记录下你所掌握的更多信息。
关于bug反馈信息的数量和质量，要做到和反馈者所掌握的一样多。愤怒地反馈个简短的bug(“这个函数太烂了！”)除了告诉开发者你此刻很糟糕以外，没什么卵用。一个含有充足上下文的bug可以更容易被复现而赢得大家的尊重，即使它已停止发布。
变更bug的状态，例如打开-关闭，这是你对bug思考的公开声明。花点时间解释为何你觉得bug应该被关闭，可以挽回在恼怒的经理和消费者面前辩解的时间。变更bug的优先级也类似于一份公开声明，仅仅是因为它对你来说微不足道，但并不意味着它会让其他人停止使用该产品。
不要为了你自己的目的就去重载一个bug字段。将“VITAL:”添加为bug主题的字段可能有利于你对一些报告结果做排序，但它也将被其他人复制并难以避免拼写出错，或者在其他报告中将其删除。使用一个新值或新字段来代替，并用文档记录字段该如何使用，以便他人不必重复。
确保每个人都知道如何找出团队认可的bug以被处理。通常可以采用一个公共的查询名称。确保每个人都采用相同的查询方式，在没有事先通知团队你已经改变了某些内容的情况下，不要更新此查询。
最后，记住bug不是工作的一个标准单元，只是一行代码的精确测量。
