tl;dr: In 2 weeks, I’d like to auto-close any issues that haven’t been updated in >1 year, and add those to the Graveyard. (About 200 issues.) This is to keep our Jira clean and relevant, so we know what matters.
Please have a look at the issues that would be affected here and add a comment to any issues you’d like to keep open. (You’ll need to remove the “Graveyard_CANDIDATE” label as well.)
Hi Community,
Last year in Nov we did a big Jira clean up that reduced our issues from >4,000 to 1,200. In the last quarter I’ve personally found it much easier to review tickets as they come in, rather than trying to hunt through a massive backlog. I haven’t noticed many tickets at all being resurrected.
We’ve also put in place new processes. Every Monday our PM Team does the following:
We review all issues filed in the last week (that don’t already have someone working on them) so that we’re aware of what’s coming in, as it comes in
We look through all tickets marked as “Blockers”
We look through tickets marked as Community Priority that are stuck “in-progress”
However we still have a problem: 1,200 issues is too much to manage, and in the PM Team we’re still spending time trying to understand old issues only to find that they’re no longer relevant. We also still have a big backlog of old, non-triaged tickets. I’m still concerned that there’s noise in here hiding things that really matter - as seen in the huge amount of “Should” and “TBD” tickets.
Our average issue age is 656 days (1.8 years old). Much better than it was in November, but I’d like to see this be <1 year. Because if we’re honest with ourselves, things that are open more than a year are very unlikely to get attention again, and the knowledge needed to address those older issues quickly grows stale.
How this would work:
I’d label all issues not updated for >1 year as “Graveyard_CANDIDATE” and add a comment: “This issue has not been updated in >1 year, and so has been identified as a Graveyard candidate - i.e. it will be closed in 2 weeks. If you want to keep this issue open (e.g. because it remains a priority or important thing to fix), please add a comment here explaining why, and remove the “Graveyard_CANDIDATE” label. For questions, you can reach out to @grace (@grace on slack or @grace on Talk).”
In 2 weeks, we’d close as “Won’t Fix” all these issues, and label them as “Graveyard”.
If someone wants to re-open it, they can still do so.
I don’t really have an objection to going through the graveyard process again. I think, though, that we should likely have some process to review those tickets in the potential graveyard queue that are in “Code Review” status. At the very least, if we move them to the graveyard, we should also close the corresponding PRs.
@dkayiwa@isaaclin about 50% of the old issues were created by @isaaclin and look like they were specifically created for GSOC2020 onboarding. Can these all be closed?
I was actually going to send an email alert to every ticket reporter that these issues would be closed, but that would have sent Isaac about 100 emails!
Update: I went through all the in a “Code Review” stage. I tagged you @dkayiwa in a lot of those PRs so if you could have a look through those in GitHub - some may be better to just close, I’m not sure.
Out of the >40 of them, only 3 had work that had actually already been merged.
Going forward, my recommendation is that we label just a few of them per day, instead of all of them at once. I got so many notifications in my inbox, and as a result, i just marked all of them as read (Ignored), instead of looking at them one by one.
Labelled everything closed this round as “Graveyard-2021-04” or “Graveyard-2021-03” depending on when I closed them: Issue Navigator - OpenMRS Issues
Positive Results
This also helped us identify ~10-20 tickets that were still a priority for organizations like PIH. Special thanks to @dkayiwa and @mseaton who were especially active in reviewing old PRs or evaluating old work requests that were still valid.
How are we doing now?
Average Ticket Age: 1.8 years. @dkayiwa and I want to see this get to <1 year. (Which will be symptomatic of other process changes.)
I’m happy to see our total issue counts broken down by project - 50-70 issues is reasonable for smaller teams, and ~200 is reasonable for our largest projects. This is where we are now.
What’s Next?
Over the next ~2 months there are 2 things I’d like to see improve.
Fewer tickets in “TBD” priority status. It worries me that half of all our tickets don’t appear prioritized - are there critical/serious issues in here? “TBD” makes it hard to tell. Plan: (A) to triage a ticket with our squads any time we see an issue in the “TBD” status, (B) to add the Priority field to the Ticket Creation step (seems the priority is often not added because it’s easy to create a ticket and then move on), and (C) community education about why it’s important not to leave things in “TBD”.
Making Jira easier to use. People still get stuck dealing with irritating workflow things (e.g. our RefApp workflow makes it a hassle to try to assign anyone to a ticket).
Stay tuned for more Jira improvements to come. If anyone is interested in helping, just reach out and let me know.
Sure! So here are the 2 first steps I’d recommend anyone do. The most helpful thing with keeping Jira clean sustainably is thoughtful review by people who really understand individual work tickets, one ticket at a time. So please try these first 2 things and then let me know once those are done, and I can definitely find more areas of work after that
Created by you. Check for any tickets you’ve created in the past that are still open. See if they still need to be worked on, or if they actually are no longer relevant and can be closed. This search link should help: Issue navigator - OpenMRS Issues
Assigned to you. Check for any tickets assigned to you that are still open. See if you can wrap up the work (especially for anything that’s TRUNK or RA). Sometimes this may mean prompting PR reviewers to take another look; sometimes it means going back to one’s PR to action on the feedback given there. Main thing is that if a ticket is assigned to someone and it hasn’t had any updates in >1 month, this doesn’t look good; the assignee should make sure that the work is either making progress and being committed, or they should unassign themself so someone else can take on the work. Issue navigator - OpenMRS Issues
@grace, I would love to work with you in cleaning up OCL for OpenMRS’s tickets, as we already have lots of undecided tickets which I really want to clean up. Also, it’s uncomfortable to create more tickets without resolving the existing ones.
Love it
Where I’d start: Can you go through the issues that we labelled as “Discuss in Squad”, by looking through the oldest ones first? There are couple that look like they may need some review/reading, but likely aren’t very needed anymore; you’ll likely be able to make a recommendation to close them that we can just confirm with the squad: Dashboard - OpenMRS Issues
Done - I’ve closed all the 76 tickets that were created by Isaac Lin with no updates for >1 yr.
