linaro-project-management team mailing list archive

[Alexander Sack <asac@xxxxxxxxxx>]

On Wed, Aug 17, 2011 at 12:42 AM, Christian Robottom Reis
<kiko@xxxxxxxxxx>wrote:

> On Tue, Aug 16, 2011 at 05:40:38PM -0400, James Westby wrote:
> > > > Milestone view
> > > > --------------
> > > >
> > > > I'm not sure what we want to do here yet, it requires some more
> thought.
> > > >
> > > > Estimate: ?
> > >
> > > Maybe the Launchpad milestone page is enough for the first cut. What do
> > > you think?
> >
> > I think so, Alexander disagrees.
>

> Just following up on this, it seems we need to flesh this part out
> further, which makes me happy as I mainly focused on the "Roadmap to
> Engineering" part of the process, but not on the actual monthly release
> cycle.
>
>
The main limitations with the Launchpad Project Group milestone view as
>

OK, to be honest, I wasn't exactly sure about what was proposed in kiko
slides.

Please correct me:
What I think we are discussing here is if and how we can make the milestone
page useful to a TL/PM/engineering role to support their day by day
tracking, planning and management of their team work/commitments - and all
that broken down to work item level?

The other discussion we could have is if we want to (rather) make milestone
pages better at conveying "what is in a milestone release for a component or
set of components and what is planned to be in the next release etc.". So
basically tuning for different type of audience.

Personally I feel that those are kind of conflicting as adding the detail
needed by TL/PM/engineering will make the page less useful for the other
audience and vv.

So, which audience should the milestone page address?
I am currently in the camp of saying:

... make milestone pages more useful to "communicate what's in and what's
planned for a milestone release"

...make status.linaro.org a very nice specialized "team work" page that
gives TLs/PMs/engineers exactly what they want and nothing more :).

Happy to hear what others think!


I see them:
>
>    - No rendering of work items
>
ack

   - Requires all projects to be within that project group
>

ack; note that this has to include visualizing the work items committed on
foreign projects/components if a TL/PM wants to use it to manage the work of
their team.


>    - No ordering of anything (though it does support AJAX sorting)
>

for project groups milestones i have looked at, blueprints seem to be sorted
by priority-order for now; bugs the same.


   - No view spanning milestones
>

that's a good idea and I would love to see that eventually.

-- 

 - Alexander