On Mon, Oct 1, 2012 at 12:50 PM, Ricardo Salveti <[email protected]> wrote: > On Mon, Oct 1, 2012 at 10:08 AM, Alexander Sack <[email protected]> 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 _______________________________________________ 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
