Welcome to the FogBugz Knowledge Exchange

Question

9

1

We are a web studio.

We have HTML coders, flash devs, designers and server developers.

As it stated in the docs, we use areas for different kind of tasks (flash dev will never do server coding)

It's very natural for us to have Code, Flash, Design, HTML Areas. We use areas so flash developers can easely see flash tasks in all projects.

We also have many short lived projects. It's pretty irritating to create 4 areas for each of the new projects. And also be unable to filter normally by area (only via search filtering).

So here is the logical request: we need sitewide Areas!

edited May 16 2011 at 19:00

Rich Armstrong♦♦
14.1k●15●34

asked Dec 30 2009 at 7:19

Alexander Gornik
1,217●4●11

Ryan CTO · Answer 1 · 2010-10-14 09:44:13Z UTC

Dear FogBugz,

We too have many clients and many projects per client, all related to Web site or mobile app (a la iPhone/BlackBerry/etc.) development, and we see areas as being the main way to manage historical data related to profitability, efficiency, and long-term resource planning.

For instance, if over time I learn that 38% of a project's time is spent on the "QA" area or the "Design" area or the "Front-end Development" area (etc.), I can make smarter hiring/budgeting decisions for the long term.

Additionally, and again, this goes back to budgeting, we even have some clients that require we bill them by discipline, because we have a rate card with different hourly costs per discipline. While I could simply say that a CakePHP engineer costs $XX per hour, if that engineer is doing project management instead of CakePHP, their hourly rate will change. Again, with better use of Areas, this would be simple to track.

All that said, I would LOVE LOVE LOVE a way to have a "project template," which relates to a "global area list," because if we had project templates, or heck, even the ability to just clone a project's settings, we'd no longer have to go through the tedious task of entering in the areas each time. Although, even as I write this, I actually will go back to wanting global areas too, just for reporting purposes on an aggregate scale. But again, that's a nice to have. Project templates/project cloning is the key I think.

-Ryan

Tom · Answer 2 · 2011-05-08 10:20:38Z UTC

1

Agree. Also, for our company, global areas would make more sense.

answered May 8 2011 at 10:20

Tom
393●2●6

Rich Armstrong · Answer 3 · 2009-12-30 21:58:50Z UTC

0

It's probably not feasible to change the basic data structure of FogBugz, along with all the design challenges that would accompany such a bold move. I think we'd do better to just address the complaints.

It is possible to create a quick little API script to create the new project and its underlying areas with just a click. I'll whip up some PHP code if there's interest.

I'm not sure if you're talking about adding a search to a filter or just actual searching, but it doesn't cost anything to add a search to a filter and the outcome is the same as filtering by area.

answered Dec 30 2009 at 21:58

Rich Armstrong♦♦
14.1k●15●34

	Why it's a bold move? It's same change as with global milestones, but much easer, because it does not have side effects on EBS, workflow or any other thing (perhaps, except the "primary contact" feature, but it should not be hard to add some lines of addtitional code to a method that calculates it) . It's just simple case categorization field. We just have "All projects: Area" and standard per-project areas. And a small change to filter UI. Should be not hard to implement. – Alexander Gornik Dec 31 2009 at 5:46
	Look at it from you own logic: you tell us: areas represent work wich is done be dirrerent kind of people. This is essentially a company wide cathegory, not a project-wide. – Alexander Gornik Dec 31 2009 at 6:50
	Sorry, but I'm just not seeing the clear use case here. There are workarounds for each of the difficulties you enumerate. Are there other compelling uses that would make this worthwhile? Yes, just adding the ability to have a global area is probably not all that hard. It's making that change make sense to the user that represents more work than the feature is probably worth. Where are these global areas administered? How do you select a global area when you haven't selected a project. It's not the technical challenges, but the design challenges. It's not the code. It's the UX. – FogBugz FAQ♦ Dec 31 2009 at 18:04

Paul · Answer 4 · 2011-03-22 14:09:31Z UTC

0

We will have many, many projects, we need a global areas list as the functional areas are consistent across all projects. And when they change, we need to change them globally.

answered Mar 22 2011 at 14:09

Paul
1

Tim · Answer 5 · 2011-04-07 02:29:04Z UTC

0

I also agree, global areas are very important. We would definately be interested in an API to create a new project with global areas.

answered Apr 7 2011 at 2:29

Tim
1

Feature request: A global Area list

5 Answers