FogBugz Technical Support

A forum for technical support discussion related to Fogbugz.
The current FogBugz Knowledge Base can be found at

Posts by Fog Creek Employees are marked:

Release Notes
Network Status

Challenges with Fogbugz...

We're finding ourselves beating our heads against the wall, over and over, with FB.  The biggest issues include:

-No workflow, so very little control over how bugs and features move through the process.  They move differently.
-No real differentiation between features and bugs, including (tallying up requests/popularity for features to determine where dev resources should be directed.)
-Issue reporting is visually confusing and very difficult to sift through when you have many customers reporting on issues.
-No way to delete comments/contributions on a topic - not all comments are valid or useful, and it's annoying to sift through it all the time.
-No custom fields (yes I know you hear this all the time).  We *have* to add 2 or 3 of own specific fields to the issues.  I've read where FogCreek stands on this, and this actually is one point that makes me irate.  I get the need to keep things simple, at the same time, FB doesn't match what my business requires, and we can't keep changing our processes to match FB's design - it just has stopped making sense.

We only have 26 licenses, so I'm sure we're small potatoes, but FogBugz has moved in the last year from an asset, to being an impediment. 

At this point, since we have no visibility into future features, and since the custom fields issues is now a requirement as far as I'm concerned, I'm forced into the unpleasant distraction of researching 2 other possible solutions.  (my point is not to bash FogCreek, so I'm not naming the 2 solutions)

So what's the point of this post?  Well honestly, it's to whine and vent a bit - but only because in a perfect world FB would be growing with my business so I could keep using.  Also to say that FB is a great solution for smaller companies or companies with simpler processes.  And I mean a great solution.  The simplicity is a key value proposition, and it's one of the drivers of our own business products, so I get it. 

That's it, and if anyone from FogCreek has something to say to refute my observations, or talk about future versions, feel free to contact me...

 A future former customer...
Tony P Send private email
Friday, October 17, 2008
Thanks for the honest feedback.  We treat this as a favor and we're glad you took the time.

First off, honestly there's not such a thing in my/our mind as a small-potatoes customer.  I've spent 45 minutes on the phone with a single license customer before, and the stuff that came out of that call was at least as valuable as the time I spent on it.

We've started real work on the next version of FogBugz, and the most that I'm allowed to say is that it's all about flexibility.

We've heard most of these many times.  The one thing here that doesn't ring a bell, though, is the visually confusing issue reporting.  Can you elaborate?
Rich Armstrong Send private email
Monday, October 20, 2008
I simply mean that we have people who enter bugs, then add more comments right after, or then post an attachment, etc, and because every entry is annotated with the who/when (and it can't be hidden), and  the entries are run together (left aligned) there can be a lot of extraneous data to look at.  In the same vein, sometimes there are lots of different comments (or in the case of the automatic crash reporting, which we use) we can get dozens and dozens of separate comments (or individual customer crashes) visually mashed together, and it's almost impossible to distinguish one comment from another.

Conversation threading, alternate colored bands for each submission, a horizontal rule - something needs to separate and distinguish one edit from another.

I know it sounds like i'm saying opposite things - less distinction/more distinction - but depending on the nature of the submission, we need both.  Sometimes all the submission/change audit info is extraneous, sometimes it's important. 


Wednesday, October 22, 2008
Thanks for that.  I can definitely see where that could be a problem.  So something like collapsing similar bug events into one, and visually differentiating bug events from each other would be useful, right?  I'm opening a case.
Rich Armstrong Send private email
Thursday, October 23, 2008
To add to this, there are some companies like mine that do not even really care to have the full edit log.  For example I dont care if a case was changed from medium to high.  Can those log items be hidden?
Thursday, October 23, 2008

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz Bug Tracking and Evidence-Based Scheduling.