每个工单——一个bug报告或一个功能请求——都是一份短期合同。你，作为报告人，雇佣他们来修复bug或实现一个功能。他们，作为开发团队，会为你做这件事——只要你付款，或者他们的动机是内在的——比如在开源项目中。沿途发生的讨论可能有助于澄清合同的要求。它也可能帮助团队说服你，这个bug不值得修复。此外，它还可能帮助他们向你交付修复方案，并说服你关闭工单。然而，如果讨论失去焦点，讨论也可能会分散双方注意力。
事情是这样发生的：
实际上，缺失的标题行也可能是一个错误。它与您刚刚报告的问题有关—但它不是您与团队建立的合同的一部分。回答您的问题可能会让他们分心，模糊他们的注意力。您不希望这样。您希望他们专注于手头的问题。
再来几个好的食谱来让他们分心：
顺便说一句，为什么这段代码设计成这样呢？
顺便说一句，我想知道，这是如何运作的？
所有这些问题、投诉和建议都是新的错误报告的完美候选者。
你可能会认为一个工单是与团队交流的机会。他们已经在回复了—那么在他们注意力在此时为什么不问所有你的问题呢？感觉他们很感兴趣，所以你不想失去这种动力。但这是一个错误的假设。他们没有动力继续讨论。他们真正想要的是关闭工单—尽快。拖延对话只会惹恼他们。
你可能还认为提交工单会冒犯团队。他们已经有很多工作要做—为什么要用更多的事情来打扰他们呢？每一个错误报告或功能请求似乎都像是给他们额外的负担。但同样，这是一个错误的信念。错误报告是他们引擎的燃料。他们需要你的工单。首先，因为它们有助于澄清需求。其次，因为它们提供了一种他们的工作是需要和被赏识的感觉。对软件团队来说，没有什么比一个沉默的客户和一个空的错误跟踪器更糟糕的了。
所以，在工单中与团队交流时，避免说“顺便说一下”。坚持要求修复你最初报告的错误。如果在沟通过程中有其他想法—无论是问题、另一个错误或功能请求—请提交一个新工单。我们–还有Mozilla–相信每一个工单都应该是一个错误报告。
你可能还考虑将对话转移到邮件列表，正如Karl Fogel建议的。甚至是到Slack或Telegram。但我不建议这样做。
Translated by ChatGPT gpt-3.5-turbo/42 on 2025-05-18 at 11:34
