• 19Dec

    In Part 1, I talked about the different states a JIRA issue can have, as well as the different resolutions and what they mean. Today, I’ll walk you through the life of an issue, from the time it’s opened to the time it’s fixed and released. I’ll also talk about some of the challenges the JIRA process faces as it turns from an inward-facing tool to be used by trained software developers, to an outward-facing tool to be used by the general public.

    In theory, here’s how things are supposed to go:

    1. Someone opens a new issue. We’ll call that person the issue reporter. The issue is now Open.
    2. People vote and comment and add more info.
    3. A programmer (either a Linden or an open source volunteer) sees the issue and decides to tackle the job. The issue is now In Progress.
    4. When the programmer is done working their voodoo, they upload a patch to the JIRA. The issue is now Resolved. Or maybe it’s still Open. Who knows?
    5. A Linden with access to LL’s source code repository applies the patch and marks the issue as Resolved, with a resolution of “Fixed Internally”.
    6. It’s compiled and examined and made sure it works and there don’t seem to be any bugs. This is called QA (Quality Assurance), and it can take a long time, because there are lots of issues to check. The issue has to wait in a queue until it can be looked at.
    7. If it all checks out, eventually it will be released in a new version along with other fixes. Yay!
    8. The issue reporter downloads the new version and makes sure the issue has really been addressed. If it has, they mark the issue as Fixed, and Close it. If not, they change it back to Open, and we go back to step 1.
    9. Done!

    That’s how it’s supposed to go, anyway; or rather, as I said last time, my interpretation of it based on experience.

    In practice, though, issues often don’t end up Closed. Instead, they linger as Resolved until a dutiful volunteer sifts through the hundreds (thousands?) of Resolved issues, marking off the ones that have been fixed. Often, issue reporters simply don’t realize they’re supposed to check back later to Close the issue.

    As it happens, the Closed state isn’t used much. Maybe it’s the ambiguous difference between Resolved and Closed. Maybe it’s confusion about when it’s appropriate to Close an issue, and who is allowed to do it. Maybe it’s fear that Closing an issue is forever, as implied by the description of Closed as “the final resting place” (it’s not forever; you can re-open Closed issues just like you can for Resolved issues). Maybe they don’t want to make the reporter angry by closing their issue.

    Another contentious issue is the fact that voting is closed for Resolved issues, which (in my opinion) should not be the case. There are cases of high-profile bugs that are still ruining a lot of people’s SL experiences, but the fix seems to be stuck in QA limbo. Since issues are marked Resolved / Fixed Internally while going through the QA process, people can’t vote for it anymore. That means there could be hundreds of Residents who would have registered the fact that it affects them, but couldn’t. This prevents the number of voters reflecting the relative severity of the problem, a metric that could (and possibly should) be used to prioritize issues in the QA queue.

    Fortunately, there are JIRA issues about the issues with JIRA (how delightfully recursive)! A lot of progress has already been made on improving JIRA, but there’s still more to do. To get you started, check out:

    • WEB-194 (“Streamline and clarify JIRA reporting process for non-technical users”)
    • WEB-274 (“Change status labels for PJIRA”)
    • WEB-315 (“Meta Issue: LL JIRA Guidelines”)

    Posted by Jacek Antonelli @ 8:47 pm


Comments are closed.