Work items tracking

[Kate Stewart]

On Tue, 2012-07-10 at 15:14 +0200, Sebastien Bacher wrote:
> Hey everyone,
> 
> I ran into some issues with the work items tracking and I wanted to 
> shared them and know how others deal with that,workaround the issues:
> 
> - status.ubuntu.com lacks summaries for some users, does anyone know 
> when it happens or how to workaround it?
> 
> example:
> 
> http://status.ubuntu.com/ubuntu-quantal/u/desrt.html is a "not found"
> where
> http://status.ubuntu.com/ubuntu-quantal/u/didrocks.html
> 
> is working

the work items are only tracked for those that are part of an existing
team in launchpad that the tracker knows about.  

if he's not a member of one of the teams in:
http://status.ubuntu.com/ubuntu-quantal/teams.html

his work items aren't individually tracked.   

There's a team where he can be added to, ubuntu-community-contributors,
so that tracking can start.   Ask him to ping me if he wants to be
added, and I'll help sort it, and anyone else that falls into this catch
all. 

> 
> - how do you track the work assigned to your team? the current team 
> views lists "the work corresponding to specs owned by the team", in 
> practice it means that the view has only part of the workitems assigned 
> to your team member ... i.e if a desktop has 5 desktop workitems but 25 
> items on a foundations spec those are basically untracked from the 
> desktop side. Did anyone figure a way to figure who is his team is 
> behind or overworked out of manually going through invidual pages for 
> each team member (when they work, cf previous bug)

Load balancing should be done before features are milestones/prioritized
and approved by team management.  

> 
> - https://launchpad.net/~lpid/+upcomingwork works but seems to require a 
> milestone to be set on the blueprints, so far we (at least in desktop) 
> only nominated specs for a serie (setting the "series goal") ... is that 
> something which should be done in a standard way? Would it make sense to 
> open a bug requesting the "upcomingwork" page to list any spec targetted 
> to the said serie rather than only the ones with an implicit milestone?

Yes, milestones and priority of the blueprint should be standard
practice to make sure are set on blueprints before they are approved.
The fields are there,  we should be using them to help us manage the
release.  :)  In terms of using the milestones, spreading the work out
and managing expectations about when features are landing, is what the
other teams are doing, and is good engineering practice to avoid
problems at the system level across teams. (for dependencies and
expectation setting).

If someone with launchpad skills wants to volunteer to do the work, we
can look at making it default to beta-1 for all blueprints not
explicitly assigned to a milestone in the series (closest point to
feature freeze),  since most blueprints are for features,  rather than
the end of the release.  Any volunteers?  ;)    

Thanks, Kate