ubuntu-bugcontrol team mailing list archive

[Brian Murray <brian@xxxxxxxxxx>]

On Tue, Oct 06, 2009 at 12:24:18PM -0500, C de-Avillez wrote:
> On Tue, 2009-10-06 at 01:18 -0500, Marc Randolph wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA512
> > 
> > Howdy all,
> 
> Howdy, and thank you for your interest in helping.
> 
> > 
> > Here are my responses for the bug control membership application:
> 
> <snip/>
> 
> > > 2. Have you read Bugs/HowToTriage, Bugs/Assignment, Bugs/Status and
> >>  Bugs/Importance? Do you have any questions about that documentation?
> > 
> > Yes, I have read those pages. I am never afraid to ask questions, and
> > I error on the side of caution (and do nothing) rather than cause
> > potential disruptions.
> > I do have a question on one topic: Assigning importance is probably a
> > triagers most important job since it sets expectations and indicates
> > the understood priority to users, maintainers, and developers.
> > But I find it sometimes difficult to assign an importance:
> > A. Especially when the ticket it is incomplete, or
> > B. When the bug contains enough information to be "confirmed", or
> > maybe even "triaged" (if a patch is provided), but I am not familar
> > enough with that particular project to understand how severe the
> > problem is.
> > 
> > In Case A, I'm not too worried, because if a bug is truely incomplete,
> > then there is likely not information to accurately assign an
> > importance.
> 
> This is a sane approach, I agree. Some groups set a default Importance
> of Medium to all new bugs, and adjust as needed as the bug progresses.
> 
> > But in case B, is it suggested to leave the bug untouched (don't
> > change the status or importance), or change just the status, or change
> > the status AND make an educated guess on importance (on the assumption
> > that if it is wrong, someone else will see it and change it)?
> 
> This is a good point, and one difficult to give a definite answer ;-).
> But, of course, I will try (I never leave aside a chance like this).
> 
> First of all, you have to keep in mind the official definitions for
> Importance -- https://wiki.ubuntu.com/Bugs/Importance. One important
> point is we are free to *estimate* the potential impact. Of course, as
> time goes by, our estimates will usually get better -- we learn more,
> and more, about the specific package and Ubuntu/GNU/Linux. Hopefully.
> But, since we are expected to estimate, it is also implied that we may
> estimate *wrong*. Of course, if you get it wrong once in a while is
> rather different than if you get it wrong most of the times. Bug-control
> is expected to get it right most of the times.
> 
> It may also happen that, as time (and work on the bug) goes by, we learn
> more about the particular issue, and may decide the (currently set)
> Importance does not reflect our (now updated) understanding -- and we
> are free to reset the Importance to a new value. Any such changes -- in
> fact, *all* changes -- in Status and Importance should be explained in a
> comment.
> 
> Now, the most importance difference between a common triager and a
> Bug-control member the the ability to set the Importance (OK, and set
> the Triaged status). Apart from that, a bug-controller is pretty much
> identical to a non-bug-controller in capabilities. As such, we *do*
> expect you will be able to set an Importance. This is why we ask
> candidates to provide their best bet on what would be the bug's
> importance.
> 
> Adding it all up: as a member of Bug-control you *are* expected to give
> your best bet on the Importance. If it ends up being wrong, someone will
> indeed reset it, and explain why.

I absolutely agree here and think that we can do a better job of setting
importance more often and as early as possible.  Consider a vague bug
report where someone is indicating that they have lost data.  While
there is insufficient information to determine whether or not the bug is
valid, if it is valid the importance will likely be Critical.  So let's
set it right away.  By setting the importance as soon as possible we are
providing ourselves and other triagers an important way to prioritize
our work.

-- 
Brian Murray                                                 @ubuntu.com

Attachment: signature.asc
Description: Digital signature