Bug System: fields - assignee

[Peter Jensen]

According to the timeline, it's time to discuss fields.

The current "definition" for the Assignee field is:

    *Note:* /The value of "Assignee" should be "null" unless the
    bug/feature request is actively being worked on or there are plans
    to do so in the immediate future.
    /

I don't think a single field is sufficient to track responsibility, and 
I don't think assignment should be too closely associated with the 
scheduling of work.

There are at least two roles to be assigned:
- Responsible Developer: responsible for detailed technical evaluation, 
and for developing a solution.
- Responsible SQE: responsible for validation and closed-loop analysis.

These fields should remain null until, from a resource management 
perspective, it makes sense to assign (or voluntarily assume) 
responsibility. When exactly that is may vary. Once made, assignment 
should indicate future, present and past (i.e. continued) 
responsibility. For instance, once a bug has been fixed, it may still 
fail validation, or SQE may have question about development testing and 
testability. Thus, development's responsibility is not over when the bug 
fix is integrated.

When a single field is used, you may try to reassign an issue when it 
moves back and forth between development and SQE. This is very fragile. 
Too often people forget, or simply do not know to whom they are to 
assign an issue (or to whom to address a simple question). Then, because 
an engineer is expecting the bug to be assigned, and doesn't pay 
attention to the status change, a bug may get stale. This slows down the 
process, and it creates a lot of overhead for development and sqe 
managers to push bugs along.

If you do not reassign the issue, then the SQE function needs to use an 
external mechanism for tracking responsibility. It's pretty sad to have 
to manually maintain wiki pages with bug listings, or develop complex 
boundary systems to detect and warn about inconsistent assignments.

-- Peter