Feature request: project groups
Following on from other threads in the discussion regarding area groupings, I feel we really need project groupings. Here's my rationale:
My company has 2 sides to it: development (my responsibility) and operations (my colleague). We want to use FB to handle both sorts of cases.
Our top level grouping is customer: we do different things for that customer e.g. operational support, development of this bit of software, building that database etc.
From the development perspective, I think each releasable component is an FB project: because version is tied to project. Therefore when I’m building a database application, I actually create 2 FB projects: one for the app and one for the database – since they are separately releasable components. This becomes more relevant when there are multiple applications hanging off the same DB.
However, both the application and the DB are obviously for the same customer, so it would be very helpful to group them under customer (or project group – whatever).
Currently – because the project list is flat – I end up with a long list of projects, the only way to group them being some sort of naming prefix.
On the operations side, we tend to create a project per customer, then an area called “Operations” to track support cases until they can be assigned to something more specific.
Given that our prime focus is customer, I’d really like to report on the status of customer cases, not the (lower level) project specific ones.
What I really need is a recursive project grouping method so I can decide my own hierarchy of customer > project group > component etc.
It seems to me that FB has come from a product development background where the focus is product (project) rather than individual customer. That’s fine, but adding project groups would make it more flexible (IMHO).
Does anyone agree? Or have I got a bad case of componentitis?
Tuesday, July 22, 2003
"It seems to me that FB has come from a product development background where the focus is product (project) rather than individual customer."
This seems right to me. I have a long list of projects, too. I don't know if another tree level would help - it might.
If someone asks you for a report that stems from an ad-hoc database query, it's nice to have that in FogBugz, in case you are asked for something similar later. This particular case is not tied to a development project. My pet peeve is that the 'Fix For' date must be based on a release. This may be appropriate for bugs & features, but for inquiries it would be nice to put in any date.
Tuesday, July 22, 2003
Fog Creek Home