ubuntu-bugcontrol team mailing list archive

[Brian Curtis <briancurtis.wx@xxxxxxxxx>]

Thank you Brian and Mackenzie,

Since bug triage is always a learning process, I am always open to criticism
from others for the benefit of learning from it.

~Brian

Research is what I'm doing when I don't know what I'm doing.
--Wernher Von Braun
"The second law of thermodynamics: If you think things are in a mess now,
JUST WAIT!!"


On Fri, Feb 27, 2009 at 4:21 PM, Brian Murray <brian@xxxxxxxxxx> wrote:

> 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
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkmoWUUACgkQDTAwc5ER+zUc/gCgvUg5PYu2Hf/m/CjQ/o0nzKzM
> OQgAoNFgtcgW9UMA5JHmYMosozUnJc1s
> =o02L
> -----END PGP SIGNATURE-----
>
>