linaro-project-management team mailing list archive

[Amit Kucheria <amit.kucheria@xxxxxxxxxx>]

On 11 Aug 15, Michael Hope wrote:
> On Sat, Aug 13, 2011 at 4:24 AM, Joey Stanford <joey@xxxxxxxxxx> wrote:
> > Hi TLs and PMs,
> >
> > As we think through the delivery of monthly milestones and their
> > affect on status.linaro.org it's become very apparent that WIs should
> > /not/ span months. Instead they should exist on a BP you intend to
> > deliver in one month.  If you have a piece of work that will span
> > multiple months then it should be multiple BPs (i.e. one BP per month,
> > not two months working on one BP).  If you think you'll span months,
> > please split the work into (minimally) one month chunks as BPs.
> >
> > This allows us to use the LP milestone view and not spend time
> > updating status.l.o with essentially duplicate functionality. It also
> > allows us to spend more time improving the "card view" (Roadmap item
> > completion).  Additionally it allows us to better communicate
> > success/failure to the TSC (we're delivering something that someone
> > could attempt to use vs some obscure subset of WIs).   And lastly,
> > it's just plain easier for you to manage a single BP per month than
> > WIs from several BPs spanned across multiple months.
> 
> What's the driver behind this?  I'm concerned we're working around
> limitations in the tools and losing information along the way.
> 
> Say I have a feature that will span months.  At the moment I have one
> blueprint that tracks that feature with clumps of work items that go
> against the months.  The work items are small and much less than a
> month so, if I'm ahead of schedule, it's easy to pull in extra work
> for this month by shifting lines on the whiteboard.
> 
> This feature == blueprint is easy to find and share.
> 
> The alternative is splitting the feature into many blueprints and
> adding them as dependencies.  The current Launchpad UI makes ordering
> these hard, duplicates lots of information, and makes it hard for a
> Roger-like person to understand what's involved.  As blueprints are
> roughly a month, then you risk being 90 % done but missing the
> milestone, and can't easily pull in work from next month.

I agree. This one-month limit for blueprints feels arbitrary. I have 30+
feature (engineering) blueprints ATM. Separating them into monthly blueprints
will explode the number and make them harder to find and track.

Consider the case of developing a tool, say, powerdebug. Every month we might
add a small feature or so. Or fix a bug. So I'm expecting there to be 1-3 WIs
related to powerdebug every month. You're asking me to create a new blueprint
every month for 1-3 work items. I find that unreasonable.

I might be in the minority here, but I feel that creating blueprints has a
lot of overhead (drafting, assigning, status, milestones, dependency linking,
etc.), not to mention sustained housekeeping (whiteboard, status, work items)
and making sure that outsiders can make sense of our blueprint hierarchies.

The only way I'd find this remotely enjoyable is if we had a blueprint clone
tool that DTRT.

Why can't we live with "Work items for <milestone>:" sections in a single
blueprint so that all information related to said feature can be found in a
single place?

The TSC and (non-assigned) member engineers are just beginning to understand
how to track our work. Monthly blueprints will scatter information across
several blueprints making it impossible for them and further increase load on
us to provide them with yet another status report.

Can't we teach the LP milestone view to understand repeated retargetting of
the blueprint every month?

/Amit