Bug System: fields - assignee
david.holmes at oracle.com
Mon Jan 30 17:05:53 PST 2012
I'm ready to jump in on this too but will wait until Iris requests
feedback on "Fields". ;-)
On 31/01/2012 5:09 AM, Peter Jensen wrote:
> On 01/30/12 10:49, Iris Clark wrote:
>> 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.
> I'm afraid I only see my concerns confirmed:-)
> You have Assignee set to null when a bug is Closed, and either null or a
> QA engineer in the Fixed state.
> I don't think we should get of the hook that easily. Yes, I know you can
> look at the history, but that's just
> not very convenient.
>> 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.
>> -----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
>> -- Peter
More information about the discuss