This document describes the in more detail. See the guide for writing tickets in JIRA for general instructions.
The Assignee of the task / bug is responsible for looking after the status of the issue. Ideally he can do something about it himself, but it is not always possible to complete the work without help.
Note that the priorities do not correspond with the complexity of the issue. (A blocker can be a complex file system issue or a tiny little execute permission problem that is fixed with a chmod.)
Instead, issue complexity is indicated by issue type.
When unsure, use Story as default.
Possible values, in order of importance:
To use the fields consistently we need to agree on their meaning. The meanings should be similar for each Type: New Feature, Bugs, Tasks, Stories and Epics.
FYI: Nice to have, but not essential. No one needs to do anything. We close or reprioritize them twice a year.
Minor: Minor issues need attention, but not in the near term. Setting a Due date for minor issues is recommended. They usually become more important if not addressed for a long time.
Major: Issue should be addressed within ~3 months. Set the Due date accordingly.
Critical: Issue should be addressed within 1-2 weeks. Set the Due date accordingly.
Blocker: Issue that prevents someone (a colleague or customer) from progressing. E.g., a bug that prevents a service from working, a missing feature that prevents the roll-out of a service or corpus. Needs attention within 3 days. Set the Due date accordingly.
Not prioritized: The default. Having an issue in this state for a long time is a problem, since the Assignee does not generally get any encouraging signals to complete the task. However, ”not prioritized” usually shows up highest in priority-based rankings, reminding people to at least set the priority.
Jira support the idea of a workflow to give issues a life cycle. The states of an issue are described below. We do not yet have fixed practives for all transitions, the information below is intended as a suggestion.
All new issues first end up here. Open issues are the big pool of issues that constitute a ”Backlog” in Kanban/Scrum terminology.
Issues that should soon be addressed. Ideally you should first pick from here before picking from ”Open”.
Again: Ideally: What you work on this week.
Issues that cannot proceed because you wait for some one else to do something.
Completed issues that require a review. Unless super trivial all issues benefit from a review, and be it that the reviewer is made aware that something is fixed.
At CSC we decided to use labels to assign reviews, since most reviews are non-urgent and labels allow for easy finding of reviable issues. Urgent reviews are either requested directly or via a sub task (”Please Review”). We also decided to have a permanent item on the agenda of our regular status meetings to remind each other of requesting/completing reviews.
Issues are ready to ”Release”, i.e. finally declared done. Project Administrators are able to release.