ubuntu-bugcontrol team mailing list archive

[Scott Howard <showard314@xxxxxxxxx>]

Hello Omer,
Thanks for your application, here are my comments:


>>> 3) If coredump.gz is attached or stacktrace.txt (retraced) contains any
>>> text that look like password/css keys.

The coredump should not be attached, delete it if it is. You are
correct to remove any text that looks important (such as passwords and
keys).

>>>
>>> 4) I find empathy and nautilus to be very interesting for bug
>>> reporting/triaging

Great! They could use some love.

>>>
>>> 5) this is really a trick question.  depending on the intensity i will
>>> mark their importance. for example if computer cannot even start for many
>>> users then critical (e.g. X breaks) and the same if happens for a few people
>>> will make it High and if a core ubuntu application crash then it will be
>>> medium and a non-core application/small usability issue will be marked low
>>> and something that is some kind of feature request=wishlist.

It's pretty straight forward, please follow the importance guidelines from:
https://wiki.ubuntu.com/Bugs/Importance

Also, could you comment on what importance you would assign to the
bugs your reported below?



On Sun, Jan 10, 2010 at 7:17 AM, omer akram <om26er@xxxxxxxxx> wrote:
> https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/499529

Thanks for sending upstream! Please use stock responses to communicate
what you did:
https://wiki.ubuntu.com/Bugs/Responses
(see the one for reported upstream)


> https://bugs.launchpad.net/indicator-applet/+bug/488839/

Before confirming the bug, did you reproduce the bug? Before marking
confirmed I'd like to either have multiple users confirming the bug
with enough information that a developer could easily reproduce it, or
reproduce it myself. It seems that others had reproduced it, but it's
unclear if the bug is from Ubuntu or passed down from upstream.

> https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/504193

Good job on this one, fixing the title, getting it upstreamed,
assigning an importance, and triaging. I'd also update the description
once you got the information from the reporter. Again, try to use
stock responses (see the one for "not described well" or "steps to
reproduce"). Lots of bug reporters are frustrated and annoyed, and the
stock responses do a good job of acknowledging their concerns, even if
their bug report is not that good. Brian Murray maintains a package
with allows you to add stock responses on LP easily in firefox:
https://launchpad.net/launchpad-gm-scripts


>> https://bugs.launchpad.net/hundredpapercuts/+bug/431073

Thanks for sending upstream! Please use stock responses to communicate
what you did:
https://wiki.ubuntu.com/Bugs/Responses
(see the one for reported upstream)



>> https://bugs.launchpad.net/empathy/+bug/495385

A little more communication is needed (see the first comment, another
triager was confused by what you were talking about). Forwarding
upstream is great, but being a little more verbose in bug reports is
needed since many people will be looking at it that may not
immediately know what you're talking about. Also writing up test cases
could be a helpful (really dumb down test cases because potential
developers and fixers may be able to fix the bug even though they are
not familiar with the program at first). Ubuntu relies on "shared"
developers between maintaining several packages, so you may be more
familiar with some packages then the developers, and they could use
your help.



Overall opinion on application:
Helpful triager that has been active managing bugs. Has done a good
job getting bugs upstream.

Things to improve: being more verbose with your communications between
reporters, developers, and other triagers (stock replies would help
with that). Developers tend to work on bugs that are well described
with complete test cases, so try to include them in your upstream and
LP reports.

I'd give a +1 if omer keeps up the good work in bug forwarding and
triaging, but is also more thorough in communicating.

Regards,
Scott Howard