Étiquette de suivi des bogues - Nécromancie ou doublon?

Je suis tombé sur un problème de demande de fonctionnalité très ancien (2+ ans) dans un outil de suivi des bogues pour un projet open source qui a été marqué comme "résolu (ne sera pas corrigé)" en raison du manque d'outils nécessaires pour effectuer l'amélioration demandée. Dans le temps qui s'est écoulé depuis que cette décision a été prise, de nouveaux outils ont été développés qui permettraient de le résoudre, et j'aimerais porter cela à l'attention de la communauté pour cette application.

Cependant, je ne sais pas quelle est l'étiquette généralement acceptée pour le suivi des bogues dans des cas comme celui-ci. De toute évidence, si le système déclare explicitement de ne pas dupliquer et marquera activement les nouveaux éléments comme doublons (à la manière des sites SE), la réponse serait de suivre ce que dit le système. Mais qu'en est-il lorsque le système ne dit pas explicitement cela, ou qu'un nouvel utilisateur ne peut pas facilement trouver un endroit qui dit avec la préférence du système? Est-il généralement préférable de pécher par excès de duplication ou de nécromancie? Est-ce que cela diffère selon qu'il s'agit d'un bogue ou d'une demande de fonctionnalité?

La seule chose qui peut répondre adéquatement à ce problème est le processus de votre organisation. Si cette situation n'est pas définie, elle doit être définie afin qu'elle soit cohérente à chaque fois qu'elle se produit.

Je recommanderais de rouvrir l'ancien et d'y ajouter de nouvelles informations, le cas échéant. Du point de vue des mesures / métriques, ce serait probablement le moins nocif - la nouvelle chose n'est pas un nouveau défaut ou une amélioration, mais plutôt une révision d'un ancien. Il devrait y avoir un état pour les demandes de changement entrantes qui indique qu'il doit être examiné par la personne responsable. En changeant l'état en arrière à cela, ils peuvent voir l'histoire (le fait qu'il a été différé une fois auparavant) mais aussi les nouvelles informations facilement.

Ce que je ferais (et ai fait dans le passé), c'est de créer un nouveau bogue (pour lui donner de la pertinence), de noter le correctif possible / nouveau et de créer un lien vers l'ancien pour référence / suivi historique.

cela dépend aussi du bogue ... ce bogue pourrait être une "fonctionnalité" maintenant, ou avoir des solutions de contournement bien établies que les gens utilisent depuis 2 ans et qui seraient interrompues par un correctif.

Fondamentalement, vous devez vraiment fouiller et enquêter sur le bogue et la correction potentielle, et si vous pensez toujours qu'il devrait être corrigé, puis connectez le bogue.

En tant que programmeur, je pense que la duplication d'informations est généralement une mauvaise chose et devrait être évitée autant que possible. Imaginez une table "Problèmes" dans la base de données de suivi des bogues. Chaque enregistrement de ce tableau doit représenter un problème unique. Lorsque vous ajoutez un deuxième enregistrement pour le même bogue, il commence à représenter non pas un bogue lui-même, mais le fait qu'un utilisateur l'a découvert et publié à une date et une heure. Ce qui s'est réellement passé, c'est que vous avez publié des informations supplémentaires sur le problème existant. Ces informations doivent être stockées dans un endroit différent, comme la table "IssueComments" ou quelque chose comme ça.

De mon point de vue, la nécromancie est moins mauvaise. Si la nécromancie est un problème, nous devrions nous battre avec quelque chose qui cause un problème, pas avec la nécromancie elle-même (si vous avez trouvé de nouvelles informations sur un ancien bug, qu'est-ce qui ne va pas? C'est totalement naturel). Par exemple, si quelqu'un publie un commentaire sur un ancien bogue fermé, cela devrait en quelque sorte capter l'attention de tous les utilisateurs intéressés.

Vous pourriez peut-être ouvrir un nouveau rapport de bogue et le lier à l'ancien. Justifiez vos raisons pour vouloir le réparer. Il peut arriver que le correctif brise le comportement existant (soit la compatibilité binaire, soit change la façon dont ils doivent travailler avec l'applicaion) et le corriger pourrait causer plus de problèmes qu'il n'en vaut la peine. Si le correctif a un impact minimal, il ne peut y avoir aucune objection à sa correction.

Vous devez voir exactement pourquoi il a été décidé de ne pas réparer en premier lieu.

Je dirais que cela diffère entre le bug et la demande de fonctionnalité.

Lorsque vous créez un rapport de bogue dans bugtracker, vous décrivez généralement des symptômes. Cela ne signifie cependant pas que la cause sous-jacente est identique ou même similaire. Surtout si les éléments internes sont bien cachés de l'utilisateur final, et tout ce que vous obtenez est une erreur générique en cas de problème. Dans de tels cas, la nécromancie n'est pas la voie à suivre, car même si les symptômes externes peuvent sembler similaires, il s'agit très probablement d'un bug complètement différent. Si vous rouvriez un ancien bogue, le développeur commencerait probablement à enquêter sur l'ancienne cause, ce qui pourrait le conduire dans une mauvaise direction et perdre du temps.

Pour une demande de fonctionnalité qui a été rejetée et les raisons du rejet ne sont plus valides, je dirais que la nécromancie est la voie à suivre. Dans ce cas, vous savez que la création d'un nouveau ticket créerait un duplicata exact.