

Using Dropbox to Track Bugs - uuilly

Being a tiny startup looking for ways to save money, we discovered the best, cheapest bug tracking software out there.  It's dropbox (or dropbugz).  Simply make a folder called "bugs" in your dropbox and put a "done" directory in it.<p>-Each bug is a .txt file whose name is the description of the bug.<p>-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.)<p>-You can assign bugs by putting "#fixer_name" at the top of the file and grepping for "#fixer_name" on the command line.<p>-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.<p>-You can preform any sort of command line voodoo to slice and dice your bugs.<p>-You know when bugs are posted or fixed through the dropbox notifications.<p>-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.<p>-You can casually browse your bugs using the preview feature on mac:<p>http://dl.getdropbox.com/u/147719/bugs.jpg<p>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.<p>I look forward to hearing HN's thoughts on extending this wonderful tool...<p>Big ups to<p>http://news.ycombinator.com/user?id=martian<p>for coming up w/ the idea.
======
gregwebs
bug tracking should be integrated with the version control system. If you use
git there is ticgit or something like that which just maintains a simple file
of bugs. But when you checkout a branch you can see what bugs are open on that
branch, and when the branch merges, it will merge its closed bugs.

~~~
tdavis
This is my biggest argument, which is why I use Lighthouse since it integrates
very easily with Github. I don't like my bugs to be meaningless text files;
it's far more useful to have them tied to VC so I can see what work has gone
into a bug/feature, which commit fixed something, etc.

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...

------
dawie
Fogbugs is Free for 2 people
<http://www.fogcreek.com/FogBugz/YCombinator.html>

------
toxik
Why not just set up a Trac?

You apparently knew how to do it with BugZilla, so why not Trac?

~~~
uuilly
You give me too much credit. I pay for secure offsite svn. They were providing
us w/ bugzilla :)

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.

~~~
run4yourlives
You could use svnrepository, which would give you trac instead of bugzilla for
like $4 a month. I use them a lot for my stuff.

------
uuilly
And furthermore, you can set

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

------
larsthorup
I don't know if I should smile because this is a nice example of how to find a
simple and pragmatic solution to some problem you have. Or if I should cry
over all the bugs they are now going to track instead of fixing them, see "Why
Bugs should not be Tracked" at
[http://www.bestbrains.dk/dansk.aspx/Artikler/Why_Bugs_should...](http://www.bestbrains.dk/dansk.aspx/Artikler/Why_Bugs_should_not_be_Tracked)

------
delano
Ya, the command line is your friend.

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.

------
koraybalci
if you are a small team and you don't want to waste time on logging in to a
client such as trac, etc, why not just use plain paper (postit?) and a pen,
pinned on the office wall.. that sure is cheap and has all the perks of your
system..

and yes, I am being sarcastic..

~~~
rshao
Doesn't work if they work from home.

------
wenbert
<http://xp-dev.com> the "bug tracker" isn't that complete yet. and for now,
only one team member is able to access one project (yikes) but they do allow
hosting of commercial projects. for free ;-)

------
dhouston
sweet. goodbye fogbugz :)

------
peterbe
IssueTrackerProduct is free and is just as good as FogBugz
(<http://www.issuetrackerproduct.com>)

------
fallentimes
Good idea, but have you looked in to lighthouse?

~~~
uuilly
Right on, it looks really nice, but w/ dropbugz you never leave the command
line. You never log in to a site or search a DB or tag things etc etc. It's
just ls'ing grep'ing and vi'ing. I find it less tedious and thus I'm more
prone to log bugs as I develop / test.

I 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.

------
ashleyw
Good idea, I prefer either Basecamp or Lighthouse though (both affordable).

------
babyshake
Such a good idea. Thank you.

