I came across a really old (2+ years) feature request issue in a bug tracker for an open source project that was marked as resolved (won't fix) due to the lack of tools required to make the requested enhancement. In the time elapsed since that determination was made, new tools have been developed that would allow it to be resolved, and I'd like to bring that to the attention of the community for that application.However, I'm not sure as to what the generally accepted etiquette is for bug tracking in cases like this. Obviously, if the system explicitly states to not duplicate and will actively mark new items as duplicates (much in the way the SE sites do), then the answer would be to follow what the system says. But what about when the system doesn't explicitly say that, or a new user can't easily find a place that says with the system's preference is? Is it generally considered better to err on the side of duplication or necromancy? Does this differ depending on whether it's a bug or a feature request?
Bug Tracking Etiquette - Necromancy or Duplicate?
issue tracking;etiquette
The only thing that can adequately answer this is your organization's process. If this situation isn't defined, it should be defined so that it is consistent every time it happens.I'd recommend reopening the old one and adding new information to it as appropriate. From a measurements/metrics perspective, this would probably be the least harmful - the new thing is not a new defect or enhancement, but rather revisiting an old one. There should be some state for incoming change requests that indicates it needs to be reviewed by whoever the responsible party is. By changing the state back to this, they can see the history (the fact it was deferred once before) but also the new information easily.