On Tue, Aug 16, 2011 at 3:15 PM, Zach Pfeffer <[email protected]> wrote: > On 15 August 2011 04:29, Amit Kucheria <[email protected]> wrote: >> On 11 Aug 15, Michael Hope wrote: >>> On Sat, Aug 13, 2011 at 4:24 AM, Joey Stanford <[email protected]> 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. > > We've been doing the monthly milestone thing since 11.05: > > https://launchpad.net/linaro-android/+milestone/11.05 > https://launchpad.net/linaro-android/+milestone/11.06 > https://launchpad.net/linaro-android/+milestone/11.07 > https://launchpad.net/linaro-android/+milestone/11.08 - in progress > > I've actually found that by executing each month that I end up with > less WIs that are more directed. If something doesn't get done and > there's been something tangible completed I split the BP. If nothings > really been done I either move the BP to the next month or put it into > the backlog. > > The other nice thing is that its easy to create Headlines and > Acceptance criteria on the smaller chunks of work.
I'm willing to give it a try, but I am concerned about how anybody is going to figure out what work was done on a feature if it is splattered across 5-10 monthly blueprints? >> 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'm not sure why this is so unreasonable. It takes roughly 1 min to > create a BP for the month. Plus once its created than people like > Android or Platform can see what the 1-3 features you're going to > deliver and create matching integration BPs. > >> 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. > > With the month-to-month planning I find BPs don't take much time to > make. I always keep in mind that a BP is just a tracking and > communication tool, its not the work. > >> 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? > > I'd vote against this. It may be a tool limitation, but its much > easier to look at the BP list: > > https://launchpad.net/linaro-android/+milestone/11.07 > > ...and see whats coming than drilling down into each one. We differ in our perspective. You're looking at it from the POV of making a release. I'm looking it from the POV of keeping all the data on a feature in one place to be able to point to upstreams/prospective members, non-Linaro member engineers, etc. >> 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. > > Its been my experience that the monthly view is easier to grok for > external people looking at a project than having a 6 month detailed BP > which someone has to dig through. > >> Can't we teach the LP milestone view to understand repeated retargetting of >> the blueprint every month? >> >> /Amit >> OK. We'll try it for 11.09 (with reservations) and see what blows up. /Amit _______________________________________________ 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
