Contribute to the DSpace Development Fund

The newly established DSpace Development Fund supports the development of new features prioritized by DSpace Governance. For a list of planned features see the fund wiki page.

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »

This is a very "loose" proposal, but wanted to capture it somewhere.

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.

Current JIRA Workflow

Our current JIRA Workflow / Statuses looks similar to this:

  1. A Ticket is created -> "Received" Status
    • If this ticket is invalid / not a bug it can be immediately "Closed"
  2. If it is valid, it moves into the "Open" status
  3. 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 there 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.

Proposed/Brainstormed JIRA Workflow

I'd 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?

  1. 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.
  2. 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)
  3. 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!

  • No labels