Etiqueta para rastreamento de bugs - necromancia ou duplicação?

Me deparei com um problema muito antigo (de mais de 2 anos) de solicitação de recurso em um rastreador de erros de um projeto de código aberto marcado como "resolvido (não corrigido)" devido à falta de ferramentas necessárias para fazer o aprimoramento solicitado. No tempo decorrido desde que essa determinação foi feita, novas ferramentas foram desenvolvidas para permitir que ela fosse resolvida, e eu gostaria de chamar a atenção da comunidade para a aplicação.

No entanto, não tenho certeza sobre qual é a etiqueta geralmente aceita para o rastreamento de erros em casos como este. Obviamente, se o sistema declarar explicitamente não duplicar e marcar ativamente novos itens como duplicados (da mesma forma que os sites SE), a resposta seria seguir o que o sistema diz. Mas e quando o sistema não diz isso explicitamente, ou um novo usuário não consegue encontrar facilmente um lugar que diz que é a preferência do sistema? É geralmente considerado melhor cometer erros de duplicação ou necromancia? Isso difere dependendo se é um bug ou uma solicitação de recurso?

A única coisa que pode responder adequadamente a isso é o processo da sua organização. Se essa situação não for definida, ela deve ser definida para que seja consistente sempre que ocorrer.

Eu recomendo reabrir o antigo e adicionar novas informações, conforme apropriado. Do ponto de vista de medições / métricas, isso provavelmente seria o menos prejudicial - a coisa nova não é um novo defeito ou aprimoramento, mas uma nova revisão de um antigo. Deve haver algum estado para solicitações de mudança recebidas que indique que ela precisa ser revisada por quem quer que seja a parte responsável. Ao mudar o estado de volta para isso, eles podem ver o histórico (o fato de ter sido adiado uma vez antes), mas também as novas informações com facilidade.

O que eu faria (e já fiz no passado) é criar um novo bug (para dar relevância), anotar a possível / nova correção e vincular à antiga para referência / rastreamento histórico.

isso também depende do bug ... esse bug pode ser um "recurso" agora ou ter soluções bem estabelecidas que as pessoas usem há 2 anos que seriam quebradas por uma correção.

Basicamente, você realmente precisa pesquisar e investigar o bug e a possível correção, e se você ainda acha que deve ser corrigido, registre o bug.

Como programador, acho que a duplicação de informações geralmente é uma coisa ruim e deve ser evitada sempre que possível. Imagine uma tabela "Problemas" no banco de dados do rastreador de erros. Cada registro nesta tabela deve representar um problema exclusivo. Quando você adiciona o segundo registro para o mesmo bug, ele na verdade começa a representar não um bug, mas o fato de algum usuário o ter descoberto e publicado em alguma data e hora. O que realmente aconteceu é que você postou algumas informações adicionais sobre o problema existente. Essas informações devem ser armazenadas em locais diferentes, como a tabela "IssueComments" ou algo parecido.

Do meu ponto de vista, a necromancia é menos maligna. Se a necromancia é um problema, devemos lutar com algo que está causando um problema, não com a própria necromancia (se você encontrou alguma informação nova sobre bug antigo, o que há de errado nisso? É totalmente natural). Por exemplo, se alguém postar um comentário sobre um bug fechado antigo, isso deve capturar a atenção de todos os usuários interessados.

Talvez você possa abrir um novo relatório de bug e vinculá-lo ao antigo. Justifique seus motivos para querer corrigi-lo. Pode ser que a correção interrompa o comportamento existente (compatibilidade binária ou altere a maneira como eles trabalham com o aplicativo) e corrigi-lo pode causar mais problemas do que vale a pena. Se a correção tiver um impacto mínimo, pode não haver objeções à correção.

Você precisa ver exatamente por que foi decidido não corrigir em primeiro lugar.

Eu diria que isso difere entre bug e solicitação de recurso.

Quando você cria um relatório de bug no bugtracker, geralmente descreve os sintomas. No entanto, isso não significa que a causa subjacente seja a mesma ou mesmo semelhante. Especialmente se os internos estiverem bem ocultos do usuário final, e tudo o que você recebe é um erro genérico quando algo dá errado. Nesses casos, a necromancia não é o caminho a seguir, pois, embora os sintomas externos possam parecer semelhantes, é provavelmente um bug completamente diferente. Se você reabrir o bug antigo, o desenvolvedor provavelmente começaria a investigar a causa antiga, o que pode levá-lo a uma direção completamente errada e a perder tempo.

Para solicitações de recursos que foram rejeitadas e os motivos de rejeição não são mais válidos, eu diria que a necromancia é o caminho a seguir. Nesse caso, você sabe que, ao criar um novo ticket, você criaria uma duplicata exata.