On Mon, Aug 22, 2011 at 5:51 PM, Michael Hope <[email protected]>wrote:
> On Tue, Aug 23, 2011 at 7:53 AM, Joey Stanford <[email protected]> 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 : [email protected] > 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>
_______________________________________________ Mailing list: https://launchpad.net/~linaro-project-management Post to : [email protected] Unsubscribe : https://launchpad.net/~linaro-project-management More help : https://help.launchpad.net/ListHelp
