ubuntu-bugcontrol team mailing list archive

[Brian Murray <brian@xxxxxxxxxx>]

On Sun, Feb 22, 2009 at 02:49:28PM -0500, Brian Curtis wrote:
> Bug Control,
> 
> Thanks for your time, here are my responses to the application questions:
> 
>    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?*  Absolutely,
>    there are situations I have been in that required a calm and cool
>    characteristics as bug reporters get angry or upset that their bugs haven't
>    gotten top priority.  I have signed the Ubuntu CoC.
>    2.
> 
>    *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 through all of them,
>    and on all bugs i've helped with have constantly come back to them for
>    assistance.  My question relates to wishlist importance, When you set a bug
>    to wishlist importance, does this consider the bug triaged (so you may set
>    it as so), or is it better practice to leave the status alone in this
>    situation?

We discussed this in #ubuntu-bugs today - wishlist bugs for feature
requests in software that is not native to Ubuntu to should become
Triaged after they have been forwarded upstream until then Confirmed is
appropriate.

>    3.
> 
>    *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.
>    * Its mandatory to look for any piece of txt/data in all attached files
>    to make sure that passwords or any type of sensative information is not
>    included before moving it to public (if this is the action you desire), its
>    still perfectly okay to leave a bug report as private for its existence.

While its okay it is not preferred, the number of people who are members
of ubuntu-bugcontrol (and see private apport crashes) is still a small
group.  In the interest of having more eyeballs on the problem it is
preferred to make the bug report after verifying there is no sensitive
information in it.  Additionally, there is no guarantee that upstream
developers are members of ubuntu-bugcontrol and would be able to see the
private crash reports.

>    4. *Is there a particular package or group of packages that you are
>    interested in helping out with? *I wish to help triage any and all
>    packages that I can.
> 
>    5. *Please list of five or more bugs which you have triaged. These bugs
>    should demonstrate your understanding of the triage process and how to
>    properly handle bugs. If there is a bug in your list that does not have an
>    importance indicate what importance you would give it after becoming a
>    member of Ubuntu Bug Control. Please use urls in your list of bugs.
> 
>    *Bug #1:
>    https://bugs.launchpad.net/ubuntu/+source/purple-plugin-pack/+bug/219093
>    this bug shows my ability to push bugs upstream and create bug reports
>    upstream if necessary, and this bug also shows my commitment to bug reports
>    and making sure that I give each bug report my all.

Thanks for taking the time to forward this bug report upstream this is
an invaluable service.  However, I'm uncertain as to why you've set the
bug's status to In Progress and assigned it to yourself.  If you are not
actually working on fixing the bug report it should be Triaged and
unassigned.

I also looked at http://launchpad.net/bugs/332689 and that should
probably be a backport request
https://help.ubuntu.com/community/UbuntuBackports#How%20to%20request%20new%20packages.

>    Bug #2: https://bugs.launchpad.net/ubuntu/+source/sysklogd/+bug/277924  I
>    feel this is important, as it shows I can create bug reports and help out
>    with them as needed.

While not incredibly detailed this looks fine.

>    Bug #3: https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/278405

This is great as you took the time to recreate the bug in a different
release of Ubuntu.  However, the bug description, particularly the
steps to recreate it, could have used some clarification.  (I've done
this now.)

>    Bug #4: https://bugs.launchpad.net/ubuntu/+source/grub/+bug/332962

It seems that you assigned this bug to the grub package which is more or
less correct.  Assigning bugs to packages is also an important thing to
be doing so thanks!

>    Bug #5: https://bugs.launchpad.net/firefox/+bug/207454 This bug shows my
>    ability to change titles appropriately, and to link upstream bug reports.

Again, finding an upstream bug report related to the Ubuntu bug is
invaluable work.  Thanks for taking the time to do this!

Based on the quality of work I've seen, discussions we've had in the
#ubuntu-bugs channel and Mackenzie's endorsement I'm happy to approve
your membership in the Ubuntu Bug Control team.  Welcome!

Sincerely,
-- 
Brian Murray                                                 @ubuntu.com

Attachment: signature.asc
Description: Digital signature