Rename Version to Found In Version, then add the following fields: Fixed In Version Found In Design Stage Fixed In Design Stage These fields are recommended by Construx as part of their Software Estimation processes to help estimators track costs associated with bugs and improve estimates over-all moving forward. These points of reference provide a data point for estimators to use in predicting how long it will take to produce similar code, to track how many bugs are anticipated at each stage, and what kind of cost will be associated with fixing those bugs along the way. Example: Project J had 5 bugs each at the concept, pre-planning, design, architecture, construction, and pre-release testing stages. Project K had similar numbers (totaling about 30 bugs by release time). The estimator knows to expect about 30 bugs on the next similar project. If they get to the pre-release stage and they've only found 15 bugs, it encourages the project manager to go back and ask the question - did we not inject 50% of the bugs we did the last two times we wrote this kind of code, or did we just miss the bugs? There's a lot more that can be done with these fields, but having them available makes a lot of sense.

For all intents and purposes, these are just extra single-select fields. After we have custom fields in place, we can discuss if there are any extra fields we'd like to ship by default. But as everybody has different needs at their company (and trust me, I've added many custom fields to many organization's Bugzillas, and they have very different needs), I'd prefer to allow people to make Bugzilla fit their process, rather than making their process fit Bugzilla. (And that's the whole point of Custom Fields.) *** This bug has been marked as a duplicate of 287326 ***

Even though this may be seen as a duplicate of the custom fields bug at this point, I'd like to work this separately since, at this point, it seems that for the corporate environment, these fields should be a part of the base installation rather than asking others to add them as custom fields. I think it might be more appropriate to mark this as a duplicate after custom fields are implemented and this can go away, otherwise, I'd really like to make sure this is worked on and I'm willing to be the one to do it. Notes to self... DB Changes: Add new table: version_tracking_map ( bug_id mediumint(9) not null, version_id mediumint(9) not null, version_type enum("FoundIn", "FixedIn", "DesignInjected", "DesignFixed"), primary key (bug_id, version_id, version_type) }

version_tracking_map ( bug_id mediumint(9) not null, version_id mediumint(9) not null, version_type enum("FoundIn", "FixedIn", "DesignInjected", "DesignFixed"), primary key (bug_id, version_id, version_type) } needs to be changed to... version_tracking_map ( bug_id mediumint(9) not null, version_id mediumint(9) not null, version_type_id tinyint not null, primary key (bug_id, version_id, version_type) } version_types { id tinyint not null default 0 auto_increment primary key, type_name varchar(255) not null, }

I am unable to work this bug at this time due to other priorities. Reassigning to default assignee.

(In reply to comment #2) > the corporate environment, these fields should be a part of the base > installation rather than asking others to add them as custom fields. No, this won't be part of the default installation. > I think it might be more appropriate to mark this as a duplicate after custom > fields are implemented and this can go away We now have single-select and multi-select fields. That's all you need to implement this. Re-marking this bug as a duplicate.