We are currently evaluating JIRA and going to use it to manage a release cycle.
I've encountered a dilema, on how to differentiate between a reported bug from QA and from Customer Services.
The following options came to mind:
1. Create a different issue type for each.
2. Use a selector field to set the origin of the issue (where it was found: QA LAB, CS LAB, Customer Production... etc).
3. Same as 2, just use a LABEL.
Main consideretions are reports, statistics and ease of creating an issue.
I will apriciate your advice and experience on this.
I'd add "separate projects" to your list - it may not be appropriate, but I don't know your process and organisation, so it's worth mentioning.
Personally, I'd also rule out option 3, as humans set labels, and we can't type, or remember to do it reliably. That kind of applies to 1 and 2 as well (we pick the wrong issue type, or the wrong item from the select list), but with those two mistakes, we are at least limited in how badly wrong we can get it. For example, if you've got 4 issue types or four "origins", the worst case is I pick the wrong one. If you have labels A, B, C and D for the origins, there's nothing stopping me writing "Penguin" for it.
I'd also prefer to use "issue type" to represent the type of problem, instead of "where it was found". Again, that's a purely personal preference, but I think it saves you some effort in explaining that "issue type != type of issue"
Finally, on option 2, a couple of extra tweaks
1. You could use components if you don't want a whole new field. Although I don't think components really are for that and probably have better uses.
2. If you indulged in a little coding, you could do sneaky stuff with the field - leave it off the "create" screen, and set it in code. For example, if your users are in distinct groups or roles, you could write some code that says "this human is a QA bod, so stick QA LAB in this field"
The easiest way for creation is to differentiate by the reporter or the group of the reporter, if this is possible.
If you want to use issue statistics, you should use a select list with predefined values or a different issue type. More issue types means more administration if you want to change the screens or workflows etc...
If there are only some values and they don't change very often I would not suggest to use labels, because you can't control the possible values and each user can create new one.
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
...attest to the experience of an urgent approval that gets lost in the boss’s inbox and requires that special “Please Approve” email or text message. In an age where we have distributed teams...
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