Each issue has a variety of associated information including:

• the issue type
• a summary
• a description of the issue
• the project which the issue belongs to
• components within a project which are associated with this issue
• versions of the project which are affected by this issue
• versions of the project which will resolve the issue
• the environment in which it occurs
• a priority for being fixed
• an assigned developer to work on the task
• a reporter – the user who entered the issue into the system
• the current status of the issue
• a full history log of all field changes that have occurred
• a comment trail added by users
• if the issue is resolved – the resolution

Below is an example of system documentation that describes the use of a very complex system–a good list of what is possible within these categories in JIRA.

List of Issue Types in Example Company

JIRA can be used to track many different types of issues. The currently defined issue types are listed below. In addition, you can add more in the administration section.

For Regular Issues

• Ad Hoc Dataset
• Application
• Bug
• A problem which impairs or prevents the functions of the product.
• Colo Task
• Custom Universe
• Dashboard Metric
• Defect
• A problem which impairs or prevents the functions of the product.
• Design Issue
• Tasks that are enhancements, suggestions, or changes to design
• DRT
• Deploy Request Ticket
• Epic
• A big user story that needs to be broken down.
• Formatted Report
• Merge Request
• Meta Issue
• Describes a general category of problems rather than a specific problem
• New Feature
• A new feature of the product, which has yet to be developed.
• New Feature Request
• QAE
• Viewer 2 – External QAR Issue type
• QART
• Release
• Release QARs
• Sim Host Repurpose Request
• Story
• An user story
• System Documentation Request
• Documents Operations procedures, Nagios requests, and other SISESE/DNOC/Ops-related items
• Task.
• A task that needs to be done.
• Ticket
• Translation
• Video Request
• Violation Report

For Sub-Task Issues

• Beta
• Story Defect
• Sub-task
• The sub-task of the issue
• Task
• A task that needs to be done.
• TPV Deploy Request
• Deploy Request Tracker for Third Party Viewers

Priority Levels

An issue has a priority level which indicates its importance. The currently defined priorities are listed below. In addition, you can add more priority levels in the administration section.

• 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. Such as the inability for many Residents to login. IMPORTANT: Abusing this setting will cause revocation of Bug Tracker access. If in doubt, mark “Severe” instead.
• 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 – Major loss of function.
• Minor – Minor loss of function, or other problem where easy workaround is present.
• Trivial – Cosmetic problem like misspelled words or misaligned text
• Unset – An issue whose priority has not yet been determined

Statuses

Each issue has a status, which indicates the stage of the issue. In the default workflow, issues start as being Open, progressing to In Progress, Resolved and then Closed. Other workflows may have other status transitions.

• Open – The issue is open and ready for the assignee to start work on it.
• In Progress – This issue is being actively worked on at the moment by the assignee.
• Reopened – This issue was once resolved, but the resolution was deemed incorrect. From here issues are either marked assigned or resolved.
• Resolved – A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.
• Closed – The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.
• 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.
• Ready for Translation – TRANSLATION PROJECT ONLY.
• Translation In Progress – TRANSLATION PROJECT ONLY.
• Translated – TRANSLATION PROJECT ONLY.
• In QA
• Passed QA
• Translation Final
• Published – TRANSLATION PROJECT ONLY.
• On Hold – TRANSLATION PROJECT ONLY.
• Editing In Progress – TRANSLATION PROJECT ONLY.
• Edited – TRANSLATION PROJECT ONLY.
• Testing – TRANSLATION PROJECT ONLY.
• Verified – TRANSLATION PROJECT ONLY.
• Verified: Fixed – TRANSLATION PROJECT ONLY.
• Verified: Fix Needed – TRANSLATION PROJECT ONLY.
• Republished – TRANSLATION PROJECT ONLY.
• Ready for Testing – Issue is ready to be tested by LL QA
• Reviewing – Reviewing issue before considering it “Development Complete”
• Deferred – The problem/idea is being evaluated but will not be worked on at the moment.
• Passed Testing – Issue has passed testing
• Approved – Design Issue fits within the current roadmap, approve it
• Rejected – Design issue does not within the current roadmap, reject it
• Requested – A QAE has been Requested for a Build.
• Failed QA
• Closed-BP
• Closed-BI
• Awaiting Review – Initial state when an issue/ticket is created or when it is reopened from a resolved or closed state. All issues in this state will be reviewed and triaged.
• Acknowledged – After upgrade (on Sept 7): When an issue has been imported to an internal Linden Lab project, it will be marked as Acknowledged. We’re installing a custom tool to enable syncing between internal and external projects (ie VWR, SVC, WEB). Prior to upgrade: Acknowledge is all issues that were In Progress.
• Released – 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.
• Needs More Info – The issue lacks actionable information. Add the info or it CAN’T be investigated.
• Cannot Reproduce – 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.
• Contact Support – The issue does NOT belong in the Issue Tracker. Please contact http://secondlife.com/support
• Expected Behavior – This is NOT a bug and functions by design.
• Misfiled – This issue doesn’t belong in the Issue Tracker.
• Deploy Requested
• Deploy Failed
• Build Requested
• Build Failed
• Prod Deploy Requested
• Prod Deploy Completed
• Prod Deploy Failed
• Prod Deploy Rolled Back
• Integration Test – Integrated and ready for Testing
• Preparing RC
• Pending RC
• In RC
• Needs Fix
• Pending Release
• Delisted
• Notified
• Violation
• Compliant
• Been Triaged
• Reviewed
• Returned
• Ineligible
• Listed
• In Beta
• Failed
• Fubar
• Req SQL Review
• SQL Rev Pass
• SQL Rev Fail
• Req Dply Staging
• Staging Deployed
• Stage Dply Fail
• Req QA
• Urgent Dply Req
• Release Review
• In Review
• Product Review – Pending approval from Product for integration
• Closed – Cannot Reproduce
• Closed – Expected Behavior
• Closed – Won’t Finish
• Information Provided
• Accepted
• Ready for QA – This status is managed internally by GreenHopper
• Ready for Deployment – This status is managed internally by GreenHopper
• Won’t Finish – This status is managed internally by GreenHopper
• Merging
• Blocked
• Planning

Resolutions

An issue can be resolved in many ways, only one of them being “Fixed”. The defined resolutions are listed below. You can add more in the administration section.

• Fixed – A fix for this issue is checked into the tree and tested.
• Duplicate – The problem is a duplicate of an existing issue.
• Won’t Finish – The problem described is an issue which likely will never be fixed.
• Not Applicable – Ticket is not applicable because it is filed in the wrong system, is a support issue, etc.
• Incomplete – The problem is not completely described.
• Unactionable – Problem described in the ticket is not in a form that action can be taken (i.e. it’s too broad)
• Released – The ticket is now in production.
• Expected Behavior
• Cannot Reproduce – All attempts at reproducing this issue failed, or not enough information was available to reproduce the issue. Reading the code produces no clues as to why this behavior would occur. If more information appears later, please reopen the issue.
• Triaged
• Contact Support
• Re-opened
• Accepted