Purpose of Resolver Field

[ZackJones]

Hi,

I have read the one line description of the resolver field in the release notes (It seems to be missing from the help file, BTW), but I don't really understand how it works.

For example:

If we set resolver to (none) and set the status as completed why would it show up as an unresolved item on the summary screen?

How does one clear items from the "My Unresolved" list?

Is there any way to ignore this field? I would appreciate it if someone could explain how to properly use this field when processing items.

Thanks in advance!

[bfinney]

The resolver field is there to assign items for verification after a developer has marked them as completed - essentially it's used to specify a QA person (or a fellow developer) that is assigned to test the bug and decide that it's really really fixed.

Resolvers can be assigned particular item categories just like developers can (via the assignee field). If a category has no resolver associated with it, bugs placed into that category make the reporter the resolver. The weakness here is that often the reporter is also the assignee and you usually don't want the guy who fixed the bug to verify it.

To get items out of your unresolved list, either mark 'em verified, or reassign them to somebody in your QA department.

Let me know if you need further clarification and I'll give a concrete example or two about how we use it in our dev process.

[mskrobul]

It looks like we need to update html documentation for Dragnet on our website.

The help that gets installed with Dragnet does document the resolver field.

The resolver is basically the person who is in charge of verifying the Dragnet item. We have had many requests for a QA assignee field and the resolver field addresses this issue. This field is there so QA people (and others) can easily see and query on items are assigned to them for verifying.

On an upgrade from a previous version all items have the resolver set to the person who logged the item.

The simplest way to change the resolver for many items is to do a batch edit and change the resolver to (none) or someone else.

[ZackJones]

To get items out of your unresolved list, either mark 'em verified, or reassign them to somebody in your QA department.

Hmm, no wonder I couldn't figure out the resolver stuff. To me verified means that the bug was varified as being found not that QA has verified that the fix was made properly.

Perhaps it would be a good idea to list the status codes and give us a brief explanation of each code and how you would recommend they be used.

Let me know if you need further clarification and I'll give a concrete example or two about how we use it in our dev process.

Sure, I would like to hear how you guys are using it.

BTW, I like your signature!

[bfinney]

Hmm, no wonder I couldn't figure out the resolver stuff. To me verified means that the bug was verified as being found not that QA has verified that the fix was made properly.

Perhaps it would be a good idea to list the status codes and give us a brief explanation of each code and how you would recommend they be used.

Wilco. This should be in the documentation, so I'll log a task for it as well.

The "prefabricated" statuses can all be renamed, but two of them have "meaning" hardwired into dragnet. I'll explain what that means when I come to them. There are other perfectly acceptable and logical use scenarios for the statuses, but we tend to use them as follows:

Open - All items begin life in the "open" state. There's really not much to be said for this one, except that something still has to be done to the item before it goes away. This status is hardwired into stuff like "My Open". If it's renamed "bargblaster", clicking on "My Open" will show bugs that have status bargblaster.

Unconfirmed - A (potential) bug has been reported by a customer and logged in Dragnet. When the developer looks into it, he can't reproduce it. At this point, he'll move the status to unconfirmed and change the assignee to a tester. The tester will spend more time trying to reproduce and isolate the bug. If it's successfully reproduced, the bug goes back to open (with comments detailing the steps necessary to make it happen). If it can't be reproduced, it will be marked invalid.

Invalid - A bug that has been logged, but can't be reproduced. Either a customer report was wrong, an internal tester was wrong, or the bug has become invalid over time as the project matures (e.g. the bug has been sitting "open" for so long that the feature with the bug has been removed or substantially modified).

Duplicate - Somebody didn't query the bug database before logging a new issue! Tsk tsk!

Disregard - This one is seldom, if ever, used. Since we QA Dragnet itself using Dragnet, once in a while we foul up and add fake bugs to the live server instead of a test box. These don't fit nicely into any other category, so they go here. It can also be used as a flag for items that can be deleted for reasons of your own choosing.

Completed - A developer has checked changes into the tree that are meant to address the item. At this point, the bug is no longer the programmer's problem, and becomes the problem of a tester (who may be a fellow developer but is usually a QA thug). The tester then does some regression testing and either marks the bug "verified", burying it forever, or resets it to "open" with comments on what failed and it returns to the developer. This one is also hardwired to "My Open", but the "Completed" tab of it.

Verified - Items that have passed through testing, and the tester is confident that the item has been addressed and nothing else has been broken in the process.

Sure, I would like to hear how you guys are using it.

For a concrete example, let's take the bug I just logged about documenting the status fields. When logging it, I put in the category "Help" and did not explicitly give it an assignee. The dev owner of the Help category is Dixie, so the bug was automatically assigned to her. Likewise, I didn't explicitly set a resolver, but we don't have a QA owner specified for this category, so the resolver was set to me (since I logged it).

In a few days or weeks, or whenever, Dixie will look at the item and will either write something up or pass it on to somebody else. Let's say that she's not familiar enough with the status fields and reassigns it to me, since I've already written the bit above which can be formalized into the basis for a help entry. At this point, I'll address the issue, modifying some html files in our Vault database and set the status to completed. Since I ended up as the dev assignee, I should not be the person verifying the changes, so I'd change the resolver to somebody else, say Tonya.

A couple of days later, after we run a new test build, Tonya will check the help file to make sure my changes are in there and that nothing is wrong or misspelled. If she's happy with it, she'll mark it "verified" and it will never trouble us again.

BTW, I like your signature!

Thanks! Let me know if I need to clarify any of that.

[ZackJones]

Brody,

Thanks for the explanation, I really appreciate it.