...
New Priority | Logically Replaces | Migrate From | Details |
---|---|---|---|
Wish | Wish Issue Type | Wish Issue Type | Feature Feature request that has no commitment from anyone to be worked on. Typically reserved for features that |
Low | Low-Minor | Low-Minor |
|
Normal | Minor-Major | Major | It wasn't clear what Minor or Major meant, but priority is a relative concept - a 'normal' is our logical baseline, and the default for a new issue |
High | Rest of Major |
| For tickets that community members plan to prioritise over other outstanding work, but has no immediate urgency |
Urgent | Critical-Blocker | Critical-Blocker | There's limited logical distinction between Critical and Blocker; it seems to make more sense to have a single 'do ASAP' tag. This should be limited to issues that need to be resolved prior to the next release. |
...
Currently it is easy for the project to miss a ticket, and for that ticket to fall through the cracks indefinitely.
At the same time, user reports cannot be expected to fill out all of the required fields accurately.
It's proposed that we introduce a new initial state named 'Triage' that has no required fields, and that anybody may file.
To transition to the Open state, you must be a contributor in JIRA (equivalent to able to assign tickets), and must ensure the required fields have been correctly filled out before doing so.
Removal of Reopened State
The Reopened state is of dubious value - arguably, it is in any scenario more helpful to file a new ticket, link the two via a relation, and leave a comment on the original for interested parties to migrate to the new discussion. In any case, its use is frowned upon and rare. It will of course remain possible to move a ticket from the 'Resolved' state to e.g. the Open state, but this will not be officially sanctioned except when correcting filing/procedural errors.
New Workflow
Triage <-> (Awaiting Feedback) -> Open/Reopened -> In Progress -> Patch Available -> Review in Progress -> Ready to Commit -> Resolved
State | Description | Expected Transitions (To) |
---|---|---|
Triage | This ticket has been filed, perhaps by a member of the community, but has not been considered by a contributor competent to assess its impact, severity, etc. Before transitioning to Open, the contributor should consider updating the title and summary to best reflect the report in a way the project will understand. | Awaiting Feedback, Open, Resolved |
Awaiting Feedback | Most beneficial as a cyclical state between Triage and itself, as dialogue takes place to establish any facts needed to understand, categorise and prioritise the report. | Triage, Open, Resolved |
Open | The ticket is prioritised and well summarised, but work is not yet underway. | In Progress |
In Progress | The assignee is 'actively' working on this ticket | Patch Available, Open |
Patch Available | The assignee has a patch that is ready for a reviewer. The assignee should endeavour to solicit from the community a reviewer competent in the subsystem(s) from, if none is already assigned. | Review in Progress |
Review in Progress | The assigned reviewer is 'actively' reviewing the available patch | Change Requested, Ready to Commit |
Change Requested | The reviewer has provided feedback for the assignee to consider and incorporate into their patch. Once they are ready to address these points, they should transition the ticket back to 'In Progress' | In Progress |
Ready to Commit | The reviewer(s) consider this patch to be ready to commit | Resolved |
Resolved | The ticket has been closed (either successfully or unsuccessfully) |
The column on the right represents the states we will provide buttons for performing a simple transition between. It does not include all acceptable transitionsObviously, the actual transition graph is much more complex than this.
Required fields on transition to 'Open'
...
Required fields on transition to 'Review in Progress'
Reviewers
Required fields on transition from 'Ready to Commit' to 'Resolved'
- Since Version (if bug)
- Fix Versions
...