• 15Dec

    If you used the SL Public JIRA (highly recommended for all Resis, it’s neat!) then you might be familiar with the various states an issue can have. But you might not really know what those states mean.

    What’s the difference between “Resolved” and “Closed”? When is something “Fixed”, and why do some issues seem to get stuck in “Fixed Internally” for a long time?

    Read on to find out!

    Due to some confusing technical jargon that doesn’t make a lot of sense if you’re not used to them, the meanings of the various states aren’t immediately obviou. Here’s a list of the possible states that an issue can have right now:

    • Open: the normal state, people can vote and comment and post patches and such.
    • In Progress: someone’s working on it, so never ye worry.
    • Resolved: some sort of action has been taken to address the issue, but someone needs to confirm that it’s addressed, or it still needs to be released. Voting is closed, but you can comment or even re-open it.
    • Closed: the issue has been solved and released, everything’s groovy, nothing more to be done. Voting is closed, but you can comment or re-open it.

    At least, that’s my interpretation of them, based in large part on this well-hidden blurb on the SL wiki. There’s a lot of confusion about issue states, especially among users who aren’t used to issue tracking software and its weird jargon.

    When someone says a problem has been “resolved”, that usually means the thing has been fixed. But wait, that’s what the “Closed” state means on JIRA! So what does “Resolved” mean, then? Is it the same as “Closed”? Why do they have both of them?! Arrrgh, so confusin’!

    To make it even more confusifying, the “Resolved” state can mean lots of very different and unrelated things, depending on what the “resolution” is:

    • Fixed Internally: LL has fixed the issue (or applied a patch) in their internal source code repository, but it still needs to be reviewed to make sure everything’s good and it can be released.
    • Fixed: the issue has been fixed and released. Yay!
    • Won’t Finish: LL won’t fix the issue, for any number of reasons. Maybe it would break content, or make things really slow, or it just doesn’t fit within their grand vision.
    • Duplicate: someone has already reported this same (or a very similar) issue earlier or with better info/repro, and you should comment/vote on the other issue instead.
    • Needs More Info: the issue doesn’t have enough info, or it isn’t specific enough, for anyone to address the issue. E.g. “inventory is borked plz fix kthxbai” <– needs moar infos!!
    • Cannot Reproduce: the Linden who looked at this issue can’t make babies. Just kidding! It means they tried to make the bug happen so they could study it (and later try again to make sure it doesn’t happen up anymore), but they couldn’t. Repros are an important part of the process!
    • Misfiled: this issue doesn’t belong on JIRA. Examples include “Halp I furgetted my password”, “I liek ponies”, and “LL sucks cuz there poopy heads”. These types of reports don’t help make SL better!

    But those labels can be confusing, too, hence me needing to explain what they mean. And some of them don’t really fit with the Resolved state: the “Fixed” resolution, for example, should really only go with the Closed issue state. But, the same list of resolutions is used for both Resolved and Closed, and there’s some overlap, so it’s fuzzy and ambiguous.

    Tune in next time for an overview of the JIRA process flow, more JIRA quirks and weirdness, and some tips on making JIRA a better place!

    Posted by Jacek Antonelli @ 3:03 pm


2 Responses

  • JeanRicard Broek Says:

    There is a very good discussion about JIRA in Nicholaz Bearsford’s blog. Niko is famous for his open source work with the client and has fixed more bugs and leaks then anyone in SL. I am pleased to pass along his name and a URL to the post part 2: http://nicholaz-beresford.blogspot.com/2007/11/understanding-jira-part-2.html. Scroll through his blog and find Part 1. Enjoy and good luck.
    You may also contact me though I make no claim to understanding the internnal workings of the client, JIRA or the Linden’s : http://jeanricardbroek-architect.blogspot.com/.

  • Torley Says:

    I get confused about some of the resolution states too; I appreciate you writing about this and ‘splainin’ it further, Jacek! We could use further simplification. Some of it is due to limitations of the JIRA software (e.g., I wish that linking something as a Duplicate would also close that issue as such the 2-step process is wasteful, esp. if you’ve done it 100+ times as I have).