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.

OBSOLETE. We no longer use JIRA and have migrated to GitHub Issues

Workflow Changes Complete

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:

  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 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?

  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

10 Comments

  1. Mark Diggory

    I like it.

  2. Hardy Pottinger

    +1 clarity is good, and this proposal promotes clarity

  3. Bram Luyten (Atmire)

    +1 great stuff, honestly can't wait to see this implemented.

    In the OR12 developer meeting discussion it was debated whether there should be a DCAT specific status to indicate that DCAT is taking on specific issues, especially in the "Needs more details" and "Needs volunteer" statuses. I don't think there was a unanimous opinion here so just noting that I personally think the fewer different statuses, the better and DCAT can show its activity in the comment logs within particular tickets. Activity on tickets will put them higher on the list of "last changed" tickets which will get them more attention anyway.

    There was also some discussion if the community would be able to adhere to certain time-bound moves of statuses. For example:

    • What should be the maximum time before a received ticket is either moved to closed (irrelevant), needs more information or needs volunteer
    • What could be done with tickets that reside too long in the needs volunteer stage (Duraspace managed projects? DCAT search for volunteers?)
    • What could be done with items that reside in the "in progress" stage for too long. How do we detect if a volunteer has given up on the project & how can it be decided to move it back to the needs volunteer stage?

  4. Bram Luyten (Atmire)

    Is there a need for a "code review required" stage when a developer is in a semi-finished stage where he/she wants input from other developers?

    1. Mark H. Wood

      YES!  Well, sort of:  I crave feedback from someone who has encountered the problem in use, not under artificial testing conditions, that I actually fixed it.  Perhaps broaden the term a little and call it "verification", which could mean code review, independent testing, or both.  When I close an issue, I want it to be in such a condition that I never hear about it again.

      I'd also like to suggest we agree a conventional amount of time for an issue to sit in this state, after which the changes can be assumed correct and the issue moved to "closed".

      1. Tim Donohue

        Based on this suggestion & discussion in today's DSpace Developers Mtg, I've added a state called "Code Review Needed" to the diagram above.

  5. Iryna Kuchma

    +1

  6. Tim Donohue

    This new JIRA Workflow idea seems to have widespread approval.  I'll be working to try and make this happen in the coming weeks. 

    However, it may take some manual work to re-categorize all existing "open" issues as either "needs volunteer" or "needs more details".  So, I may be asking for help from developers & community members in this re-categorization process once the new workflow is in place.

    So, this change will be happening in the near future – hopefully in just a matter of a few weeks, assuming there are no unanticipated roadblocks along the way.

  7. Bram Luyten (Atmire)

    DCAT continues to be very interested in this. Especially the "needs more details" stage would make it very easy for DCAT members to identify those issues in which we can contribute.

    1. Tim Donohue

      Not to worry. I'm working on this as we speak.  Finally got to it this week.  However, as mentioned, this is a rather complex change in JIRA – it will affect nearly all of our existing JIRA tickets.  In addition, after the migration is complete, approximately 400+ tickets will need some sort of manual review to determine whether they need to be in the "volunteer needed", "more details needed" or "accepted" status.

      I've updated a few statuses in the above diagram with what the final names will be. 

      • The "in progress" status has been renamed to "accepted" as it was noted that just cause a developer has been assigned to the ticket doesn't necessarily mean that the work is currently taking place. Just that it's on someone's radar
      • The "Needs more details" and "Needs Volunteer" statuses were just renamed slightly to be consistent with other status names...they are now "More Details Needed" and "Volunteer Needed".

      I'll be emailing Developers & DCAT with details of this migration (later today, likely). It'll be a bit painful to have to (re-)review the 400+ tickets which need to be re-categorized properly, but it's necessary to dig through this backlog anyhow.

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.