My personal preference it to use two workitems for this: an "issue"
which is owned by the submitter, and a "task" which is owned by a
developer. The issue captures the perspective of the submitter, while
the task captures the perspective of the developer. In particular, this
allows a clearer model for when several users submit related issues that
are addressed by a single task. (See work item 21879).

For the particular case below, it allows you to distinguish between
developer verification (verifying the fix works in the integrated build)
from user acceptance (verifying that it solves the particular user
issue). In the multi-issue case, it also allows you to track which of
the issue submitters have verified that their particular flavor of the
issue is addressed).

Cheers,
Geoff

On 5/18/2010 9:38 AM, ppieczul wrote:

I'd like to have automatically owner transitioned to work item
submitter when state is changed to resolved. Otherwise it is
impossible to manage work item verification (moving to
verified/closed) state.

As indicated in my response, I was just indicating a personal preference, not a statement about what the tool can or cannot do. If you want to automatically change owner upon state change, you could write a process hook to do so.

As for "complicating the lifecycle and increasing bureaucracy", I believe the opposite is true. In particular, each of the individual work items have a much simpler lifecycle than the "composite work item", because in a composite work item, the lifecycle needs to contain states indicating "what role currently owns this work item" (e.g. "in-development", "being-documented", "being-validated"). Similarly bureaucracy is decreased because each individual can do whatever they want to their work item ... whereas once a composite work item is moved to "in-development", the original submitter is often prevented from modifying it ... for example, if they decide they no longer need it, they aren't allowed to mark it as "no longer needed" ... since the developer now "owns" that submitted work item.

Cheers,
Geoff

I think that it complicates the lifecycle and increases bureaucracy. In most cases we will have 2 records instead of one.
From this answer I assume there is no technical way to automatically change owner upon state change, is that right?
Thank you