ubuntu-bugcontrol team mailing list archive

[Daniel Manrique <daniel.manrique@xxxxxxxxxxxxx>]

Hello,

On 12-02-05 09:26 AM, Brett Cornwall wrote:
>> 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? 
> Yes, my signature can be viewed at www.pad.lv/~brettcornwall
>>
>> Have you read Bugs/HowToTriage <https://wiki.ubuntu.com/Bugs/HowToTriage>,
>> Bugs/Assignment <https://wiki.ubuntu.com/Bugs/Assignment>, Bugs/Status
>> <https://wiki.ubuntu.com/Bugs/Status> and Bugs/Importance
>> <https://wiki.ubuntu.com/Bugs/Importance>? Do you have any questions about
>> that documentation?
>>
> I have read them and I am familiar with them. Should I need questions I will
> consult the wikis or ask another member.
>>
>> What sensitive data should you look for in a private Apport crash report bug
>> before making it public? See Bugs/HowToTriage
>> <https://wiki.ubuntu.com/Bugs/HowToTriage> for more information.
>>
> I should search for any passwords, possible bank numbers, user names, server
> names, or anything else that could be a potential breach of privacy/security.

You should never mark as public a bug that still contains *something* which you
didn't mention here. Could you please review the documentation (under Apport
crash reports) and see if you  may have missed something?

>> Is there a particular package or group of packages that you are interested in
>> helping out with? 
> None in particular for the long-term. I've been helping out on Launchpad since
> 2008 and have decided to try and elevate my involvement (as well as have the
> authority to change some bug statuses for those times when lone bugs are forced
> to wait for someone to come along.
> 
> I will probably start with Compiz and the software-center.
>>
>> Please list five or more bug reports which you have triaged and include an
>> explanation of your decisions. Please note that these bugs should be
>> representative of your very best work and they should demonstrate your
>> understanding of the triage process and how to properly handle bugs. For *all*
>> the bugs in the list, please indicate what importance you would give it *and*
>> explain the reasoning. /Please use urls in your list of bugs./
>>
> 1) https://bugs.launchpad.net/compiz/+bug/579688
> 
> I would set this as 'low' because of the trivial impact on users. It does not
> affect the program's functionality or stability in any way.
> 
> 2) https://bugs.launchpad.net/banshee/+bug/738862
> 
> I would set this to 'low' -- same reasons as the above.
> 
> 3) https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/923823
> 
> I would actually have set this to 'wishlist' as it's a feature enhancement
> request. Since it was reported upstream and properly documented it was ready for
> developer response.
> 
> 4) https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/297234
> 
> I would set this to 'medium' because of the non-frequency of such a setup does
> not warrant a 'high' value. It warrants a 'medium' rather than a 'low' because
> Compiz is a core Ubuntu application.

Bug 1) above is also for Compiz and you say you'd set it as "low". Importances
are somewhat subjective but I suggest trying to be consistent especially when
the bugs are about the same package.

> 
> 5) https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/768800
> 
> This is 'wishlist' material because this is a non-trivial extension of
> functionality not in the design scope. I confirmed the bug with my own tablet.
> 

I have to agree with Omer Akram's comments, a little more verbosity, especially
when first handling a report, IMHO helps reassure users that their bugs are
being looked at. You don't have to type a lot for this; you can take advantage
of the stock responses as Omer mentioned.

Kudos on the upstream reporting/linking, it's a bit difficult to get in the
habit but I see you're already doing well in this regard.

In general I like what I see but I'll be a +0 on this one (neutral). You have
good criteria and the inconsistencies I point out before are just a matter of
getting a bit more experience while triaging. It's not necessarily a
showstopper; should the group decide that you need to wait a bit for admission
to Bug Control, please don't be discouraged; asking for help to set bug statuses
in #ubuntu-bugs is a great way to improve your triaging skills.

Oh, and don't forget to check the sensitive data documentation I mention above
and amend your answer if you think it's needed!

> 
> Apologies is my application is not sufficient; I would appreciate any feedback
> for how I can improve my skillset should my evaluation lack the minimum
> requirements.

I hope my feedback was useful and thank you for applying.

Regards,

- Daniel

> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~ubuntu-bugcontrol
> Post to     : ubuntu-bugcontrol@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-bugcontrol
> More help   : https://help.launchpad.net/ListHelp