linaro-project-management team mailing list archive

[Alexander Sack <asac@xxxxxxxxxx>]

On Mon, Oct 1, 2012 at 12:50 PM, Ricardo Salveti
<ricardo.salveti@xxxxxxxxxx> wrote:
> On Mon, Oct 1, 2012 at 10:08 AM, Alexander Sack <asac@xxxxxxxxxx> wrote:
>> +1 for killing the status.linaro.org external use-case (we still may
>> need it to map cards to blueprints for internal convenience use)
>>
>> So:
>>  * let's internalize status.linaro.org by making it
>> cards2blueprints.linaro.org without a redirect
>>  * ensure we have have sharp monthly reports that reflect reality for
>> TSC/mgmt/stakeholders
>
> Would this monthly reports be based on the output of this new
> cards2blueprints.l.o? If so, that would basically mean we'd need try
> to keep the system updated again.

I would like to get to a point where leads together with their PM
submit one report a month that is accurate. This should then be the
source for OPSCOM to do a sharp report about progress state of the
cards and also be the main source for our release highlights.

>
> Ideally I'd also like to see it working as an easy way to find out
> what is happening across the organization, but the reality proved
> otherwise.

I don't think automation tools will be able to provide the report.
They can be good data sources for TLs/PMs and OPSCOM to get the start
data set that then gets refined to be a sharp and accurate report that
our stakeholders and managers know is accurate.

>
> From a tech lead point of view, we just got too many reports and
> places to put status, and before moving this forward we'd probably
> want to clean that up as well.

I agree on the too many reports and we have to streamline for sure. We
just have to remember thjat automation is something that can only be
good to give you a starting point internally. Once that is understood
we can go and work on a single reporting mechanism where TL/PM puts
everything that is needed for the various channels and audiences in.
Clear goal should be to have roughly ONE mail that the TL/PM is
supposed to send per month with all info included (using or not using
the automation to source his data).

>
> One example from my side:
>  - Weekly update at blueprints
>  - Weekly update for cards

Only thing that we need on high level on a weekly basis is really
weekly alerts in case something got stuck.

The rest is all internal execution details that we can delegate to the
teams/PMs.

>  - Release specific updates (highlights)
>  - Post-mortem updates
>  - Platform monthly report (mostly the same release highlights)
>  - Engineering exec report (highlights and future work)

platform monthly report moved into engineering exec report

However, yes. I want to find a mechanism where TLs/PMs just have to
send on mail that includes all info needed for all the above
channels/audiences.

> Besides the normal monthly planning and engineering :-)
>
> It seems it'd make sense if we could mostly shift entirely to cards
> directly, and use blueprints to track work not directly involved
> there. From the weekly cards update, we could mostly automatically
> generated all the other reports.

As I said for management and stakeholders all that matters is getting
accurate updates on progress on cards.

Using blueprints, bugs or spreadsheet is ultimately an team-internal
execution detail that doesn't matter so much for our stakeholders and
manager and doesn't need a corporate wide policy.

My believe is however, that TLs/PMs will want something they can
delegate to their reports to own for their tracking.

-- 
Alexander Sack
Technical Director, Linaro Platform Teams
http://www.linaro.org | Open source software for ARM SoCs
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog