Jira - Local help - Jira

Jira tracks issues, which can be bugs, feature requests, or any other tasks you want to track.

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

Issue Types

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

Action Item: This is a project-defined Action Item that must be tracked to closure. Action Items may come out of meetings or design reviews.
Realized Risk: This is when a risk (which has been documented in the LSST risk registry) has been realized. A realized risk, by definition, is now an issue. The realized risk should cross reference the unique identifier from the LSST risk database.
General Issue/Concern: Use this category to capture general issues/concerns.
LSST Change Control Board Action Item: Actions generated during a CCB meeting that need to be tracked to closure should use this issue type. These may be deferred actions (for example, the CCB may recommend a document for approval but would like to make sure something gets incorporated during the next update).
Hazard: This is an item from the LSST Hazard Analysis that cannot be designed out or is not identified as a risk in the risk register. These are hazards that will be dealt with through training, signage, or some other method that has a implementation point that is still far into the future.
TCB Action: Telescope Control Board Actions
RFC: An issue whose primary purpose is to advertise an intent and allow stakeholders to comment.
Milestone: An overall project milestone
Meta-epic: An overarching scope of work that spans multiple epics
Key Metric: A key performance metric or other type of quantifiable attainment targer
RFD: A request for what may potentially be open-ended discussion on high-level topics.
Discrepancies: Review item discrepancies
Comments & Questions: Review item clarifications, comments and questions
Paper: Story issue type for PUB project
Planning Package
Fault: A problem that affected normal operations
Verification: An activity relating to planned verification
IT Ticket: This is a ticket for IT.
Review Recommendation: An action item resulting from an agency review
Risk: An uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives
Incident
Request
Requirement: This is for mapping requirements in MagicDraw to a JIRA issue.
SE Task: A slightly augmented task issue type for Systems Engineering.
Deviation: A deviation request is generated when a requirement will not be fully met but is determined to be acceptable.
RM-Handling: Handling action for risks and opportunities.
RM-Risk: Risk issue type to be used in the risk management project.
RM-Opportunity
Event Request: Issue Type used to request, approve, track and report on events, which are classified as activities performed by a specific group in a specified timeframe.
Tour: This issue type is used to plan and track tours or external visitors that are scheduled in advance to visit a Site.
Travel: This issue type is used to plan, and track employee travel between locations. Primarily, Chile and the US.
Event: This issue type is used to plan, coordinate and track the implementation of Observatory hosted meeting and events.
Failure Report: Documentation of an event in which an item does not perform one or more of it's required functions within the specified limits under specified conditions.
Corrective Action: A task required to implement a corrective action to reduce the recurrence of a failure.
Car Request: Issue type used to initiate a vehicle use request, and to track logistics.
Validation: An issue describing what needs to be completed in order to validate the science objectives or characterize the system.
Resource Request: Issue type used to interface with the LASD project (AMS) to coordinate administrative and support activities like lodging, travel, shuttles, etc.
ADMIN Request: Issue Type to support resuests for support from the Chile Administrative Team
Work Request: This Issue Type is intended to perform a similar function as the "Task" Issue Type. with a slightly modified workflow.
Maintenance: Generic, temporary Issue Type created to process both Planned and Unplanned maintenance activities.
Internal Review Recommendation: A recommendation resulting from an Internal Review process
Hazard Mitigation Verification: Verification of the defined mitigation to the hazardous condition identified in the LSST Hazard Analysis.
Service Request
Problem
Ops Review Rec: Review recommendation for the Rubin Observatory Operations project.
Priority Image HOLDER-1: This Issue type was created as a place holder for the Avatar/image used for SUMMIT PRIORITY-1
Priority Image HOLDER-3: Placeholder for Priority Image for SUMMIT-3
Information
In-Kind Helpdesk: In-kind helpdesk ticket
Non-Conformance Report: An NCR captures the deficiencies in the manufacturing, assembly, and workmanship of the system during it’s production.
Block: An Observing Block, a quantum of schedulable observing
Content Creation: Rubin Ops EPO Team specific issue type for tracking the content creation process.
Bug: A problem which impairs or prevents the functions of the product.
Epic: Created by Jira Software - do not edit or delete. Issue type for a big user story that needs to be broken down.
New Feature: A new feature of the product, which has yet to be developed.
Story: Created by Jira Software - do not edit or delete. Issue type for a user story.
Task: A task that needs to be done.
Improvement: An improvement or enhancement to an existing feature or task.

For Sub-Task Issues

Sub-Task: The Sub-Task of the issue
Sub-Template: Sub-Issue Type for Templates
Technical task: Created by JIRA Agile - do not edit or delete. Issue type for a technical task.

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.

Blocker: Blocks development and/or testing work, production could not run.
Critical: Crashes, loss of data, severe memory leak.
Major: Major loss of function.
Minor: Minor loss of function, or other problem where easy workaround is present.
Trivial: Cosmetic problem like misspelt words or misaligned text.
Undefined: No priority assigned (may not apply or be unknown)
1: This must be done to enter commissioning (a) or operations (b); no waivers will be granted if not met.
1a: Must be demonstrated to be working before the start of the commissioning period.
1b: Must be demonstrated to be working before the start of the observing.
2: Should be done to enter Operations; but waiver likely to be granted if not met.
3: Overall capability/efficiency/ease of use/etc., may be reduced but science will not critically suffer if not done.
Standard
Urgent
SUMMIT-1: Critical Path
SUMMIT-2: Near Critical Path
SUMMIT-3: When We Can
SUMMIT-4: Back Burner
SUMMIT-5: DELETE - Not Applicable
TEST-TEMP: Temporary Priority created for testing purposes. Will be deleted after test.
Low: Only 1 person affected
Medium: Many people affected
High: Everybody is affected

