Jira Improvement Plan, Part 1: THE GRAVEYARD. Closing all outdated issues in 2 weeks.

The Problem

Our ticket system should be serving our community, and helping us see what matters. It’s not doing that right now. We can change that.

Our ticket system should be an up-to-date reflection of the work that is being done, vs what needs review. This is not the case right now, and the workflows are so painful that just to mark a ticket done takes so many clicks. We can change this too.

The Plan

In 2 weeks (at the PM Team call on Nov 9), we’ll close as “Cancelled - Won’t Fix” all issues in Jira that haven’t been updated in >1 year (since before Nov 1 2019), in ALL projects.

I.e. everyone has the next 2 weeks to review and update tickets that are really old, but you still want them addressed. Issues that are closed will be labeled with a label like “Graveyard 2020”, and we will also have a Jira dashboard that shows all these closed issues.

What You Can Do

Have a look at either the list or (probably easier) the Graveyard dashbaord to see if there’s anything you want kept Active. To “update” a ticket, simply add a comment with a little information about why the issue is still important for the platform or for your organization.

(Important note: Please leave it to me (Grace) to apply the Graveyard label in 2 weeks - if someone tries to do this too early we could accidentally close things others wanted left open. I will walk through this with the whole PM Team so that we learn from this process together.)

Here’s what the Graveyard Dashboard looks like (thank you @ssmusoke for the idea):

Is this a Reasonable Thing to Do?

Yes. Bulk-closing old issues is common practice in software product management. Here’s why this is a good idea for us at OpenMRS.

  1. A closed ticket is not deleted . If we realize later that an old ticket actually was important, we can easily resurrect it and add it back into our backlog. If people come back and say “Yikes, this one was actually a priority, and is still a big problem for us!” That’s fine. We would simply re-activate the ticket and add it back to the current backlog.

  2. It’s been done elsewhere in the OpenMRS community - here’s an example of doing this for an actual OpenMRS implementation that had >1100 tickets.

  3. Our backlog is too old and massive to be quickly useful. This will help us identify what is current and what is important much more quickly than manually trying to go through the almost 5000 tickets that are in our backlog. There are 3,409 tickets not updated since before Nov 1 2019. Average age: 2,344 days unresolved.

  4. This is arguably safer than what we are doing now. With helping organize the RefApp and Platform releases, I’m now really really painfully aware that the backlog of >1500 tickets between these two projects is actually dangerous. It’s almost impossible for me to see at a high level what really matters, and it’s not realistic for us to comb through 600 issues to make sure the RefApp release really does include all critical bug fixes. Leaving old things there suggests that we are looking into those issues, when in fact we might never get to re-reading that ticket at all.

But what is possible is for us to start with a fresher slate.

How will this help us right away?

It will instantly clear up ~56% of all tickets in RefApp and Platform. This it will substantially clean up the TRUNK and RA projects from 1408 to 484 issues.

Why 2 weeks notice?

I’d rather fix this asap, because tickets only pile up as time goes by, and this is worrisome when we want to assure quality releases, like the RefApp and Platform release work happening right now. More tickets generally means less oversight.

We also had several sessions on this back in July and August, and I reached out to a number of people to ask them to review their old tickets to look for things that still mattered. So this isn’t actually out of the blue, I just haven’t gotten back to it until now. Check out my fun, meme-filled Forensic Analysis of our Jira instance in these slides (but seriously, the Jira findings were a wake up call).

What Will Come Next?

Part 2: This will leave behind another 1,290 tickets in all projects, with an average age of over 600 days unresolved. We’ll need to address this next too - that will be Part 2, where we use this other dashboard to identify further opportunities for bulk cleanup. Once we are down to ~400-500 tickets total (no more than ~150 per big project), then we can start Part 3: simplify the workflows. Part 4, we can also start looking at bots to help keep our issue management system fresh.

A Monthly Jira Ninjas Session: Less tickets to review means we can start regularly reviewing new tickets. We’ll be able to track new tickets coming in and give them an appropriate priority level - contrast that with our current state, where most tickets are in a “TBD” state.


