linaro-project-management team mailing list archive

[Alexander Sack <asac@xxxxxxxxxx>]

On Mon, Oct 1, 2012 at 1:20 PM, Alexander Sack <asac@xxxxxxxxxx> wrote:
> 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.

I meant "...ONE mail..." :)

>
>> 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



-- 
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