Issue Tracking with Email
Issue Tracking with Email
Issue tracking is a very annoying topic when dealing with disorganized development. When part of a team working on the same project, using some sort of tracking system like Jira, trac, Bugzilla, or any of the million and a half other trackers becomes a natural requirement that eventually gets implemented into the workflow. A problem I've had in the past is the unwillingness of a client to want to use one of the systems. I had to figure out a way to appease their desire to not bother while keeping items in some sort of order and to provide historical records of requests and conversations.
Properly communicating on a project can be a strain at times for smaller operations, and adding in extra steps to the workflow can make it self-destructive. A past client wanted to talk to me directly and not deal with a system. "Email is fine," they said when pitched the idea. If email is fine, then email is was to be. I needed to somehow use email, but also needed the ability to add items if they told me in person or over the phone.
There are a couple options I came up with. The first was simply creating an email account dedicated to this project that they'd communicate with. This solved my problems, but the client refused to communicate through another email address since they already knew how to get in touch with me through the existing email. I later also realized this solution might be difficult to expand to beyond one principle developer.
Another solution I came up with was to set up filters that would direct communications to various folders for projects, but this solution quickly polluted my email account with unneeded fluff.
What Worked
So what eventually became the solution was a somewhat mixture of what I've described already. I created a separate email account to handle what I needed to keep track of and set necessary filters and folders there. I would maintain standard communication channels with the client through my standard email account, and when something would be requested, I'd forward their email to the issue tracking email address with my comments. Whenever I needed to make a note, I'd either email to the address or forward a correspondence over. Most modern email clients allow for threaded conversations, so I'd easily be able to see historical information for different issues by viewing the tracking email account. Also in that account, I could easily move a conversation from folders or labels that represented different statuses like "open", "closed", "awaiting comment", etc. My method for this particular client was to have that inbox for "open" issues, and have an archival folder for "closed" issues. By collapsing all conversations, I could quickly assess the status of the project and see how many outstanding issues there were.
Never did I send emails from the tracking account; it was for organization to track the progress of the issues.
This was my email issue tracker, an issue tracker for dummies.