Etiqueta de seguimiento de errores: ¿nigromancia o duplicado?

Me encontré con un problema de solicitud de función realmente antiguo (más de 2 años) en un rastreador de errores para un proyecto de código abierto que se marcó como "resuelto (no se solucionará)" debido a la falta de herramientas necesarias para realizar la mejora solicitada. En el tiempo transcurrido desde que se tomó esa determinación, se han desarrollado nuevas herramientas que permitirían su resolución, y me gustaría llamar la atención de la comunidad sobre esa aplicación.

Sin embargo, no estoy seguro de cuál es la etiqueta generalmente aceptada para el seguimiento de errores en casos como este. Obviamente, si el sistema declara explícitamente no duplicar y marcará activamente nuevos elementos como duplicados (de la misma manera que lo hacen los sitios de SE), entonces la respuesta sería seguir lo que dice el sistema. Pero, ¿qué pasa cuando el sistema no dice eso explícitamente, o cuando un nuevo usuario no puede encontrar fácilmente un lugar que dice que la preferencia del sistema es? ¿Se considera generalmente mejor errar por el lado de la duplicación o la nigromancia? ¿Esto difiere dependiendo de si es un error o una solicitud de función?

Lo único que puede responder adecuadamente a esto es el proceso de su organización. Si esta situación no está definida, debe definirse de modo que sea coherente cada vez que ocurra.

Recomiendo volver a abrir la anterior y agregarle nueva información según corresponda. Desde una perspectiva de medidas / métricas, esto probablemente sería lo menos dañino: lo nuevo no es un nuevo defecto o mejora, sino más bien revisar uno viejo. Debe haber algún estado para las solicitudes de cambio entrantes que indique que debe ser revisado por quien sea la parte responsable. Al volver a cambiar el estado a esto, pueden ver el historial (el hecho de que se aplazó una vez antes) pero también la nueva información fácilmente.

Lo que haría (y lo he hecho en el pasado) es crear un nuevo error (para darle relevancia), anotar la posible / nueva solución y vincular al anterior para referencia / seguimiento histórico.

también depende del error ... ese error podría ser una "característica" ahora, o tener soluciones bien establecidas que las personas han estado usando durante 2 años y que se solucionarían con una solución.

Básicamente, realmente tiene que investigar e investigar el error y la posible corrección, y si aún cree que debería solucionarse, entonces registre el error.

Como programador, creo que la duplicación de información generalmente es algo malo y debe evitarse siempre que sea posible. Imagine una tabla "Problemas" en la base de datos del rastreador de errores. Cada registro en esta tabla debe representar un problema único. Cuando agrega un segundo registro para el mismo error, en realidad comienza a representar no un error en sí mismo, sino el hecho de que algún usuario lo descubrió y publicó en alguna fecha y hora. Lo que realmente sucedió es que publicaste información adicional sobre un problema existente. Esta información debe almacenarse en un lugar diferente, como la tabla "IssueComments" o algo así.

Desde mi punto de vista, la nigromancia es menos malvada. Si la nigromancia es un problema, deberíamos luchar con algo que está causando un problema, no con la nigromancia en sí (si encontraste información nueva sobre un error antiguo, ¿qué tiene de malo? Es totalmente natural). Por ejemplo, si alguien publica un comentario sobre un error cerrado antiguo, esto debería captar la atención de todos los usuarios interesados.

Tal vez podría abrir un nuevo informe de error y vincularlo al anterior. Justifique sus razones para querer arreglarlo. Podría ser el caso de que la solución rompa el comportamiento existente (ya sea compatibilidad binaria o cambie la forma en que tienen que trabajar con la aplicación) y solucionarlo podría causar más problemas de lo que vale. Si la solución tuviera un impacto mínimo, entonces puede que no haya objeciones para que se solucione.

En primer lugar, debe ver exactamente por qué se decidió no solucionarlo.

Yo diría que esto difiere entre el error y la solicitud de función.

Cuando crea un informe de error en bugtracker, generalmente está describiendo síntomas. Sin embargo, no significa que la causa subyacente sea la misma o incluso similar. Especialmente si las partes internas están bien ocultas para el usuario final, y todo lo que obtienes es un error genérico cuando algo sale mal. En tales casos, la nigromancia no es el camino a seguir, ya que aunque los síntomas externos puedan parecer similares, lo más probable es que sea un error completamente diferente. Si vuelve a abrir el error anterior, el desarrollador probablemente comenzará a investigar la causa anterior, lo que puede llevarlo a una dirección completamente equivocada y perder tiempo.

Para la solicitud de características que fue rechazada y las razones de rechazo ya no son válidas, diría que la necromancia es el camino a seguir. En este caso, sabe que al crear un nuevo boleto estaría creando un duplicado exacto.