A forum for technical support discussion related to Fogbugz.
This question especially relates to EBS and how it views projects and milestones within a project.
I've defined / named the FB project for our primary application "Core Application Program", using the word "program" to denote that it touches a number of areas and that work on it is continuous, rolling from development for one release right into the next. As such, I'll have milestones in the project like "4.0 Dev Iteration 1", "4.0 QA Iteration 1", "4.0 Code Complete", "4.0 QA Final Verification", "4.1 Dev Iteration 1", etc. all at the same time. Note the milestones for multiple releases (4.0 and 4.1) within the same FB project.
This seems to present a challenge to FB in that if a 4.1 milestone completion date is before some of the 4.0 milestone completion dates, the EBS report shows that in its slider of milestones. If I'm wanting to look at 4.0 milestones in the EBS report, I don't want the 4.1 milestone in the middle of that list.
One approach would be to have each release be its own FB project. The challenge with that is that most aspects of the "program" carry on from release to release. So, for example, I'd have to re-create all the project "Areas" every time I create a new FB project to represent a specific release.
Another issue with each release being a different FB project is that there are some implied expectations when creating a new case if it gets assigned to a particular project. It's easy enough to move them, but the somewhat large number of users who create cases here generally know to assign a new case to our "program" project; and I can adjust milestones. If an FB project is really a release, then it's not an "Undecided" milestone that a new case might get assigned to, it's an "Undecided" project (i.e. release). Obviously, I could create a project named "Undecided", but that's not particularly intuitive when creating a new case.
Thus the question asked in the subject. What is the canonical meaning / expectation around an FB project? If it's intended to correspond to a release, then FB really needs a "project clone" capability to make it easy to apply the settings of one project to another when they're concerned with the same "program". If an FB project is really more like a "program", then FB needs a first-class concept of a "release" in which to organize milestones and which can be distinctly viewed in the EBS reports.
Thursday, October 15, 2009
Indeed, you are using FogBugz projects in the intended manner - that is how we use projects and releases here. For instance, FogBugz is a project, and we have multiple milestones leading up to each release, and sometimes there are multiple releases (a service release and a major release with lots of changes) with milestones that interleave in time.
I understand what you're saying with the idea of first-class releases for aggregating milestones, and that is one idea we are considering for future versions of FogBugz (and EBS). We are somewhat reluctant to add a new concept unless we are sure it is necessary, but you make a good and well-put case for it.
In contrast, with how Fog Creek's teams work, we are not in our own use of FogBugz bothered by the fact that these releases show up on the same slider on the options page; the names of the milestones separate them, and unless the same people are working on different releases, they will not interfere with one another schedule-wise because the EBS algorithm works based on each person. So it's interesting for us to know how the milestones interleave chronologically, and it doesn't hurt the modeling.
In summary, I think you're using it as effectively as it can be used in its current iteration, and I have linked this discussion topic to our case for dealing with these kinds of problems in future versions: it's a good take. I can't offer you a workaround for separating these milestones visually right now, but I agree it's a good idea and we're working on a good solution to this problem that doesn't introduce too much complexity.
If there's anything else you want to tell us about your use case, please do - it will help inform how we approach this; of course, anyone else reading this thread, that goes for you, too.
I appreciate the prompt and detailed response. It's good to know that Fog Creek is using it much the same way I am.
As you pointed out, the output from EBS isn't impacted by the interleaved milestones. But it's a little ambiguous if you want to be focusing on a single release.
In the short term, I think the biggest problem with the current implementation is that I can't easily pull up all cases that are part of the same "release". This is something I need to do somewhat regularly, and there's no great support for it right now. I'm experimenting with a custom field named "Target Release", but I have to manage everything about that manually. And, since the gridview that results from a search isn't quite a first class gridview (filtering options exposed, sorting behaving consistently, etc.), it's not a very good solution.
Thursday, October 15, 2009
Got it. Yes, I can see that not being able to filter on release could be a problem, and I hope the custom field mitigates this, but I can see that it wouldn't be great. You should get first-class filtering and grid columns from your custom field, though?
I suppose one could go a little bit further and write a plugin that would automatically manage a 'release' field based on the beginning substring of the milestone, but with the search limitations plugins have right now, it wouldn't be perfect.
This topic is archived. No further replies will be accepted.Other recent topics