Higer level Dragnet process documentation?

cdenend · Post by **cdenend** » Thu Jun 16, 2005 4:15 pm

Ultimately, it seems like a bugbase is an expression of a bug filing and fixing policy. I am wondering if there are any policy documents which describe best practices for working with Dragnet.

For example, when a bug gets submitted, it usually needs to be reproduced by QA. Dragnet seems to immediately place added items in the Open state, which doesn't seem quite correct. Once a bug has been reproduced, it then most likely needs to go into a review process, where bugs are assigned, given priority, and assigned a milestone. Dragnet appears to allow the submitter to set all of this information, which again does not seem quite right.

I get the feeling that I am not understanding how Dragnet was intended to be used.

Any thoughts on this, and or documentation references would be greatly appreciated.

Thanks
-- Chris

lbauer · Post by **lbauer** » Thu Jun 16, 2005 9:49 pm

Ultimately, it seems like a bugbase is an expression of a bug filing and fixing policy.

You're right, though Dragnet at this point in its development is more about filing and less about policy.

Currently Dragnet workflow reflects our own -- anyone can log a bug and assign a priority and milestone. The project manager reviews all the bugs logged and makes any changes in status, priority, milestone, etc. they deem necessary.

When it's first logged, a bug is "Open" and assigned to someone; usually the developer for that category. Generally the bug has already been reproduced by one of our staff when we log it. This would be different if your customers logged bugs directly into Dragnet -- I can see where you'd want QA or Tech Support to check it out first.

Once a developer has checked in the code to fix the bug, it becomes Completed. They think they're done; QA tests to make sure. QA re-opens the bug if there's still a problem or marks the bug Verified if it's been fixed.

We have other categories like Invalid, Disregard, etc. for bugs which have proven not to be bugs.

It's a fairly informal process, but does a good job of tracking all the work users need to do and the deadlines by which they need to do it.

We have had requests to add more workflow and policy enforcement to Dragnet. We're looking at ways to do this while keeping Dragnet flexible enough to meet the diverse workflow needs of our users.

We'd be interested to what type of workflow/policy you and other users would like to be able to set in Dragnet.

cdenend · Post by **cdenend** » Thu Jun 23, 2005 11:36 am

lbauer wrote:It's a fairly informal process, but does a good job of tracking all the work users need to do and the deadlines by which they need to do it.

Thank you for the insight into how Dragnet is intended to be used. This helps quite a bit.

I think the ad-hoc workflow you have defined will work, but it seems like there a few fields that would help with overall tracking.

First, a field indicating reproducibility would be good. A bug may only happen once, but you still want to log it, so you have a record if it happens again. This helps with setting priority as well.

Related to this, it would be nice to have a field for frequency. Knowing how many users might hit this bug, again helps with setting priority.

I also think that a field giving the bug an owner would be helpful. Often, a person from outside engineering will file a bug, and I will want to assign the bug to someone in QA to own and verify. The reporter field could work for this, but it doesn't seem to be editable.

I think it is also useful to have a fix build field. This helps with verification, so QA knows what build to test for the fix.

Finally, as I mentioned, I am used to having bugs first enter a "new" state, where they can either be triaged, or reviewed and assigned. I find that as one approaches major milestones, it is good to keep the "noise" for the developers to a minimum, and having an initial review before assignment helps with this process. To work around this, it seems like I can create a "review" user, and ask that all new bugs be assigned to this user.

All in all, I could probably use the custom fields for some of this information, or I could just ask that it be added to the details. Is there anyway to set default text for the details field, to prompt for this info?

Thanks
-- Chris

lbauer · Post by **lbauer** » Thu Jun 23, 2005 3:51 pm

Thanks for the suggestions.

I also think that a field giving the bug an owner would be helpful. Often, a person from outside engineering will file a bug, and I will want to assign the bug to someone in QA to own and verify. The reporter field could work for this, but it doesn't seem to be editable.

We do plan to add a separate Resolver field (equivalent to QA assignee/Owner, etc) for Dragnet 1.0.4, due out later this year.

You can use the custom fields for two of your other needs, though there's no ability to pre-fill or prompt at this time.

I'll log fields reproducibilty, fixbuild, frequency and status new as feature requests.