[techtalk] Bug tracking/Change orders

[jennyw at griffon.personic.com]

From: "Telsa Gwynne" <hobbit at aloss.ukuu.org.uk>
> I think it depends how it's used. Certainly the Mozilla folks use it
> for both. From http://bugzilla.mozilla.org/

That's probably accurate ... For me, a bug and an enhancement are two
completely different things, and should go through two completely different
processes.  Enhancements might be submitted as a bug, but they should be
re-written as engineering change orders if they're accepted, and then go
through that process.  These two are really simplified, but give you an idea
of what I'm looking for:

Example bug life-cycle:
1. Submitted as a bug.
2. QA confirms that the bug exists, and refers to sections of the spec. or
ECO(s) as needed.
3. Bug committee reviews and decides bug is to be fixed, and assigns it to a
resource.
4. Engineer fixes bug.
5. QA engineer verifies the bug fix.

Other states include deferred and feature.  Feature refers to a bug written
on something that's behaving the way it should. If the bug is requesting
functionality that doesn't exist, it should become an enhancement request.

Example enhancement request life-cycle:

1. Submitted to product team. Status: Submitted.
2. Approved as a feature enhancement.
3. Re-written as an engineering change request. ECR includes a description
of the functionality (ECRs are amendments to the spec.), what ECOs or
sections of the spec. this ECR supercedes, and references.  And category of
change. And lots of other things, too.
4. Submitted for approval.
5. Approved as an engineering change order, assigned an ECO number.

Obviously, neither of these examples is comprehensive, but I think you can
see how the enhancement request process differs from the defect tracking
process. If I can't find any request tracking systems, I'll probably write a
simple one for our own use.

Thanks!

Jen




************
techtalk at linuxchix.org   http://www.linuxchix.org