ubuntu-defect-analysts team mailing list archive

[Brian Murray <brian@xxxxxxxxxx>]

On Wed, Oct 05, 2011 at 05:24:24PM -0500, Kate Stewart wrote:
> Here are the notes I took down,  corrections, additional comments, etc.
> most welcome. 
> 
> Attendees:
> Ursula
> Pedro
> Brian
> Joe
> Kate
> 
> Agenda:
> 1) feedback to roles and responsibilities
> received from Rick Spencer:
> > Role:
> > Analyze defects reported about a team’s packages that are most 
> > important for the quality of the release and customer perception, 
> > and ensure that the defects are addressed by the engineering team.
> > This requires creating and maintaining metrics for determining the
> > quality of products and effectiveness of processes.
> I think the role definition can be stronger. For example, it could start
> with "The defect analyst is the primary driver for quality on their 
> team. A successful defect analyst will do whatever is necessary to help 
> their team release with maximum quality."
> 
> all basically ok with this. 
> 
> > Responsibilities:
> <snip>
>   - Work with the QA team to ensure that necessary automated tests are 
> in place, being run, and producing useful results.
>   - Regularly provide the team and the team's Manager with an accurate 
> understanding of the state of their projects at the appropriate level
> of 
> detail.
>   - Assist the Engineering Managers in channeling resources towards 
> areas and issues that require attention.
> 
> Kate tried to forward original email, but some issues with mailer,  will
> forward and make sure defect-analysts mail list is on,  so folks can
> respond individually.  
> 
> Some clarity is probably needed on a few of the points. For instance on
> bullet 2: provide the team and the team's Manager - should be DA's
> specific team, not QA team,  some ambiguity by positioning. Kate also
> requested that release team be added to the list of those who need to
> understand status of area. 
> 
> AI: Kate reply to note on list and ensure defect-analysts are back on
> the distribution so that they can follow up directly.

I replied with my thoughts to that email.
 
> 2) UDS Topics brainstorming
> 
> Discussion revolved around creating blueprints that will extend from
> work done at London Sprint.   For cross functional topics like this,
> please use "other" track for the blueprint. 
> 
> Topics:  
>    Team Specific Bug review dashboard:   Brian to start off blueprint
>        - use subscribed packages for team, as framework, so can be set
>          for different teams.
>        
>    Team Specific Based Metrics:  Brian to start off blueprint draft 
>        - use subscribed packages for a team, so can be set up for 
>          different teams and sets of packages. 
>    
>    Summary of Team Specific Bugs,  Metrics:  Kate to start off blueprint
>        - extract from team specifics into common overview for release

If I recall correctly this was more about the release quality.  Is that
right?

>    Common process across all teams for use of milestones for bug: ??
>        - set the milestone by launchpad janitor when they were fixed??

One idea is to have the Launchpad janitor set the milestone to the next
milestone for the release by examining today's date and the release
specified in the changelog entry.

As an example if you look at http://launchpad.net/bugs/793950 the
janitor would set the milestone for this to ubuntu-11.10.

>        - prototype it with old release on staging?  set all the
>          milestones and look at historical data (bugs fixed by
>          milestone as well as those fixed which were formally 
>          assoicated with milestone).  discuss with launchpad team.

My thought here was to take a release and set all the milestones using
changelog information and then play with the data to see what kind of
useful information we get out of doing this.  Is it useful to know that
most bug fixes happen between beta-2 and final? (This is made up.)

>        - use of release tasks in bugs - really going to be fixed 
>          in Oneiric vs. future SRU. 
>        - consistency of use of milestones - be able to expect them 
>          done to earlier.    As soon as plan to fix. 
> 
>    Automated package assignment for "no package" bug reports: Brian  

One thing I want to work on during the Precise cycle is assigning no
package bug reports to packages based off the text in the bug
description.  For example if 'no sound' is in the description assign the
bug to linux.

>    Bug Lifecycle rework ??
>      AI: Brian to review survey feedback, summarize impressions
>      Kate wants to get states clarified, and plans drawn up 
>      in P so, we can get this cleaned up with Launchpad team's help
>      in Q, if not before. 
> 
> 3) Bugs want to see fixed in P by certain milestones.
>    AI all: brainstorm ways that the not fixed bugs from last release
>    can be surfaced and tracked in low impact way,  and then get factored
>    into work and committed to specific milestones during release.
>    AI all: use rls-mgr-p-tracking tag for any bugs found for now, until
>    we can come up with something better.
>    AI Kate: discuss commitment to fix certain designated bugs by 
>    specific milestones with the other managers at release sprint, 
>    prep. for UDS.
> 
> 4) Launchpad bug priorities
>    Need to figure out a prioiritzed list of bugs that the defect
>    analysts feel is important to have addressed. (Searching for
>    information inside launchpad,  API's missing, timeouts, etc.)
>    AI: each DA subscribe top 5 bugs to defect-analyst-list
>    https://bugs.launchpad.net/~ubuntu-defect-analysts

I believe the point of subscribing the team to the bugs was for us to
have a way to find the Launchpad bug reports that are important to us as
a team.  Additionally, its a way for me to be alerted to a bug report
about Launchpad that Ursula thinks is important. So limiting the number
of bugs that each of us subscribe the team is not helpful.

Instead I think we just need to keep personal notes about which are our
top 5 or track them in the white board for the blueprint.

>    AI: In brainstorming session,  discuss and prioritize the top ones
>    for the virtual team.
> 
> 5) Back to regular meetings on Monday.
>    Kate will miss next monday.  Volunteers to host?

While I'll be working next Monday it is a US Holiday.  Joseph will you
be working?

--
Brian Murray
Ubuntu Bug Master

Attachment: signature.asc
Description: Digital signature