ubuntu-bugcontrol team mailing list archive

[Brian Murray <brian@xxxxxxxxxx>]

On Sun, Feb 12, 2012 at 09:42:12PM -0500, Daniel Manrique wrote:
> 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 love the fact that you made a screencast of this!
 
> 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.

With regards to verbosity - because precise is still under development
it would be helpful if you were to mention the package version with
which you were testing in compiz.

It is also useful to tag bugs using the release code name, oneiric and
precise in this example, so that one could search for bugs affecting or
found in precise.

Based on your application, the quality of your work and the other
endorsements of your application I am happy to add you to the Bug
Control team.  Thanks for helping out and welcome!

--
Brian Murray

Attachment: signature.asc
Description: Digital signature