Statuses

Status Categories

Helps identify where an issue is in its lifecycle.
Issues move from To Do to In Progress when work starts on them, and later move to Done when all work is complete.

Done: Represents anything for which work has been completed
In Progress: Represents anything in the process of being worked on
No Category: A category is yet to be set for this status
To Do: Represents anything new

Issue 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.

Unplanned: The issue is open and ready for the assignee to start work on it.
To Do
In Progress
Reopened: This issue was once resolved, but the resolution was deemed insufficient. 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 has been closed due to legacy status, no further work has been registered.
Deferred: Use this state for any item that has technical resolution but will not be updated in baselined documentation until a later date.
In Review: This status is managed internally by JIRA Software
Done
Acknowledged: The person who has been assigned the issue acknowledges that he/she is the correct person to assign the issue to and agrees to work the issue.
Reviewed: This status is managed internally by JIRA Software
Code Review
Planning: This status is managed internally by JIRA Software
Blocked: This status is managed internally by JIRA Software
Awaiting Signoff: This status is managed internally by JIRA Software
Won't Fix: This status is managed internally by JIRA Software
Can't Reproduce: Giving up unless more information is provided
Withdrawn: The proposal has been withdrawn due to the Reporter reconsidering, or as a result of the discussion.
Flagged: An issue has been flagged for management escalation.
Retired: This RFC has been retired because it is no longer applicable (eg. it relates to software that has been replaced)
Proposed: An RFC or plan has been proposed
Adopted: An RFC or plan has been adopted as the baseline
Duplicate: This is a duplicate of another ticket
Invalid: A catch-all for any kind of status that does not fall in an existing category. In DM this includes reports that can't be reproduced, duplicates, confusion, etc.
Implemented: Tis Done.
Reported
Selected for Development
With PubBoard: Awaiting Action from the PubBoard (referee assignment, approval etc)
With Reviewer: The item is with the reviewer assigned by the pub board
With Project: The item is in its project-wide consultation period
Closeout Review
Denied
Journal Submitted: The paper has been submitted to the journal (or proceedings etc.)
Journal In Review: The paper is in the journal's peer review process
Journal In Press
With Author
Active
In Analysis
Passed
Board Recommended: The RFC has been recommended for approval by the relevant change control team (eg DM-TCT or ITCG)
Manager Approved: Approved by Manager with permissions
Discuss
PM Approval
Returned: This issue was submitted for Review, but additional information or action is requested. From here issues are sent back (returned) to the Assignee.
Review
Cancelled
Covered: The verification requirement has been traced to a least 1 Test Case.
In Verification
Verified: The verification requirement has been fully verified with no Deviations.
Monitoring: The verification requirement has been fully verified and is now being monitored to ensure it does not go out of compliance.
Failed
Verified w/ Deviation: The verification requirement has been verified but required a Deviation.
Accepted: The deviation request has been accepted.
Not Covered: The issue has been created but it has not been traced to any Test Cases.
Descoped: The verification requirement has failed verification and has been decided to be descoped.
Out of Compliance: During monitoring, the verification requirement has fallen out of compliance.
CCB Review: The deviation request is being reviewed by the CCB.
Impact Analysis: The deviation request is having an impact analysis being performed by the SE Team.
Waiting: Set the ticket on waiting status for whatever reason.
Subordinated
Active Risk/Opportunity
Realized
Deprecated
Requested
FRB Review: The failure report is being reviewed by the Failure Review Board.
CA Approved: The Corrective Action(s) have been approved by the FRB for implementation.
SE Review
Planned: Action is officially planned.
Admin Review: This Status indicates that a Request for Services has been received and in under Administrative Review to determine the appropriate next action.
Open
Under Review
Maintenance Approved: This step indicates that the Maintenance activity is successfully completed.
Rejected
Admin Request: Interim step to hold tickets to identify when Admin support is requested.
Traveler Input Required: Step to indicate that a task is on hold pending Traveler input.
Fulfilled: Status to indicate that TRAVEL projects requests have been addressed.
Reqless Request: Initial status when email received from Reqless after TR approval. Progression causes subtasks to be created.
Proposed Task: State created to hold new tasks for CAM review and planning before adding to the Summit Calendar
Safety Review
Unverified
Investigation
Waiting Customer
Waiting External
Pending Approval
Pending Review
Pending Documentation
Escalated L2
Escalated L3
Parametric Configuration: Temporary interim state to allow post function conditioning of data transferred from an external system
Approved
No Artifact: The requirement verification has been reviewed and no artifact is available.
Tracking: This ticket is being monitored but needs additional input (data, testing, occurences, etc) before it can be worked on
Oops
Backlog
Preparation
Ready
Observable
Observed
Abandoned
Transferred: Action created in a subsystem Jira project
Testing
Text & Content: Specific content is being generated.
Content Review: Content is under review by appropriate reviewer
Visuals & Translation: Specific visuals are being created and translation is underway.
Final Review: Review of all aspects of the content is underway.
Ready for Publication: Content has been created, reviewed and now is ready for publication (Done).
On Hold: Work on content has been paused, waiting for escalation.
Prospective: An issue or task that is being considered for future implementation.

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.
Won't Fix: The problem described is an issue which will never be fixed.
Duplicate: The problem is a duplicate of an existing issue.
Incomplete: The problem is not completely described.
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.
Done: GreenHopper Managed Resolution
Won't Do: This issue won't be actioned.
Passed Verification: The verification requirement has been fully verified.
Passed Verification w/ Deviation: The verification requirement has been verified but required deviations.
Descoped: The verification requirement has failed verification and has been descoped.
Accepted: The Deviation has been accepted.
Rejected: The Deviation has been rejected and the issue must be fixed a verified.