[openstack-dev] [all] [ptl] Troubleshooting cross-project communications

Anne Gentle annegentle at justwriteclick.com
Wed Sep 16 18:30:03 UTC 2015


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


>
> 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.
>
>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/1a85dcbe/attachment.html>


More information about the OpenStack-dev mailing list