We can’t show our community that Jira is a serious, meaningful place, until we are humanly able to use it meaningfully. I’d like to lead changing this, and have heard support from the PM Team and the TAC - join us in making this process better for everyone!


CC @burke @dkayiwa @ibacher @k.joseph @christine @bistenes @mogoodrich @mseaton @ssmusoke @jdick @nkimaina @eachillah @jennifer @janflowers @paul @gcliff @sharif @herbert24 @jwnasambu @gracebish @tendomart @mozzy - please also CC others who should hear about this.

@isears - please have a special look for anything security related that you would like to keep around.


@grace Those images appear to link to your GMail account. Would you be able to replace them with images we can all see?

1 Like

Updated! Thanks for catching that. That’s what I get for making a draft in gmail :stuck_out_tongue:

Awesome, thanks @grace! Although this is a little scary in some ways, I do think it’s 100% necessary…

1 Like

I’m going through the backlog of Graveyard-candidate tickets previously labeled “Blocker” or “Must”. Here’s a practical example of one I just closed:

  1. Notice it was last updated in 2013
  2. Added the label “Graveyard”
  3. Commented on why it’s being closed (so anyone watching the issue will get a notification and will have the chance to re-open it if they chose)
  4. Marked as “Closed - Won’t Fix”

Did we agree to add the year of graveyarding to the label?

Great question. So, I was originally going to. Then I realized this would mean that any time we did a clean up (or a bot in the future did), we’d have to go into the Graveyard dashboard and update the search filter to query “Graveyard Oct 2020” AND “Graveyard Jan 2021” AND… and so on.

If we just use the label “Graveyard”, then we won’t have to maintain the dashboard/graveyard search queries like this. But we’ll still be able to do timeline-based searches, because when we do the bulk closure, we’ll add a comment like “This issue is being closed as part of the Graveyard Oct 2020 initiative. If you are aware of a reason this should be reopened, please…” etc. This will give the tickets all the same “Last Updated Date”. Does that make sense?

But, the other thing I could do is use the label “Graveyard Oct 2020”, and then just make sure all the tickets with that label also have the Graveyard label.

Shame on JIRA for not supporting wildcard searches on labels.


Thanks so much for working on this, @grace!

All issues put in the graveyard should share one label (i.e., graveyard). I think it’s a great idea to add another label for the graveyard run (e.g., graveyard 2020-11).

It would be a nice touch – if it’s easy enough to do – to edit the reopen transitions for active workflows to remove the graveyard label. Otherwise, a report looking for any tickets labeled as graveyard that are not closed might help (should always be empty list), to ensure we don’t let graveyard linger on tickets that get reopened.

1 Like

Great point. We can do this.

I was thinking this too. Looked at a few Atlassian community posts (e.g. this one) and seems like this is a long standing community request, but there’s no feature available yet without an Add-On or script.

The report idea is a good simple thing to do. So I’ve set up a query and dashboard to double-check for things like that here in the new ZOMBIE CHECK Dashboard, using the JQL search resolution = Unresolved AND labels = Graveyard. I’ll leave this pinned to my dashboard nav and check it from time to time, and we’ll embed this double check practice into our Jira Ninja’s Club process :wink: Still fairly manual, but fast, and should over time give us a sense of how often this edge case happens.

Just want to spotlight the work done by @mseaton today shared via slack:

Mike checked the Graveyard Dashboard for tickets that he had created, which will be affected by the Clean-Up on Nov 9. He did this by going to the Graveyard Dashboard and clicking his name in the “Creators” widget:

Here’s his findings:

** I just went through the 169 issues in the Graveyard 2020 Candidates where I am listed as the creator. I pinged 2 or 3 to keep them active, but agree that the vast majority can (and should) be closed and sent to the Graveyard. Thanks for doing this - I do think it’s going to allow us to focus a lot more on what is actually important and desireable to work on.**


What if I don’t see my name on the Graveyard Dashboard?

No problem - this query should show you any issues you created in the past that will be sent to the Graveyard next week:

resolution = Unresolved AND updatedDate < 2019-11-01 AND creator = currentUser()

Happy backlog cleaning! :broom: