linaro-project-management team mailing list archive

[James Westby <james.westby@xxxxxxxxxx>]

On Wed, 3 Aug 2011 17:39:23 +0100, Joey Stanford <joey@xxxxxxxxxx> wrote:
> Hi Kiko,
> 
> I've updated the slide deck with items from today's Project Management
> discussion.

Hi,

[tl;dr: we can likely do this, but there are some risks if we want it
before the next connect]

Here's my thoughts on the changes required to implement this change from
a tools point of view, based on a fleshing out of the "Code Required"
section of this presentation. I've included my very rough estimates for
each part of the work.


Linking a blueprint to a card
=============================

We have a few options here:

  1. Put the link in the description and use a regex to pull it out
  2. Use the "URL for this specification"
     - Can't link multiple BPs to a card without LP changes or hacks
     - Means that we can't use that link for e.g. wiki notes on the work
  3. Create something like our TR BPs that represent the card on LP and
     use dependencies as we do now.

I propose option 1.

Estimate: 1/2 day to add the regex to pull this out.

Meta information for BPs
========================

I agree with the proposal to use a convention in the
description/whiteboard as we do now.

Estimate: 1 day to extend the parser to recognise these things.

status.linaro.org
=================

Card view
---------

For this we really need an API for the cards. Does kanbantool have an
API? This is a risk.

This will be similar to the TR view as we have it now, showing the
blueprints contributing to that card and their progress. It may or may
not have a burndown chart for the card.

The page will include the expected milestone for each part of the work.

This page will be pretty high level, focusing on "I requested this card,
is it being worked on and when can I expect to see stuff?"

Estimate: 4 days to provide this view assuming we have the card API

Lane view
---------

This will be similar to the front page that we have now, showing one
particular lane (Quarter for nearer things, longer time for further
away.)

It will show the cards that are in that lane, with an indication of the
progress on them.

You will be able to jump to the card view for any particular card.

Estimate: 4 days to provide this view

Milestone view
--------------

I'm not sure what we want to do here yet, it requires some more thought.

Estimate: ?

Past work
---------

The lane views will be available for completed lanes so that you can see
what has been delivered.

We may also want to produce aggregate information to show things like
things delivered in the past 6 months for a particular sponsor.

Estimate: 2 days to provide something simple, another 3 days to provide
things like filtering by sponsor.

Performance information
-----------------------

One of the things that status.linaro.org currently does is provide some
idea of how the team is progressing.

We will show some of this for the current and previous lanes.

In addition we might want aggregate info for completed lanes. This would
show things like number of workitems and %completed for each of the
months/quarters.

I think this requires some more thought, and isn't needed in order to be
able to plan the future, so we may want to defer until after then next
connect.

Estimate: 2 days, but defer from this round.

Blueprint/card health check
---------------------------

Each blueprint and card should have a "health check" that shows whether
it has what it needs.

We will likely want to show a per-team view that just highlights
problems.

Displaying most of this is likely pretty straightforward. Displaying
workitem parsing errors  is more complex than the other parts.

Estimate: 3 days for simple health check, 2 days for workitems errors, 2
days for per-team view.

Launchpad milestones
====================

I contacted Francis about whether we will be able to change the
milestone rules on Launchpad, and am awaiting a response.

This is important if we wish to push some of the monthly visualisation
off on to Launchpad, otherwise we may be forced to provide the view in
status.linaro.org.

This is a significant risk for this project.

Estimate: 0 days, assuming that we can change this and the LP team does
it.

AJAX workitem editing
=====================

While this would be nice to have, it isn't required as it will still be
possible to edit workitems in the current manner.

A prototype in greasemonkey is likely the best way to approach this.

Estimate: defer from this round, so 0 days.

Bonus features
==============

I'm going to defer looking at this for now, except to stay that using
Launchpad milestone view for the team pages is apparently contreversial,
and so we should discuss that further.



Scheduling this work
====================

The rough estimates about total ~20 days work. This means that we need
at least one person month to be dedicated to this work.

We have 2 months to complete this if we want it in place *before* the
next Connect.

Looking at the workload for the team:

Deepti: I think that we want to keep her on CI at least until the next
Connect.
Salgado: away for two weeks, and then working on private hardware pack
builds, which has an estimate of 6 weeks, so that means he can't work on
this if we want to deliver in 2 months. It may be quicker than 6 weeks,
but it would be a significant risk to bet on that.
James T.: Also going to work on private hardware pack builds, after
finishing up some fetch-image work, so same as above.
Mattias: away for one week, then continuing with hwpacks v2. Assuming
there are no further substantial changes in the acceptance criteria of
that project he can likely finish in August.
Paul: Working on Gerrit, then CI for Android, likely to take more than
two months.
Me: I could work on this, but would need additional support from
elsewhere to avoid the other projects suffering.

So, it looks like we can take this on, with Mattias starting on it once
he finished hwpacks v2. Assuming we want this in two months, this
presents some risk, unless we have a backup plan for the next connect.


So, I think we have the following to do from here:

  * james_w to go over the details again to try and find other work that
    has to happen and so will affect the estimates, and to look for
    other risks. This will particularly focus on milestones as that was
    ignored above.
  * james_w, joey, kiko to work with LP to get a satisfactory resolution
    to the milestones issue, and come up with an alternative plan if
    that isn't going to happen in time.
  * kiko, would you look into whether kanbantool has an API? If it
    doesn't then we can discuss alternative approaches.

Now it would be great to have a system in which I could enter all the
work, split it up and estimate it :-)

Thanks,

James