Re: [platform-ui-dev] Platform UI triage process

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

Another option is to ask the webmaster
for a small window of time to disable bugzilla notifications and do a mass
update. We did this when Equinox migrated into the RT project. I think
as long as the bug only changes owner and doesn't change state (RESOLVED/CLOSED),
it's reasonable to do this with bugzilla notification disabled. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=237868
for details.

John


Boris wrote on 02/24/2009 12:04:49 PM:

> Sounds like we have a consensus. (Yay! Next topic: formatter
> options... just kidding :-)
> 
> I have filed https://bugs.eclipse.org/bugs/show_bug.cgi?id=265985
to
> get the new bugzilla account created.
> 
> On today's call, we said that moving bugs from existing owners to
> platform-ui-triaged should happen over time rather than as one fell
> swoop. I will add a button to the Greasemonkey script for the purpose
> of moving a bug to platform-ui-triaged. The script will add a one-line
> comment to the bug, with a pointer to a wiki page explaining the
> changes. Based on this one-line comment, people should be able to
> filter out unwanted bug emails.
> 
> Boris
> 
> 2009/2/24 John Arthorne <John_Arthorne@xxxxxxxxxx>:
> >
> > +1, I think this proposal makes sense and is worth a shot. In
Platform
> > Runtime/Resources we use the ASSIGNED to inbox technique, but
I agree with
> > the sheer volume of bugzilla traffic on UI that a dummy triaged
owner makes
> > sense. That allows people to watch only new bugs, or all triaged
bugs if
> > they dare. Component owners will need to double-check their bugzilla
> > settings to ensure they are notified on bug changes when they
are the QA
> > contact.
> >
> > John
> >
> >
> >
> > Boris Bokowski/Ottawa/IBM@IBMCA
> > Sent by: platform-ui-dev-bounces@xxxxxxxxxxx
> >
> > 02/23/2009 10:15 PM
> >
> > Please respond to
> > "Eclipse Platform UI component developers list."
> >  <platform-ui-dev@xxxxxxxxxxx>
> > To
> > platform-ui-dev@xxxxxxxxxxx
> > cc
> > Kevin McGuire/Ottawa/IBM@IBMCA
> > Subject
> > [platform-ui-dev] Platform UI triage process
> >
> >
> >
> >
> > Apologies for the long email, but we have put this off for too
long and it
> > is high time to fix how we triage bugs.
> >
> > The "busy committer" summary is: We would like to move
bugs that nobody is
> > planning to work on to a group account ("platform-ui-triaged@xxxxxxxxxxx").
> > To ensure that each bug has someone who is responsible for "watching"
it, we
> > would like to use the "QA Contact" field which is currently
unused.
> >
> > === Problem ===
> >
> > In the current Platform UI bug triaging process, bugs are assigned
to
> > component owners. The primary role of the component owner is
to watch over
> > the activity in those bugs, ensuring that no critical bugs are
left
> > unnoticed and that comments are addressed. Second to that is
to attempt to
> > fix some of the bugs. This assigning of bugs is effected through
the
> > changing of the "owner" field of the bug.
> >
> > However, this process incorrectly provides the impression that
all bugs are
> > being worked on because they have owners. This often isn't the
case, since
> > the reality is that there are more bugs per component owner than
the owner
> > will ever have time to fix. It makes it look like "everything
is being taken
> > care of".
> >
> > Additional tricks like adding the "helpwanted" keyword
or changing the
> > priority are then required, but these aren't always or consistently
applied,
> > so become an unreliable reflection of the need/desire for community
> > participation.
> >
> > Finally, while being the owner of a component area is a fairly
"big" job,
> > watching over bugs and helping with their further triaging isn't,
and we
> > recognize that there are opportunities for the community to participate
at a
> > lower granularity than component owner.
> >
> > === Proposal ===
> >
> > We believe that it would be clearer, and more helpful to the
community, if
> > the assigning of a bug meant what it should mean, which is that
the person
> > "owns" the outcome of the bug and is going to fix it.
When and only when a
> > committer decides they are going to fix a bug should it's owner
field be set
> > to them. Bugs without owners are, by definition then, bugs not
being worked
> > on.
> >
> > To manage the "watching" of bugs task, we propose instead
to use the QA
> > Contact field, which presently is unused. Where today we'd assign
the bug to
> > the component owner, we'd instead make them the QA Contact. Triaged
bugs
> > would initially be assigned to a group user like
> > platform-ui-triaged@xxxxxxxxxxx. The QA Contact could be the
component
> > owner, or could be any other platform UI committer who is willing
to lend a
> > hand. They would keep up on the comment thread and ensure that
critical bugs
> > are brought to the attention of someone who can fix it.
> >
> > === Advantages ===
> >
> > We believe there are several advantages to this small change:
> >
> > 1) Clarity of status:
> > It provides a more truthful reflection of bug activity. It now
becomes
> > easier to tell which bugs are actually being worked on, since
they are the
> > ones with owners.
> >
> > 2) Identification of opportunity:
> > It provides an easier way for the community to identify places
where they
> > can get involved. Bugs without an owner are defacto "help
wanted" bugs.
> > Additionally, committers who want to help but can't commit to
owning a
> > component can become QA Contacts for some set of bugs.
> >
> > 3) Effectiveness:
> > Finally, we believe this will help component owners focus on
fixing the most
> > important bugs, which after all, is the greatest benefit to the
community.
> >
> > ===The Process in Detail===
> >
> > This is how the bug process would look like as a result:
> >
> > Incoming bugs are triaged by a full-time committer on a rotating
basis. The
> > goal is to have an empty inbox, no bug should stay in the inbox
for longer
> > than a few days.
> >
> > Incoming bugs: To do triage, we use the Greasemonkey script (with
buttons
> > for all component areas). Clicking on a button will
> > - Prefix the bug description with [ComponentArea].
> > - Set the "QA contact" field to the person responsible
for watching bugs in
> > the identified component.
> > - Assign the bug to platform-ui-triaged@xxxxxxxxxxx (separate
account from
> > platform-ui-inbox).
> > As part of the triage, we need to make sure that the bug contains
enough
> > information, and that the "severity" is set to a value
that makes sense.
> > Enhancement request need to be marked as such, and the same is
true for
> > blocker/critical bugs.
> >
> > When a committer is assigned as the QA contact for a bug:
> > - Double-check that there is enough information in the bug, and
that the
> > severity is accurate.
> > - If it is a blocker or critical bug (e.g. loss of data, crash),
it needs to
> > be fixed as soon as possible. If you are not able to fix the
bug yourself,
> > assign it to someone else who is.
> > - If it is a regression, it needs to be fixed during the current
development
> > cycle, or potentially in a maintenance stream as well. Schedule
the bug
> > accordingly, or assign it to someone else who has time to work
on it.
> > - For all other bugs, try to stay "on top" of the bugs
you are watching in
> > the sense that you can produce a rough prioritization of the
bugs in a
> > component area. Something like: "if we had the time to fix
these ten bugs,
> > our code would be in much better shape".
> >
> > When a new comment is made on a bug you are watching:
> > - Respond on the bug if necessary.
> > - Adjust prioritization if necessary.
> >
> > Questions and comments are of course welcome. Unless we find
a flaw in the
> > proposed process, or come up with a better idea, we should be
able to use
> > the new process next week. We suggest that we start using this
new process
> > on all incoming bugs, and move over existing bugs over time.
For existing
> > bugs, we should start with those that are currently "owned"
by former
> > members of the team (Kim, Tod, Karice...). As part of the moving
over, we
> > should classify bugs correctly as actual bugs vs. enhancement
requests.
> >
> > Boris and Kevin
> >
> > P.S. A copy of the main part of this email is at
> > http://wiki.eclipse.org/Platform_UI/Bug_Triage - to be cleaned
up and
> > enriched with links etc. when we have
> > consensus._______________________________________________
> > platform-ui-dev mailing list
> > platform-ui-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
> >
> >
> > _______________________________________________
> > platform-ui-dev mailing list
> > platform-ui-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
> >
> >
> _______________________________________________
> platform-ui-dev mailing list
> platform-ui-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/platform-ui-dev