Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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

StateDescriptionExpected 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
OpenThe ticket is prioritised and well summarised, but work is not yet underway.In Progress
In ProgressThe assignee is 'actively' working on this ticketPatch 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 ProgressThe assigned reviewer is 'actively' reviewing the available patchChange Requested, Ready to Commit
Change RequestedThe 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 CommitThe reviewer(s) consider this patch to be ready to commitResolved
ResolvedThe 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

...