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 8 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)
  • Needs More Details - denoted the ticket is incomplete or too "blue sky". It needs details or more fleshing out before it can even be worked on
  • Needs Volunteer - denotes the ticket is ready to be worked on, but needs a volunteer to work on it.
  • In Progress - denotes the ticket is being worked on & has a volunteer assigned
  • Closed - denotes ticket is complete

(If we felt the need, we could add a "Needs Solution Review / Needs Code Review" status for tickets that have a proposed solution available but just need more eyes or a quick code review.)

Here's a diagram of how a ticket would transition from one status to the next:

Unknown macro: {gliffy}

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