We refer to Sifter as a “bug and issue tracker”, but really, it’s just a fancy team todo list. You can track bugs, but that’s only the tip of the iceberg. Internally, we dump almost everything into Sifter, and it just might be useful to see how flexible Sifter can be. It’s no accident that Sifter has fixed statuses or that we chose the words “resolved” and “closed” to represent that later stages of an issue.

It’s also the driving reason that Sifter issues have a very simple set of attributes so that they apply equally well to all types. For instance, fields like URL, User Agent, and Operating System aren’t very useful for non-technical matters. Moreover, a URL field only makes sense for web-based software. Of course, just because there aren’t dedicated fields for these pieces of data doesn’t mean that they can’t be added to the description. With full-text search, it’s still just as easy to find them later.

Bugs

Let’s get the obvious one on the table. Sifter is great for tracking bugs. We track all of our own bugs in Sifter. (It isn’t perfect for sharing code just yet, but it’s on the radar.) With bugs, “resolved” represents the state where the bug has been fixed, and “closed” represents the state where the fix has been reviewed, ideally by the original opener, and approved. With some smaller bugs, we might skip retesting and just close them out right away. However, with larger, more complex bugs, we’ll mark them as “resolved” and make sure to review them in staging before we officially close them out.

Issues, Questions, and Discussions

Not everything is a bug that can be solved by changing code. Some things are more generic problems that need to be addressed or just high-level questions that need an answer. For instance, things like pricing or philosophical approaches to problems need a forum to discuss and work towards a discrete outcome. For example, if we’re evaluating a couple of vendors or considering switching vendors, we’ll create an issue in Sifter to handle the discussion. Then, regardless of the outcome, we have a discussion thread to circle back to later.

Ideas

Internally, we even have a dedicated project for ideas. You might think of it as an icebox or a backlog, but it’s really much more than that. We discuss everything from new features to marketing to areas that may need refactoring. Not everything that’s an idea necessarily graduates to be implemented, but it provides a great location to throw out suggestions and see what folks think. (As a side note, this is a little more difficult with larger teams because we don’t make it easy to notify multiple people, but we’re working on that and should be adding @mentions in the very near future.)

New Features & Enhancements

We keep all of the ideas for new features and enhancements in our “Ideas” project. We’ll track discussions and log interesting customer suggestions as well. Even when we decide not to build a feature, we still have a record of our decision and how we arrived at the decision. That way, 6 months down the road when we start to second guess ourselves, we have a clear explanation of our thought process. This gives us the context to either say “well things have changed since then” or “oh yeah, there’s now way we’re going to do this”.

Tasks, Todos, and Action items

Some things aren’t even problems or inherently negative. They’re just tasks that need to be done by a specific person. Anytime something might take a couple of days, we toss it in Sifter. There might not be any discussion about it at all, but it provides a place for updates on every ongoing task. For instance, if an SSL certificate is going to expire in a few months, we’ll create an issue that someone needs to address it. Then, that issue can be updated with status information as the process moves along. If anyone is ever curious about where it’s at, they can hop into the issue and see without having to interrupt the person responsible.

Summary

Sifter doesn’t differentiate any of these types of data internally, because it’s generally not relevant. It’s a distinction without a difference. At the highest level, it’s all simply bits of data that need a formal resolution. It’s work that needs to be done regardless of what “type” it is.

In general, there’s three key points when tracking this stuff. First, it’s about getting data into Sifter, which means making sure that all of the different types of data fit comfortably. If the data isn’t in the app, then nothing else matters.

Second, it’s about enabling a workflow towards a discrete outcome. Issues need to be closed. There’s no “on hold” or “pending” statuses because that’s a way to avoid taking action one way or the other. Our philosophy is that either it’s going to get done and closed as completed or it needs to be closed out right away if it’s not going to happen.

Finally, it’s about a central and searchable place to record decisions. We’ve all had those moments where we look back and wonder “why did we decide not to do this?” or “what was our final decision on that problem?”. Verbal agreements are worthless. With an issue tracker, everything is documented, and it’s always accessible. If your bugs were in one system and your issues or questions or enhancements in another system, that’s not easy to figure out.