在对某个版本的bug进行分类时，通常会使用什么标准来确定是否会针对该版本修复该错误？
答案 0 :(得分：27)
有关这方面的文章是My life as a Code Economist，Eric Sink。
真的值得一读这篇文章，但是如果你想在一份清单中总结出来的话：
答案 1 :(得分：5)
答案 2 :(得分：2)
如果严重程度较低且产品即将发布，我们会经常发现，最好将修复程序保存到下一个版本中。
让沉睡的狗躺在原则上。
需要锁定代码。代码修复需要进一步的回归测试，这需要时间。
伤心但真实。
答案 3 :(得分：2)
“零缺陷”心态还有很多要说的。任何类型的错误都应该总是到达堆栈顶部，或者最终它们会让你感到压力。
当然，在现实世界中，获得那个闪亮的新功能，所以你可以赢得那个大新客户可能比修复一些轻微的烦恼更重要。上市时间确实有时会超过质量。
答案 4 :(得分：1)
通常具有重要性，影响力和金钱。
答案 5 :(得分：1)
这绝对是一个特定领域的问题。我为Hedge Funds，Prop Trading Desk，Mutual Funds等编写大型交易应用程序，所以：
前几天，我确实在一个不同领域工作的'Bug Triage Manager'谈过。他简单地说：
首先我修复了崩溃，然后我修复了导致我们赔钱的事情，然后我解决了让我们看起来很糟糕的事情，然后我解决了其他问题。
答案 6 :(得分：1)
影响严重程度的事情我在这篇文章中还没有看到。
答案 7 :(得分：0)
根据我的经验，它只是：
答案 8 :(得分：0)
我编写RDBMS服务器软件，因此任何可能导致数据损坏的错误都会立即显示出来。此外，任何可能导致数据库服务器在相对正常使用下崩溃的错误都将符合条件，因为从查询中返回不正确的数据。
它还必须依赖于修复的不稳定性以及需要多长时间。
答案 9 :(得分：0)
作为一项规则，我们将修补任何在发布周期之外崩溃系统的错误。
任何其他错误都会添加到产品backlog中，并且会与新功能一起优先处理。在确定发布中的内容时，我们只需要具有最高优先级的任务。这对我们很有用，因为我们有每月发布周期。
我们使用与此线程上其他人提到的错误优先级相同的系统，除了客户端可以支付以提高错误（或功能）优先级的额外例外。
答案 10 :(得分：0)
是否值得进入technical debt，不修复它，或做一个快速而肮脏的修复，以便以后正确修复它。
答案 11 :(得分：0)
已经有很多很棒的答案，当然情况会有所不同，具体取决于项目/公司/错误/发布时间/依赖性/...
但我发现以下两个指标是一个有用的指南。
两个变量上标记的bug越高，就应该越早修复。
答案 12 :(得分：0)
我同意@Chris Upchurch，但我认为一个关键因素是在你进入崩溃时间之前得到各方的同意。这样，你可以用最少的牙齿咬牙切齿和胸部撞击来减少你的检查清单。
答案 13 :(得分：0)
在做出决定方面，不能根据严重程度，影响，成本等提出最佳答案。
时，您需要谨慎使用这些规则。 我曾经做过很多项目，因为它们不是任何责任，因此会让错误失控。我想出的最好的工作规则是
那么。