Fog Creek Software
Discussion Board

Wanted features


We're considering replacing our current bug tracking system. FogBUGZ seems like a compelling alternative.

I've read the thoughts behind FogBUGZ at While I completely agree that it should be extremely easy to enter bugs and that any overhead should be avoided, I don't like the idea of not being able to add custom fields.

Having been at Microsoft and used Microsoft's own RAID for a few years there are a few features that currently prevents us from moving to FogBUGZ. Here's what I miss mostly:

* Severity - The possibilty to assign a severity to each bug, in addition to priority.
* RelatesTo - The possibility to relate multiple bugs and click to move between them.
* SubArea - In addition to setting an area of the bug, each indivudual team can also have subareas within their area of development.

Are these planned features for FogBUGZ?

Thursday, November 27, 2003


My issues are even more basic:

I want two fields:

  Found in build  (part of problem report)
  Fixed in build    (part of resolution)

Also, there seems to be no logical way to pipe workflow toward documentation.  The only way is for the developer to assign it to the writer.

I would prefer for the developer to:
  Resolve    the item

then for the tester to:
  Confirm      the item

<at this point it is closed>

The documenter then looks at all confirmed things that are not yet Documented    (checkbox)

Make sense?

Friday, November 28, 2003

I agree with both of the above posts.  Any chance a fogcreek rep could respond?  Custom fields (i.e. data driven from the customer's standpoint for adding fields) are a huge feature that we need.

martin sweitzer
Wednesday, December 31, 2003

I'd like to add another vote for a "severity" field...we find that very helpful in our environment.

Thursday, January 22, 2004

I asked about piping to documentation several months ago. We're just getting started and are trying this workflow:

Documentation produces a list of resolved/closed cases since a certain date. They review the list. If they determine that documentation is required. They create a case that says "Document bug xxx".

We have created a separate project for documentation. I kind of like this method because the documentation update is not always in sync with testing. Entering a separate case allows us to have a documentation workflow that is asynchronous to the code change workflow.

Don Benson
Thursday, February 5, 2004

I agree - we need to be able to link bugs together.

Patrick Halstead
Tuesday, March 9, 2004

*  Recent Topics

*  Fog Creek Home