← Back to team overview

linaro-project-management team mailing list archive

Re: Upstream and planning

 

On Mon, Aug 22, 2011 at 5:51 PM, Michael Hope <michael.hope@xxxxxxxxxx>wrote:

> On Tue, Aug 23, 2011 at 7:53 AM, Joey Stanford <joey@xxxxxxxxxx> wrote:
> > Howdy,
> >
> >>> A developer assigns the BP to themselves and retargets the BP out of
> >>> the backlog milestone and into the current monthly milestone.
> >>
> >> Sorry, in what state do they do this?  Does it stay in 'backlog' until
> >> accepted upstream?
> >
> > BPs that are created each quarter by new Roadmap cards go into the
> backlog.
> > At the end of the quarter we clean out the backlog to make room for
> > the next quaters BPs.
>
> Diversion: blueprints can be created at any time and are lodged into
> the backlog.  Blueprints may result from splitting cards as the result
> of investigation.
>
> >> How does someone else tell if a blueprint is free
> >
> > If a BP is in the backlog milestone then it by definition means that
> > it's not being worked on.  Ideally an engineer would go visit the
> > backlog and grab the next highest priority item off it. However what I
> > suspect will happen, and this is certainly very good as well, is that
> > you as the TL may choose to assign a BP to an engineer in advance.
> >
> > Think of it like airplanes in a holding pattern over an airport. Once
> > the tower is ready to do something with an airplane they move it out
> > of the holding pattern and put it on approach.  We're doing same
> > things.  BPs in the backlog are BPs in a holding pattern until
> > resources free up to work on them.
> >
> >> How do I tell what is in progress and what is blocked
> >> upstream?
> >
> > The monthly milestone view.  You move a BP from the backlog milestone
> > to your current monthly milestone. It will tell you want's done, in
> > progress, and blocked for that month.
>
> Yip, so that fits my original method.
>
> So my question stands: we don't control upstream and can't assign a
> blueprint to a monthly milestone as we don't have control over when it
> will actually land.  How should this be handled?
>

Should we have another milestone called 'Upstream' for example? (This
milestone would be a place holder milestone similar to the 'Backlog'
milestone)
Once an engineer is ready to work on a bp, he/she will move the bp from
Backlog milestone to Upstream Milestone.
That way, the TL/PM would know which bp's are being worked.
The progress of the bp would still be the started-> good progress or blocked
as you described before.

So the flow will be like the following:
 1. When a developer comes free, they pick the next best blueprint
 2. They assign it to themselves, remove the 'backlog' milestone, *mark it
for upstream milestone,* and
mark it as 'Started'
 3. If the work gets stuck in review or acceptance due to no response
then they mark it as 'Blocked'
 4. Once the work has been accepted, they mark the blueprint against
the next milestone
 5. They backport in a timely way
 6. Once backported, they mark it as as 'Deployment'
 7. On release, I change all 'Deployment' blueprints to 'Implemented'


The benefit of this is we can look at the Upstream milestone and see all the
bp's waiting on upstream.
if the bp  status ==  started, the bp is being worked
if the bp status == blocked , the bp is stuck on upstream

>
> -- Michael
>
> _______________________________________________
> Mailing list: https://launchpad.net/~linaro-project-management
> Post to     : linaro-project-management@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~linaro-project-management
> More help   : https://help.launchpad.net/ListHelp
>



-- 
Mounir Bsaibes
Project Manager

Follow Linaro.org:
facebook.com/pages/Linaro/155974581091106
http://twitter.com/#!/linaroorg
http://www.linaro.org/linaro-blog <http://www.linaro.org/linaro-blog>

Follow ups

References