What do you get from a 10+ year old open source framework, thousands and thousands of users within a wide range of roles, and tremendous complexity? A JIRA project with over 3,000 unresolved tickets, ranging from the brand-new to a stale 8+ years. Welcome to Hibernate ORM.
Is the large number indicative of low software quality? Definitely not. And therein lies the problem. A vast majority of the tickets are no longer issues, no longer relevant, or duplicates. But due to the sheer quantity, it became nearly impossible to weed through them.
I became the self-appointed “JIRA czar”, in an attempt to clean it up. The following details the steps I’ve taken, so far, in case they’re useful to other teams in similar situations. Unfortunately, while some steps are automatable, the majority require a lot of tedious, manual work. But in the end, it’s worth it.
- Manual query*: keywords “reject” or “can’t reproduce” (and variations). Our community, thankfully, often attempts to reproduce older issues and will comment, but we don’t always notice the message.
- Manual query*: <= 1 vote. This often signifies “staleness” for bugs or a lack of interest/relevance for new features.
- Manual query*: low number of watchers. This can also signify “staleness” or lack of involvement, but is far less reliable.
- We use a custom “Awaiting Test Case” state. If a ticket has sat in it with no response, beyond a given threshold, automatically reject.
- Manual query*: participants list includes a core team member. This turned up numerous tickets where a team member mentioned a lack of feasibility, feature misunderstanding, etc., but for whatever reason did not actually reject the ticket.
- I started a really rough script, using the JIRA API, that attempts to discover duplicates by analyzing stacktraces within the tickets. It’s definitely a work-in-progress, but has already proved useful. To use it (or contribute), please see https://github.com/brmeyer/BugTrackerDuplicateUtils. Alternatives do exist, but I haven’t found any that are 1.) open source, 2.) still maintained, 3.) not horrendously complicated and 4.) usable for Java-related text. If anyone has suggestions, I’m all ears!
* denotes the addition of common query parameters: unresolved, unassigned, and reported by someone outside of the core team.
Through the above steps, I’ve been able to close out nearly 1,000 tickets. And that does not mean I’ve become trigger happy and closed issues that really are still problems. But frankly, I’d rather be overly aggressive and rely on the community to push back if something is erroneously closed. Being too conservative will not help.
To help prevent this situation from happening again, I’ve implemented some regular steps and rules:
- Check new tickets each morning.
- If the ticket is a question, say so, politely request use of the forums, and close.
- If no test case is provided, set to Awaiting Test Case and request one.
- Continue to automatically reject tickets sitting in Awaiting Test Case for more than 2-3 months with no response.
- Above all, do a better job of educating users, rather than scolding them
If anyone has other tips, please post them!