Bug Tracking and Customer Support Tools
Daniel talks about finally moving from Mercurial to Git and the advantages of standardizing on technologies that have “clearly won.”
Manton talks to Daniel about his decision to switch from Zendesk to Help Scout, and gets Daniel excited about the prospect of finally switching away from FogBugz for his own work.
Daniel tells Manton about finally leaving FogBugz and going deep on Help Scout and GitHub Issues. Meanwhile Manton has also finished his migration to Help Scout! They talk about their mutual satisfaction with Help Scout and about how to best manage GitHub Issues.
For bug/issue tracking, I started out with FileMaker Pro, then CVSTrac, then Trac when I switched to Subversion, then OmniOutliner Pro. When OmniFocus came out it was a revelation, but ultimately it didn’t scale for the number of issues I had. I used FogBugz from 2009 until 2017 when I got fed up with the bugs and unreliability and the design got weird. Then I switched back to OmniOutliner Pro, which had improved a lot in the meantime in features, though I’m convinced that the interface brought back from iOS remains slower. This worked well for a while, but I kept running into scaling problems—particularly slow typing—even after splitting my issues into separate documents for each product and for current vs. archived issues.
Early this year, I did a trial with Gitea. Run directly on my Mac, it’s fast and works offline. I’m not dependent on a cloud service. The interface and feature set are good. It has an API and a command-line tool, and of course I had full access to the SQLite database itself if I wanted to do a fancy query. But, ultimately, I got annoyed by editing text within a Web app, and it was not as flexible with filtering, searching, and bulk operations as I wanted.
I’m now using EagleFiler, with each issue as a Markdown file, folders for milestones, smart folders for particular queries I care about, and tags for things like Area, Cause, Status, and Type. The GUID portion of each EagleFiler record’s record link is a natural identifer that I can put into code comments, Git commit messages, and other issues. The issues themselves are also in Git, so I get automatic backup, history, and syncing with my other Macs. Files related to an issue get attached to its note. When there’s a complicated issue that I want to work on, I open the Markdown file in BBEdit, where I get more editing tools and a live preview. I can automate things (like collecting release notes) via AppleScript and do bulk find/replace with BBEdit. In retrospect, it’s obvious that I would enjoy using my own native app, and that the app itself would benefit from such dogfooding, but for a long time I had a mental block about using it in my development workflow because there are times when it would be inconvenient to use the app as a tool while developing and testing it. So far, this has not been a problem. EagleFiler stores everything as regular files in folders, so if the app itself is unavailable, I can still browse/search issues using BBEdit projects or LaunchBar, tag them in Finder, etc.
For customer support, I’ve used regular e-mail (in Mailsmith, Apple Mail, and EagleFiler) except for the time I was using FogBugz. With FogBugz, e-mails got a case number so it was easy to link them from issues. Now, I do that using the Message-ID.
Previously:
- The Longest Atlassian Outage of All Time
- Swift Bugs Moving to GitHub Issues
- Manuscript (FogBugz) Sold to DevFactory
- FogBugz Becomes Manuscript
- Improved FogBugz Cases Menu
- Subversion to Git
- OmniFocus Data Storage
- Switching From Trac to OmniOutliner Pro
- Migrating to Trac
- cvs2svn
- CVSTrac
3 Comments RSS · Twitter
Great process history description. Thanks for sharing.
Does your shift to EagleFiler leave OmniOutliner or OmniFocus for anything in your workflow?
@Sean Yes, I still use OmniOutliner for all sorts of lists and simple spreadsheet-type things. And I still use OmniFocus for managing my daily to-do list, recurring tasks, errands, etc.
I tried using OmniFocus for issue tracking for a while, but it's just not built for that job. I've currently settled on Gitea on a local server. But, I still hate git with the intensity of a thousand suns. I use Breezy (https://www.breezy-vcs.org) for version control which can use the git repository format. That's now I'm threading the needle between using a better tool while conceding that the entire industry has standardized on git.
