linaro-project-management team mailing list archive

[Alexander Sack <asac@xxxxxxxxxx>]

where do we have the latest slide deck? could we put that in google
docs? Thanks!

On Sat, Aug 6, 2011 at 9:53 AM, James Westby <james.westby@xxxxxxxxxx> wrote:
> 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
>



-- 

 - Alexander