Bug System: fields - assignee

[Iris Clark]

Hi, Peter.

I haven't filled out the Assignee field section yet.  The "Note" was added as part of my updates to the Developer Workflow which references the Assignee field (and the potential need for other fields you mention) in multiple places.  Until I can get the Field section filled in, I recommend you read the "Owner" sections for each of the status in the Developer Workflow.  Searching for "Assignee" in the entire document would be a more thorough way to get the complete picture.  Most of your concerns are addressed there.

The other "Note" fields I the current DRAFT are there for similar reasons.  I needed a way to annotate things that were specifically referenced in the Developer Workflow, but didn't want to write that portion at that moment.

Thanks,
iris

-----Original Message-----
From: Peter Jensen 
Sent: Monday, January 30, 2012 10:35 AM
To: discuss at openjdk.java.net
Subject: Bug System: fields - assignee


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