ubuntu-bugcontrol team mailing list archive

[Matt Fischer <matthew.fischer@xxxxxxxxxxxxx>]

On 05/18/2012 09:40 AM, Dave Morley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 18/05/12 15:53, Daniel Manrique wrote:
> > On 12-05-10 10:55 AM, Dave Morley wrote:
> > > Hi, I'm Dave Morley (davmor2) and I've been part of the bugsquad
> > > for a long while now. I was fairly active early on till apport
> > > bugs started coming in and I had no idea on how to read them. I
> > > move over to iso testing at that point.  I've done a lot of work
> > > with developers triaging bugs I've come across, confirming issues
> > > and writing out steps to reproduce to help the devs out and
> > > obtaining more info for them.
> > > I now work for canonical and am working for the Consumer
> > > Applications team, this work involves everything to do with
> > > Software Center. Because of this work I need to gain additional
> > > triage rights to help the developers with the ubuntu based
> > > Software Center Bugs.
> > > - 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 I will continue being polite to any reporters and I've signed
> > > the CoC since the beginning.
> >
> > > - Have you read Bugs/HowToTriage, Bugs/Assignment, Bugs/Status
> > > and Bugs/Importance? Do you have any questions about that
> > > documentation?
> > > I have read the pages that still exist there are a few links that
> > > may need updating to point at the more up to date links.
> > > Example DebuggingProcedures
> >
> > > - What sensitive data should you look for in a private Apport
> > > crash report bug before making it public?
> > > Any Passwords, Account details of any sort, Login details, keys
> > > of any sort, server names.  If there is no retrace attached or
> > > there is a coredump.gz attached
> >
> > > - Is there a particular package or group of packages that you are
> > >   interested in helping out with?
> > > software-center, aptdaemon, update-manager but primarily just
> > > software-center
> > > - Bug list:
> > > https://bugs.launchpad.net/ubuntu-webcatalog/+bug/987851
> > > This example bug was confirmed by the maintainer but was triaged,
> > > reported and importance set by myself following guidlines that
> > > our team had laid out.
> >
> > > https://bugs.launchpad.net/ubuntu/+source/ldtp/+bug/979183
> > > A bug report that was sent upstream when I discovered the lead
> > > dev preferred them there rather than on launchpad.
> >
> > > https://bugs.launchpad.net/ubuntu/+source/unity/+bug/967085
> > > Understanding how the system was meant to work meant I could
> > > track down this issue report it to the correct team and see it
> > > confirmed in a very short period of time.
> > > https://bugs.launchpad.net/ldtp/+bug/979229
> > > Another Bug sent to upstream
> > > https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/969266
> > >   One assigned to me that I am currently working on but can't
> > > reliably interact with other than comments currently.  So you can
> > > see the issue I face.
> > > Sorry for the lack of bugs I mostly triage bugs that are for
> > > private teams now. So I've had a struggle finding some that I
> > > could display.
> > > I'm hoping that these should be enough to warrant that I can work
> > > with upstreams, set bug tags correctly that are relevant to our
> > > team, set importance to the correct level by the merits of our
> > > team, and can work with our own developers to confirm and triage
> > > bugs.
> > Hi Dave,
> >
> > Thanks for applying for Bug Control!
> >
> > I notice a lot of the bug reports you sent have no importance, and
> > you didn't discuss anything on the importance you would have set
> > for them. This is relevant as one of the main things Bug Control
> > folks do is set importance for bugs, and evaluating your criteria
> > and judgement for this is perhaps the main point of the application
> > process.
> >
> > Could you, then, for these bug reports, comment a bit on the
> > importance you set / would have set for them?
> >
> > Also remember that you can ask for bug importances to be set, Bug
> > Control members are there to help with this too.
> >
> > Thanks again!
> >
> > - Daniel
> Hi Daniel,
>
> So for us in the Consumer Applications server team (where I have
> triage, stat changing status currently) we have a slightly different
> way of using the importance tool that we might look to port over to
> Software-center also.  So that the whole team is off the same page
> when it comes to the importance of a bug. Due to this on going talk
> there is no definite decisions as to the right way of using this
> feature currently.
>
> As for the bugs listed in my examples then I would mark the importance
> as follows:
>
> https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/969266
> Critical till the initial purchase issue was resolved then lower the
> bug standing to medium for any ongoing work.
>
> https://bugs.launchpad.net/ldtp/+bug/979229 this is a medium bug for
> me in that I can work around the issue but it's not ideal.
>
> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/967085 I would
> set to medium it's not something that is a game stopper but should be
> dealt with and isn't noticeably affecting a lot of users.  I would
> escalate this to high if more people confirm this though.

I'd say this is low since it's just a cosmetic issue.  (I also updated 
it with my attempt at a repro)
> https://bugs.launchpad.net/ubuntu/+source/ldtp/+bug/979183 should be
> set to fix-released and medium, again I am the only person really
> affected by this but it was preventing me doing my job effectively.

Thanks for sending this upstream.  I think your bug title upstream makes 
a lot more sense than the one here.

> https://bugs.launchpad.net/ubuntu-webcatalog/+bug/987851 I already set
> this to low which in our server talk means that this is annoying but
> works just not as expected and should be worked on in time for the
> 12.10 release or earlier if possible.
>
> The bug listed are mostly written by myself as they are the bugs that
> I interact with the most.  The move to include USC with the work I do
> on USC server is the only reason that I am applying for membership and
> so if we (Consumer Applications) as a team settle on using one
> methodology for marking importance then it will suddenly become more
> import for me to be able to triage payment issues that might be report
> against USC in a more timely manner, it would also mean that as the
> guy in charge of QA for the CA team I would be able to spend one day a
> week sitting and triaging the USC bugs in a format that everyone on
> our team is familiar with.
>
>
> I hope this helps but feel free to ask anything else.

Dave,

All the bugs you showed here were ones that you filed.  I think that a 
large part of triage is taking a bug from someone else and working with 
that bug until it's ready for the developer to work on.  Another part is 
improving existing reports with tags, more info, versions, repro info, 
etc.  Do you have any examples of those?