Open Stack

On Wed, Sep 16, 2015 at 11:30 AM, Anne Gentle <annegentle at justwriteclick.com
> wrote:

>
>
> On Wed, Sep 16, 2015 at 9:16 AM, Thierry Carrez <thierry at openstack.org>
> wrote:
>
>> Anne Gentle wrote:
>> > [...]
>> > What are some of the problems with each layer?
>> >
>> > 1. weekly meeting: time zones, global reach, size of cross-project
>> > concerns due to multiple projects being affected, another meeting for
>> > PTLs to attend and pay attention to
>>
>> A lot of PTLs (or liaisons/lieutenants) skip the meeting, or will only
>> attend when they have something to ask. Their time is precious and most
>> of the time the meeting is not relevant for them, so why bother ? You
>> have a few usual suspects attending all of them, but those people are
>> cross-project-aware already so those are not the people that would
>> benefit the most from the meeting
>
>
>> This partial attendance makes the meeting completely useless as a way to
>> disseminate information. It makes the meeting mostly useless as a way to
>> get general approval on cross-project specs.
>>
>> The meeting still is very useful IMHO to have more direct discussions on
>> hot topics. So a ML discussion is flagged for direct discussion on IRC
>> and we have a time slot already booked for that.
>>
> I wanted to add a +1 to the idea of using a tag other than [all] to
highlight cross-project communications.

>
>> > 2. specs: don't seem to get much attention unless they're brought up at
>> > weekly meeting, finding owners for the work needing to be done in a spec
>> > is difficult since each project team has its own priorities
>>
>> Right, it's difficult to get them reviewed, and getting consensus and TC
>> rubberstamp on them is also a bit of a thankless job. Basically you're
>> trying to make sure everyone is OK with what you propose and most people
>> ignore you (and then would be unhappy when they are impacted by the
>> implementation a month later). I don't think that system works well and
>> I'd prefer we change it.
>>
>> > 3. direct communications: decisions from these comms are difficult to
>> > then communicate more widely, it's difficult to get time with busy PTLs
>> > 4. Summits: only happens twice a year, decisions made then need to be
>> > widely communicated
>> >
>> > I'm sure there are more details and problems I'm missing -- feel free to
>> > fill in as needed.
>> >
>> > Lastly, what suggestions do you have for solving problems with any of
>> > these layers?
>>
>> I'm starting to think we need to overhaul the whole concept of
>> cross-project initiatives. The current system where an individual drives
>> a specific spec and goes through all the hoops to expose it to the rest
>> of the community is not really working. The current model doesn't
>> support big overall development cycle goals either, since there is no
>> team to implement those.
>>
>
> Completely agree, this is my observation as well from the service catalog
> improvement work. While the keystone team is crucial, so many other teams
> are affected. And I don't have all the key skills to implement the vision,
> nor do I want to be a spec writer who can't implement, ya know? It's a
> tough one.
>

Hi, would it make sense for the product WG to help write and/or track the
specs?  Apologies, in advance, if our workflow does not fit the needs being
discussed.

We have a defined workflow for how we will be working on user stories
through our process[1] and I wonder if a similar workflow could be built
for cross-project specs.  We are already trying to focus on
multi-release/cross-project user stories[2] but we are doing it from a
market perspective as opposed to tracking items that are cross-project
needs based on the current state.  The process could definitely be expanded
to help coordinate these needs as well.   This will allow an individual to
still be associated with a spec but if the person is unable to finish the
work or needs more help, the team could ask for more resources or let
stakeholders know that there might be a delay.

[1]
https://docs.google.com/presentation/d/1dZBm4cfpSyVlvPLpHSReaQiZ7e8SfgS7VLSbSqoWokw/edit?usp=sharing
[2] https://wiki.openstack.org/wiki/ProductTeam#Objectives

>
>
>>
>> Just brainstorming out loud, maybe we need to have a base team of people
>> committed to drive such initiatives to completion, a team that
>> individuals could leverage when they have a cross-project idea, a team
>> that could define a few cycle goals and actively push them during the
>> cycle.
>>
>
This is very similar to how the Product WG structure is setup as well.  We
have cross-project liaisons (CPLs) that participate in the project team
meetings and also user-story owners who cover the overall goal of
completing the user story.  The user story owner leverages the cross
project liaisons to help with tracking component/project specific
dependencies for implementing the user story but the user story owner is
looking at the overall state of the bigger picture.   Our CPLs work with
multiple user-story owners but the user story owner to user story mapping
is 1:1.

>
>>
> Or, to dig into this further, continue along the lines of the TC specialty
> teams we've set up? We ran out of time a few TC meetings ago to dive into
> solutions here, so I'm glad we can continue the conversation.
>
> I'm sure existing cross-project teams have ideas too, liaisons and the
> like may be matrixed somehow? We'll still need accountability and matching
> skill sets for tasks.
>

> Anne
>
>
>> Maybe cross-project initiatives are too important to be left to the
>> energy of an individual and rely on random weekly meetings to make
>> progress. They might need a clear team to own them.
>>
>> --
>> Thierry Carrez (ttx)
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Anne Gentle
> Rackspace
> Principal Engineer
> www.justwriteclick.com
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Thanks,
Shamail Tahir
t: @ShamailXD
tz: Eastern Time