Bug Tracker/Status

From Second Life Wiki
< Bug Tracker
Revision as of 09:25, 20 September 2010 by Sue Linden (talk | contribs)
Jump to navigation Jump to search

Here's how Linden Lab uses the workflow status and resolution field:

Awaiting Review
Initial state when an issue/ticket is created or when it is reopened from a resolved or closed state. All issues in in this state will be reviewed and triaged.
Acknowledged
When an issue has been imported to an internal Linden Lab project, it will be marked as Acknowledged and Assigned to User:WorkingOnIt_Linden. We've installed a custom sync tool that enables syncing between internal and external projects. NOTE: VWR bugs will be moved to internal projects and be visible to residents (also Residents will have the ability to comment on them). Residents will be able to see only issues that have been moved from VWR not the entire internal project, unless the team has opened their project; for example, Snowstorm.
Fix Pending
When the imported issue has passed QA internally, then the public issue will change to Fix Pending. The bug is fixed in a version of the code that should soon be publicly available.
Released (Resolution = Fixed)
When the imported issue has been released (when it's marked as Closed), then the public issue will be marked as Released and the Resolution = Fixed.
Closed
Resolution = Fixed
When the Reporter agrees the issue is fixed in Production, s/he should mark the issue as Closed.
Resolution = Won't Finish
The assignee or Linden Lab doesn't reasonably believe this issue should or will be fixed.
Resolution = Duplicate
There's another issue about the same problem/idea. See the issues linked to it.
Needs More Info (Resolution = Incomplete)
The issue lacks actionable information. Add the info or it CAN'T be investigated.
Cannot Reproduce (Resolution = Incomplete)
Following the stated steps does NOT show the problem. Please provide a solid description of how to reproduce the problem, otherwise it's like finding Bigfoot. Issues that can't be reproduced will eventually be closed.
Deferred (Resolution = Incomplete)
The problem/idea is being evaluated but will not be worked on at the moment.
Contact Support (Resolution = Not Applicable)
The issue does NOT belong in the Bug Tracker, and needs to be handled through the Support Portal or Second Life Answers.
Expected Behavior (Resolution = Not Applicable)
This is NOT a bug and functions by design See Expected Behavior aka Not a Bug.
Misfiled (Resolution = Not Applicable)
This issue doesn't belong in the Bug Tracker. Often, these are afoul of our rules.

After an issue gets Linden attention, you can follow along.

Diagram of Workflow

PJIRA-proposed-workflow-v3.jpg

Note:

  • Diagram does not have all the transition arrows.
  • A terminal state is a state that's not a middle step in a workflow, and would frequently be the last state for an issue. "Support Issue" is a good example.

Sync Tool Overview

  • Terms:
    • Original Issue = the original issue entered in the public portal (or originating project)
    • Cloned Issue = the issue copied and moved from the public portal to the internal scrum project.
  • Acknowledged --> Fix Pending
    • When the cloned issue is moved to Passed QA on the internal project (a comment is also placed on the orignal issue).
  • Fix Pending --> Released
    • When the cloned issue moves to Closed on the internal project indicating it has been released to production (a comment is also placed on the orignal issue).
  • Reopen Original from Needs More Info
    • When the original issue is reopened from NMI, then the cloned issue is also reopened and latest comment is added on to the cloned issue.
  • Reopen Cloned Issue
    • When the cloned issue is reopened, then original issue is also reopened (a comment is also placed on the orignal issue).

Priority Definitions

  • Showstopper - an issue that could (or did) cause disastrous consequences. For example critical loss of data, critical loss of system availability, critical loss of security, critical loss of safety.
  • Severe - an issue that could (or did) cause very serious consequences. For example a function is severely broken, cannot be used and there is no workaround.
  • Major - an issue that could (or did) cause significant consequences, but there is a workaround. For example: A function is badly broken but workaround exists.
  • Minor (default) - an issue that could (or did) cause small or negligible consequences. Easy to recover or workaround. For example: misleading error messages, displaying output in a font or format other than what the resident desired.
  • Trivial - an issue that can cause no negative consequences. Such defects normally produce no erroneous outputs. For example: simple typos in documentation, bad layout or mis-spelling on screen.

Transition to New Resolutions on 2010/08/24

Definitions
Status = Step in the workflow; the stage the issue is currently at in its lifecycle; ie the box in the workflow diagram
Resolution = a record of the issue's resolution. If Resolution is blank, the issue is "Unresolved." If Resolution has a value, the issue is "Resolved" and will appear crossed out in JIRA. This is regardless of the workflow status.

Resolution Migration Plans
Fixed No change
Duplicate No change
Won't Finish No change
Not Applicable New
Incomplete New
Cannot Reproduce Change to "Cannot Reproduce" Status, Resolution = Incomplete
Contact Support Change to "Support Issue" Status, Resolution = Incomplete
Expected Behavior Change to "Expected Behavior" Status, Resolution = Not Applicable
Misfiled Change to "Misfiled" Status, Resolution = Not Applicable
Needs More Info Change to "Needs More Info" Status, Resolution = Incomplete
Under Advisement Change to "Deferred" Status, Resolution = Incomplete