错误跟踪礼节-尸体鉴定或重复？

我在一个开源项目的错误跟踪器中遇到了一个非常古老（超过2年）的功能请求问题，由于缺少进行请求的增强功能所需的工具，该项目被标记为“已解决（无法修复）”。自从确定以来经过的时间，已经开发了可以解决该问题的新工具，在此，我希望引起社区的注意。

但是，我不确定在这种情况下错误跟踪的普遍接受的礼节是什么。显然，如果系统明确声明不重复，并且会主动将新项目标记为重复（这与SE网站的做法大同小异），那么答案将是遵循系统所说的。但是，当系统没有明确说出这样的意思，或者新用户无法轻松找到具有系统偏好的地方时该怎么办呢？通常认为在重复或死法方面更佳吗？根据是错误还是功能请求而有所不同吗？

唯一能充分回答这个问题的是您的组织流程。如果未定义这种情况，则应对其进行定义，以便每次发生时都保持一致。

我建议重新打开旧版本，并在适当时向其中添加新信息。从度量/度量的角度看，这可能是危害最小的-新事物不是新的缺陷或增强，而是重新探究旧的缺陷或增强。对于传入的更改请求，应该有某种状态，表明无论负责方是谁，都需要对其进行审核。通过将状态更改回此状态，他们可以轻松查看历史记录（以前曾经推迟过一次的事实），还可以轻松查看新信息。

我要做的（过去所做的）是创建一个新的bug（以使其具有相关性），记下可能的/新的修复程序，并链接到旧的以进行历史参考/跟踪。

它也取决于该错误……该错误现在可能是“功能”，或者是人们已经使用了两年的完善的变通方法，而这些变通方法可能会被修复所破坏。

基本上，您确实必须深入研究并调查该错误和潜在的修复程序，如果您仍然认为应该修复该错误，请记录该错误。

作为一名程序员，我认为信息复制通常是一件坏事，应尽可能避免。想象一下错误跟踪数据库中的“问题”表。该表中的每个记录应代表一个唯一的问题。当您为相同的错误添加第二条记录时，它实际上并不是开始代表错误本身，而是某个用户发现它并在某个日期和时间发布的事实。实际发生的是您发布了一些有关现有问题的其他信息。此信息应存储在其他位置，例如“ IssueComments”表或类似的地方。

从我的角度来看，死灵法术不那么邪恶。如果死灵法术是个问题，我们应该与引起问题的事物作斗争，而不是与死灵法术本身作斗争（如果您发现了一些有关旧错误的新信息，那是怎么回事？这很自然）。例如，如果某人对旧的已关闭的错误发表评论，则应该以某种方式引起所有感兴趣的用户的注意。

也许您可以打开一个新的错误报告，并将其链接到旧的报告。说明您要修复它的原因。修复程序可能会破坏现有行为（二进制兼容性或更改其与应用程序的工作方式），并且修复此问题可能会引起更多的问题。如果此修复程序影响最小，那么可能没有反对者对其进行修复。

您需要确切地了解为什么决定不首先解决它。

我想说，错误和功能请求之间是不同的。

在bugtracker中创建错误报告时，通常是在描述症状。但是，这并不意味着根本原因相同或什至相似。特别是如果内部结构对于最终用户而言是很好的隐藏对象，那么当出现问题时，您得到的只是一般错误。在这种情况下，死法不是解决之道，尽管尽管外部症状看起来很相似，但很可能是完全不同的错误。如果您要重新打开旧错误，则开发人员可能会开始调查旧原因，这可能会导致他朝完全错误的方向前进并浪费时间。

对于已被拒绝且拒绝原因不再有效的功能请求，我想说要死法。在这种情况下，您知道创建新故障单将要创建完全相同的副本。