Blog

  • 2024
  • 2023
  • 2022
  • 2021
  • 2020
  • 2019
  • 2018
  • 2017
  • 2016
  • 2015
  • 2014
  • 2013
  • 2012




We are starting using JIRA as an issue tracking system for some of our projects. While we still maintain and really like our Bugzilla installation, we want to given another product a try. Mainly because we switched our wiki to Confluence and new want to test how well these two tools integrate.

The first thing we wanted to discover was, how we should categorize our bugs. In Bugzilla we added a number of keywords and flagged our issues with them. Now we checked, which one have really been useful in the past.

 

You may want to have a look at the keywords we used with bugzilla, to get the picture since I do not repeat their meaning in the following discussion.

These are the results of our evaluation ...

Info Tags

We had three different info tags to flag the information granularity. Due to the use of our issues-maven-plugin the noteworthy keyword proofed really useful to mark issues to be highlighted in the release report. The other two - I'll save the time to name them - where hardly ever used.

Remember Tags

Never used. Do not remember them.

Bug Status Tags

These tags where used to mark issues to be in the state of discussion or that more information is required to continue with a particular issue. Sometimes we used the investigate flag to signal that we are currently working on it to check, if the report should be accepted.

The other two where never used.

I still like the idea of the discussion, needinfo and investigate keywords. So they will make it to JIRA.

Breaking Tags

These tags signal to users that there have been incompatible API changes. They are recognized by the Issues Maven Plugin and reported in the release notes.

This has been extremely useful in the past, because we could document incompatibilities easily. So we will continue to have these labels in the future with JIRA.

Code Tags

Meant to allow to categorize an issue, I often set these keywords - but actually never evaluated them. But this may be due to the fact, that our open source tools are quite small and therefore the number of reported issues is too small to require deeper insight into the types of bugs often encountered.

I think we will regroup some of them and continue to use them in the future. Hoping that we will someday add reports to draw invaluable information from them. Maybe I'm just a documentation freak ... :-)

Summary

So these are the keywords that will make it to the new JIRA installation:

    • noteworthy
    • discussion
    • investigate
    • break (4 types)
    • Code tags (in some new form)

Seven keywords will be skipped completely.

In our next article we will report, which technique we used to map our Bugzilla keywords to JIRA.


Link

Link

Posts