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.
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.
- Total list of tickets not updated in >1 year: https://issues.openmrs.org/issues/?filter=23053
- Dashboard of tickets currently eligible for the Graveyard: https://issues.openmrs.org/secure/Dashboard.jspa?selectPageId=15751
(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.
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.
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.
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.
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!