I would like to be able to represent a fix as a separately tracked item that may be linked to one or more issues.
For instance, I might have 3 bugs tracked as issues, but I want them all to be linked to a single fix. The fix will track the status of the development (for instance, currently under development, undergoing code review, released), whereas each issue represents the status of the bug (for instance, open issue, fixed).
Keeping the two ideas separate helps to capture the concept of a fix and being distinct from the issues that it is fixing, which can be different. For instance, a fix might have its own history of going through the development process and will stay closed once released, whereas one of the bugs it fixed might unwittingly be opened up again in the future by another developer's changes. It also helps in situations where you might have conceptually different bugs that can be fixed by the same code change.
I looked into perhaps making the fix its own issue type, so as to track the status separately, but then the problem becomes how to describe the links. None of the link types (blocks, clones, duplicates, causes, relates) adequately describe the relationship, though if there is no better option, I could just go with "relates" and look to the issue types being linked to infer the rest of the meaning.
I also considered making each fix an epic, since you can link issues to them, but after some reading, it seems that this concept is probably overkill and too much ceremony for what I'm trying to represent.
Any suggestions on what the "right way" to represent this in JIRA is? Thanks.
You can change the link types and add new ones. Please see here
The beauty of JIRA is that the flexible configuration makes it possible to conceptually do almost anything if you are open to spend resources.
But I would personally review what JIRA has that relates to your requirement first and try to work with that. Fix Version/s field should for example cover some aspects. You can read how to manage versions here.
You could let the bugs represent the flow for knowing the status of the Fix Version. As you said " The fix will track the status of the development (for instance, currently under development, undergoing code review, released)"
For example don't allow re-open of bugs "whereas one of the bugs it fixed might unwittingly be opened up again in the future by another developer's changes." Clone or create new ones as you said the "a fix might have its own history of going through the development process and will stay closed once released".
Best regards, Niclas
Hey Community mates! Claire here from the Software Product Marketing team. We all know software development changes rapidly, and it's often tough to keep up. But from our research, we've found the h...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs