[eclipse-dev] Re: Bugzilla "inbox" accounts?

["Kevin Haaland" <Kevin_Haaland@xxxxxxx>]

How eclipse handles defect reports was identified as an area that needs
improvement for 2.1 as component leads
were spending a significant amount of time doing first line support..The
inbox accounts are the first visible changes
to how some teams are going to handle their defects.

In bugzilla the default owner for the a component is changing to be a mail
alias <product>-<component>-inbox@xxxxxxxxxxx.
For example, the core componet in bugzilla is owned by
platform-core-inbox@xxxxxxxxxxx. This will not only allow teams to
more easily change who is doing the initial defect triage but will also
make it easier to know which defects are actively
being worked on.

Here is an outline of the PR triage process that the UI component has been
using:


To Triage A Defect
==================

      A new user id will be created to represent the "Inbox" for a
component.

            New defects will, by default be assigned <Product>-<Component>
-Inbox@xxxxxxxxxxx



      We identify a (possibly rotating) subset of the team to be
responsible for PR triage who are responsible
      for.

            1. Getting a valid defect report. This means:

                  Confirm that the problem exists.
                  The steps to recreate must be clear.

            2. Attempt to remove duplicates

            3. Do a first pass of prioritization

                  Is it a defect or an enhancement request?
                  Is it critial?

            4. Forward valid defects onto a commiter.


      For defects that are not actively being worked on the will be
assigned to the "inbox".

PR States
=========


      Eclipse commiters will set the priority.

            P1 => Critical "stop ship" defect.

            P2 => Major error. Intent is to fix before shipping but we will
not delay the release if they are not all done.

            P3 =>  Nice to have.

            P4+ => Low priority.



      Defects, when they are created; are in the "New" state. When assigned
to the <Product>-<Component>-Inbox
      nobody has looked at them. Defects should not stay in the new state.


      A defect that is owned by the inbox user may:

            -> be resolved (eg. duplicate, invalid, worksforme)

            -> assigned to an individual if it requires immediate
attention.

            -> accepted by the inbox (if they are valid requests that we
are not going to work on now)
                  => Must be prioritized.


      A defect that is assigned to a person.

            => Will appear as a new defect.

            => The expectation is that these defects will be accepted.

            => Under exceptional circumstances they may bounce around.
(Need to minimize this).

                  This includes reassigning to inbox user for further
triage.