While Sifter is first and foremost a bug and issue tracker, it’s also the perfect place for keeping notes for future reference. Over the years, we’ve had countless features or design solutions where we’d make a decision and move on. Then, a month later, we’d be looking at it and wondering what we were thinking. Similarly, we’ll occasionally fix a big and then encounter a similar problem down the road, but we can’t remember what did to fix it.
With detailed resolutions you never have to remember. You just go back and look. So we wanted to offer up some suggestions for writing good issue resolutions. By recording decisions, resolutions, and your thought process, you’ll always have a historical record to help out when your memory fails you.
- Obscure Bugs – I know we just fixed this problem on page X, but I don’t remember how we did it.
- Design Decisions – Should the logo be bigger? How should feature X work?
- Business Decisions – Did we decide on 30 or 14 day trials? Are we going to charge $50 per month or $49?
Similarly, a lot of things that seem like they should be issue statuses, but they actually work better as issue resolutions. For instance, simply classifying an issue under one of the following groups doesn’t really help because you’d never need to filter on them. However, if you close or resolve the issue and enter detailed information about the reasoning, the burden of responsibility returns to the opener, and you have a clear chain of conversation for historical records. More importantly, providing a detailed explanation can go a long ways in creating a satisfying resolution for everyone.
- Can’t reproduce – Why not? What did you try? Are there any questions you ask to clarify so that you might be able to reproduce it? Often, with just a little followup and care, these pesky issues can easily be reproduced.
- Working as Designed – This can be a touchy subject, but it’s also a great opportunity to clarify any potential miscommunications. Moreover, when the topic comes up again, and it will, you’ll have a historical record of the conversation and agreed upon outcome.
- Feature Request – It’s not always clear why something is a new feature rather than a bug. This can be especially divisive in the case of usability enhancements. One person’s usability requirement is another person’s icing.
Remember, resolutions should be conversations, not merely outcomes. It’s not about finality. It’s about engaging the other people participating in making the software better and providing clear explanations and insight for future reference. If you’re not regularly circling back to look up the outcomes of old issues, you’re missing out on one of the greatest benefits of issue tracking.