Using Dropbox to Track Bugs
-Each bug is a .txt file whose name is the description of the bug.
-Dropbox keeps track of who creates / edits files so if someone botches a description you can always figure out who wrote it up and when. (Unix does a decent job of this too.)
-You can assign bugs by putting "#fixer_name" at the top of the file and grepping for "#fixer_name" on the command line.
-When bugs are done you move them to the "done" folder. If you duplicate a title it overwrites, but dropbox has your back w/ revision edits.
-You can preform any sort of command line voodoo to slice and dice your bugs.
-You know when bugs are posted or fixed through the dropbox notifications.
-You never have to leave the command line and go to a web app to enter bugs. The result for us is that we enter more bugs.
-You can casually browse your bugs using the preview feature on mac:
http://dl.getdropbox.com/u/147719/bugs.jpg
We didn't have the money for FogBugz and we were using BugZilla which is so miserable that we resorted to not using it. There are certainly features dropbugz lacks, but for basic bug tracking for a small team, it is awesome. And any feature you want to add is just a script and a chron job away. I've used a bunch of web-based bug trackers in the corporate and startup world and this is the only one I've ever liked.
I look forward to hearing HN's thoughts on extending this wonderful tool...
Big ups to
http://news.ycombinator.com/user?id=martian
for coming up w/ the idea.
23 comments
[ 2.6 ms ] story [ 30.9 ms ] threadI say again though, I'm working w/ a small team of developers and my needs are modest. And if dropbugz fails me I'll check out lighthouse.
bug=your/dropbugz/folder
in a .bashrc file ON dropbox. Have all your ~/.bashrc's on different machines source the one from dropbox and you're set. Now entering a bug is just:
echo "App crashes on launch" > $bug/epic_fail.txt
We do something really similar using git. Our "done" directories are dated ("done-08-q4") and we also have "testing" and "delayed" directories. Issues are moved to the testing directory in the same commit as the code changes and then to the done directory with a release.
You apparently knew how to do it with BugZilla, so why not Trac?
I clearly didn't do much homework on this. But I stand by our solution even if it was made in ignorance. It is the only bug tracking tool mentioned (besides the guy using git, good idea btw) that doesn't interrupt the workflow.
We use it, and are happy with it.
and yes, I am being sarcastic..
I suppose I could retain the "never leave the command line" thing by composing e-mails to Lighthouse for new bugs in mutt via vim, but that seems like more work than tabbing over to the Lighthouse Keeper window...