OBSOLETE. We no longer use JIRA and have migrated to GitHub Issues |
The new JIRA workflow (see diagram below) was implemented for the DSpace JIRA project on 8 Jan 2013. This page just serves as an archive of what changes occurred between the old workflow (no longer in use) and the new workflow that is now in place. The current workflow is described at JIRA Usage. |
I'm starting to wonder if there are ways we can improve our JIRA workflow that would also simplify some of our JIRA review processes (and help us start to catch up on our JIRA backlog and "categorize" tickets better.
Old JIRA Workflow
Our old JIRA Workflow / Statuses looked similar to this:
- A Ticket is created -> "Received" Status
- If this ticket is invalid / not a bug it can be immediately "Closed"
- If it is valid, it moves into the "Open" status
- Once "Open", the ticket remains in that status indefinitely. There are two possible "next steps".
- Ticket can move to "In Progress" to denote that it's being worked on (this is actually rarely done)
- Ticket can be marked as "Resolved" to denote that it is fixed.
In total were are 5 statuses:
- Received - Ticket just came into the system
- Open (& Re-Opened) - Just denotes that this seems to be a valid ticket & that it is not yet "fixed".
- In Progress - Denotes someone is working on it (rarely used)
- Resolved - Denotes ticket is fixed/complete
- Closed - Also denotes ticket is fixed complete (we use it interchangeably with "Resolved")
The last two are very similar and we use them pretty much interchangeably to mean the ticket is "complete". Traditionally, in JIRA, many consider "resolved" tickets to be complete but may require extra verification (e.g. code review) before they move to the "closed" status.
New JIRA Workflow
I propose thinking about reworking our JIRA statuses to better represent what the Ticket may be "waiting on" or requiring. So, I'd propose instead using the following statuses:
- Received - Ticket just came into the system (same as current)
- More Details Needed - denoted the ticket is incomplete or too "blue sky". It needs details or more fleshing out before it can even be worked on
- Volunteer Needed - denotes the ticket is ready to be worked on, but needs a volunteer to work on it.
- Accepted- denotes the ticket has enough details to be worked on & has a volunteer assigned. Work on this ticket will begin soon (if it hasn't begun already).
- Code Review Needed - denotes that the assigned developer feels the ticket is complete, but has requested that someone else review the code before the ticket is closed.
- Closed - denotes work on the ticket is complete.
Here's a diagram of how a ticket would transition from one status to the next:
So, what are some of the possible benefits here?
- It would be more immediately clear which tickets need extra details ("Needs More Details"), so that we could point DCAT (or others) at them to start describing use cases, etc.
- It would be more immediately clear which tickets need a volunteer to work on them. (& it would allow other developers in the community to provide solutions via patches or GitHub Pull Requests)
- It would mean less tickets would remain indefinitely in the current "Open" status (which is a rather meaningless status, as it gives no information about why the ticket is sitting in that status)
Again, this is just an initial brainstorm. Comments/suggestions/changes/alternatives welcome!