linaro-project-management team mailing list archive

[Ricardo Salveti <ricardo.salveti@xxxxxxxxxx>]

On Mon, Oct 1, 2012 at 12: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.

+1

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

Yeah, automation would probably help just to have an easy way to get
the broader picture (per team at least).

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

We just need to connect this one email with the release highlights.

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

I agree on that, but at the moment it seems we actually need to put
engineering status update at every card, weekly. Maybe that's because
we want to make sure the card is not blocked, but that is already
something the PM would know.

The PM should be the one raising any block issues that the team might
be facing, and we should just properly update the card once a cycle is
done.

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

Ok, that makes more sense then.

Thanks,
-- 
Ricardo Salveti de Araujo