25

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?

Improve this question
1
  • linking common related tasks, items, bugs is the way to go !
    – Yusubov
    Commented Sep 19, 2012 at 15:37

5 Answers 5

Reset to default
10

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.

Improve this answer
6
  • Not part of an organization. This is an open source project. I'll clarify in the question.
    – Shauna
    Commented Sep 19, 2012 at 15:28
  • 2
    @Shauna There's still an organization involved. In this case, it's the open source project team. They have some way of doing things, and the best thing to do would be to ask them what you should do. Given that it's an open source project, they might have forums or a mailing list to pose this question.
    – Thomas Owens ♦
    Commented Sep 19, 2012 at 16:12
  • You're right, I misinterpreted what you originally meant.
    – Shauna
    Commented Sep 19, 2012 at 16:21
  • @Shauna: Additionally, the way he wrote his answer makes it relevant to people other than you.
    – Daenyth
    Commented Sep 19, 2012 at 16:57
  • 1
    @ThomasOwens: I think the implication for this question, and all questions like this, is 'how should it be' not, 'how is it at the OP's organization'. If the latter were the case, it'd be too localized.
    – Steven Evers
    Commented Sep 20, 2012 at 15:44
26

What I'd do (and have done in the past) is create a new bug (to give it relevance), note the possible/new fix, and link to the old one for historical reference/tracking.

it also depends on the bug... that bug might be a "feature" now, or have well-established work-arounds that people have been using for 2 years that would be broken by a fix.

Basically, you really have to dig through and investigate the bug and potential fix, and if you still think it should be fixed, then log the bug.

Improve this answer
1
  • 3
    To add to this: Linking to the old bug tells a reviewer you acknowledge there's a dupe and you have got something to add (or the conditions have changed). Most dupes happen because people don't search first and you get 10 people submitting the same bug.
    – Aren
    Commented Sep 19, 2012 at 17:33
3

As a programmer, I think that information duplicating is generally a bad thing and should be avoided whenever possible. Imagine a table "Issues" in bug-tracker database. Each record in this table should represent an unique issue. When you add second record for the same bug, it actually starts to represent not a bug itself, but the fact that some user discovered it and posted on some date and time. What actually happened is that you posted some additional info about existing issue. This info should be stored in different place, like "IssueComments" table or something like that.

From my point of view, necromancy is less evil. If necromancy is a problem, we should fight with something that causing a problem , not with necromancy itself (if you found some new info about old bug, what's wrong with that? It's totally natural). For example, if someone posts comment on old closed bug, this should somehow capture attention of all interested users.

Improve this answer
2

Perhaps you could open up a new bug report and link it to the old one. Justify your reasons for wanting to fix it. It could be the case that the fix would break existing behaviour (either binary compatibility or change the way they have to work with the applicaion) and fixing it could cause more problems than it's worth. If the fix would have minimal impact then there may be no objections to it being fixed.

You need to see exactly why it was decided to not fix in the first place.

Improve this answer
0

I'd say this differs between bug and feature request.

When you create a bug report in bugtracker, you're usually describing symptoms. It does not however mean, that underlying cause is same or even similar. Especially if internals are well hidden from end user, and all you get is generic error when something went wrong. In such a cases necromancy is not the way to go, as event though external symptoms might seem similar, it's most likely completely different bug. If you'd reopen old bug, the developer would probably start to investigate the old cause, which may lead him in complete wrong direction and loose time.

For feature request which was rejected and the rejection reasons are no longer valid, I'd say necromancy is the way to go. In this case you know that creating new ticket you would be creating exact duplicate.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.