These days, we have four active projects. One each for Sifter, Marketing, Ideas, and the book. The Sifter project is self explanatory. This is where we track any work that needs to be done related to the application or the infrastructure where it lives. Marketing lets us manage any advertising, blogging, emails, or updates to our marketing web site. Ideas is much more open-ended, and the book project is for handling everything from typos to how we might offer additional formats.
The Sifter project is primarily organized by milestones. These almost always correlate to a branch or pull request on GitHub. However, we also make heavy use of the “Unplanned” milestone. Any minor bug fixes or other tweaks that need to happen but don’t justify a dedicated milestone get filed without a milestone. For us, “Unplanned” doesn’t mean “No Plans”, it simply means that it is work that needs to happen but isn’t part of the plan. Another way to think of these issues is “Hot Fixes”. While milestone-centric updates are less frequent, these smaller unplanned updates happen almost daily.
Beyond that, we try to keep 3-5 active milestones. In case, this is primarily a factor of team size and availability. Since I’m the only person full-time on Sifter, and I’m not doing development full-time, we really don’t have any full-time developers. We’ll generally have an active milestone for each person’s main focus. Then, once that milestone reaches a point where we can actively discuss its direction, the person leading the charge on that effort will open a pull request on GitHub. From there we’ll do some testing, review the code, and, if necessary, log new issues or questions against the branch.
The marketing project is less exciting, but it’s a great example of how well Sifter works for handling much more than just bugs or issues. One of the most useful ways that the marketing project helps is by keeping tracking of likely topics to blog about. Most of the inspiration for blog post topics is a direct result of answering support emails, but keeping a backlog of potential topics helps us recognize when we’ve heard enough questions to address the topic. If that topic seems like a good one, we add comments as we evolve the idea. Then, when we’re ready to blog about the topic, we have a collection of thoughts around what to write about. Similarly, any changes to the marketing web site go through the marketing project so that they don’t distract from core development.
We originally filed all of our “someday” ideas inside of the Sifter project. However, we’ve found that it’s much more productive to keep them out of the way. If an issue is in the Sifter project, we fully expect to take action on it at some point in the near future. Otherwise, it doesn’t belong there. The main project is for action, not talk. The ideas project gives us a place for the talk and is sub-divided by categories like API, Billing, Notifications, Search, etc. So whenever we decide to work on a specific area, we can also hop into the ideas project and filter the ideas to see if there are any relevant enhancements we could knock out at the same time. Naturally, since the ideas project is more of a sandbox, we don’t use milestones for it at all.
With the ideas project, though, we can toss any half-baked idea into the project with reckless abandon. Think of the ideas project as a safe place for good and terrible ideas alike. If we can easily log an idea and get feedback from others, we can slowly build both a detailed backlog as well as a collection of knowledge around our decisions. Once we make the decision, we can close the issue. Then if it comes up again the future, we just reopen the discussion. If we decide to do it, we can either move the issue into the Sifter project or, if it’s large enough in scope, create a milestone for it in the Sifter project.
For instance, we might have a discussion about Markdown support where we’ll talk about the pros and cons until we reach a point where we’re comfortable with a decision. Then, if the topic comes up again a month later, we have a clear record explaining our earlier decision. We can then easily evaluate whether our original concerns are still valid. By documenting our thought process, we know we can always go back and question our original assumptions.
Writing a book is an interesting project. Most of the issue tracking revolves around editing, but there are many other components that need to be tracked on an ongoing basis. Books have bugs, todos and issues just like software. Cover design. Payment processing. Formatting. Fonts. The web site. Announcement email. Typesetting. Having a central place to track and discuss these items makes it easy to stay on track. And by keeping it in the same location as our software development projects I was able to more easily juggle multiple projects without missing anything.
Issue Tracking as Project Management
Sifter is a great bug and issue tracker, but can also serve as a great project management tool. It’s explicitly designed to be abstract enough to track much more than bugs and issues. We believe that everything needs an explicit resolution. Sometimes that resolution may simply be “tabled” or “out of scope”, but by saving those resolutions for future reference, we’re able to maintain a starting point for any future discussions without rehashing the same old stuff every time. Open-ended threads about a topic are alright, but the value of always thinking in terms of closure, resolutions, and accountability help maintain forward progress and keep everybody on the same page.