ubuntu-bugcontrol team mailing list archive

[Draycen DeCator <ddecator@xxxxxxxxx>]

hggdh,

Thanks for the response. Sorry about the URLs, I just noticed that on the
wiki. I'm not sure how much information you want in regards to my process in
deciding importance, so I've included just about everything you could need.
Below is an explanation of how I decide the importance of bugs. (As a side
note, I followed the wiki when I sent my application, so maybe add a step in
there asking us to show examples of our procedures for deciding bug
importance?)

Wishlist:
- The report is requesting a reasonably small, well defined feature addition
or change in a program.

Low:
- The bug is a cosmetic issue that does not inhibit functionality of a
program.
- The bug seems to be affecting one person (and maybe a few others in a
small group) only intermittently, and it is not serious (no crashing, just
affects functionality slightly).
- The bug has a simple workaround.

Medium:
- The bug causes a program to crash for a small amount of people.
- The bug, while not causing a crash, affects functionality of a core
application and affects a moderate amount of users.
- The bug affects hardware that is not necessary for running Ubuntu.
- The bug affects a large number of people, but the program is a non-core
application.

High:
- The bug is causing a core application to crash for a significant number of
users.
- The bug makes Ubuntu unusable for a small group of users.
- The bug affects hardware that is essential to running Ubuntu.

Critical:
- The bug causes severe problems for a large portion of Ubuntu users.

In regards to the bugs I posted, here is my justification for the importance
assigned to them:

https://bugs.launchpad.net/ubuntu/+source/window-picker-applet/+bug/485352
(Low) This report is requesting a trivial feature be added to the Windows
List Applet, and the desired function is clearly stated.

https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/523236
(Low) The bug is simply a cosmetic issue, which does not affect
functionality in any way. Also, while the translation is not correct, users
are still able to tell what it is supposed to mean.

https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/517777
(Low) Once again, this bug is a cosmetic issue that does not affect
functionality. In the event that the background does happen to be black and
render the text unreadable, the user can simply close nautilus and reopen
the folder in order to resolve the issue. There is also a simple workaround.

https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/515725
(Low) Another cosmetic bug that only minimally affects functionality. The
user is also able to easily reset the zoom so the display is correct again.

https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/516154
(Medium) I originally viewed this bug as Low due to the easy workaround of
simply not using the "Ask me every time" feature. However, after some
discussing in #ubuntu-bugs, it was suggested to me that this could
potentially be seen as a security issue since it involves cookies. As a
result, we determined that Medium was a better fit for this report.

https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/514782
(Medium) This bug affects the functionality of a core application, so a
moderate amount of people are likely to be affected.

Hopefully this is a sufficient explanation of how I decide Importance.

Thanks,
Dray

P.S. - Thank you for the comments hggdh, I will remember them and apply them
to future bugs =)

On Thu, Feb 25, 2010 at 4:45 PM, C de-Avillez <hggdh2@xxxxxxxxxx> wrote:

> On Mon, 22 Feb 2010 00:11:57 -0600
> Draycen DeCator <ddecator@xxxxxxxxx> wrote:
>
> > 1. Do you promise to be polite to bug reporters even if they are rude
> > to you or Ubuntu? Have you signed the Ubuntu Code of Conduct?
> >
> > Response: Yes I do, Bug #517777 is evidence to this pledge. Yes, I
> > have signed the CoC.
>
> Generally, it is better to provide the full URL to a bug -- I, at
> least, am lazy ;-)
>
> Oh, I do remember this one. For the record, I was complaining of *all*
> the continuously changing description, the (re)assignments, and the
> status changes. All in all, I think he just had a bad day. Good work.
>
> <snip/>
>
> > 3. What sensitive data should you look for in a private Apport crash
> > report bug before making it public?
> >
> > Response: Coredump.gz files should be removed (if they are not
> > needed) from reports before they are made public. If there is no
> > Stacktrace.txt file, then the Coredump.gz file should remain on the
> > report, the report should remain private, and Martin Pitt should be
> > contacted via IRC. The Stacktrace.txt file (if there is one) should
> > also be examined for personal information, such as account numbers,
> > passwords, usernames, etc. before a report is made public. If the
> > Stacktrace.txt file is complete and does not contain any personal
> > information, then the Coredump.gz file can be removed and the report
> > can be made public.
>
> Well, it seems our hammering on coredumps did some good...
>
> A bit more on this: if 'apport' is still subscribed to the bug, then
> the apport retrace magic has not yet taken place; in this case, it is
> better to way for it. This should also be visible by the presence of
> 'need-*-retrace' tags.
>
> <snip/>
>
> > 5. Examples of triaging skill. Below are six examples of my
> ability to
> > handle bug reports. The importance of each report was requested by
> > myself on #ubuntu-bugs, and a Bug Control member changed the report
> > for me.
> >
> > Bug #485352
>
> Good work. I particularly like the fact that you try to explain what
> you did and why you did it.
>
> > Bug #523236
>
> Another good work. Although I can understand the frustration of those
> that do not read French, I sort of agree that in English the error would
> not be that evident ;-)
>
> > Bug #517777
>
> Already discussed. Nice call not to mix yourself in the brouhaha.
>
> > Bug #515725
>
> Extra points for searching for, finding, and adding the Mozilla bug.
> Now, what does the tag 'upstream' mean?
>
> > Bug #516154
>
> Nice sequence. One comment: it is a good idea to review the canned
> response for a duplicate if it is used some time after comments to the
> bugs have been made -- mostly if you, or somebody else have already say
> 'thank you for reporting...'. Usually we thank the OP for opening the
> bug *once* per bug ;-)
>
> > Bug #514782
>
> Also good work!
>
> > These bugs are in no particular order, and I have selected these six
> > in order to show my experience with different aspects of triaging
> > (i.e., filing upstream, translation bugs, testing on development
> > release, dealing with a rude reporter, etc.)
> >
> > My mentor is Pedro (pedro_), however I have had difficulty in keeping
> > in contact with him, so I am not sure how much he has been following
> > me. Others who have helped me most on #ubuntu-bugs include hggdh,
> > persia, and micahg.
>
> This can happen, unfortunately. This is one reason we have been trying
> to match availability on both sides.
>
> On the other hand, anyone at #ubuntu-bugs can chime in and help, as
> happened with you. In a very real sense you were mentored by all.
>
> >
> > I really enjoy working with Bug Squad and Bug Control members, and I
> > look forward to becoming a more integral part of the team!
> >
> > Thank you for taking the time to review this application,
> > Draycen DeCator (ddecator)
>
> All in all, good work. The *ONLY* thing that is preventing me from
> giving you a positive 1 is...
>
> WHERE ARE YOUR VIEWS OF HOW IMPORTANT (or not) A BUG SHOULD BE?
>
> This is the major difference for -control. Only -control can set an
> importance. It is not the only difference, but it *is* the major one.
>
> So -- please -- give us your view of how *you* would set the
> importance. After reviewing them -- and I would expect you get them
> very much correct --, I will be extremely happy in giving you a +1.
>
> Right now, thou...
>
> +0. # should be 1...
>
> ..C..
>