Open Stack

Hi,

tl;dr
We need everyone agreeing and understanding the "why" behind what we are doing.
A shared language/understanding of the context is an important part of that.
Writing things down, and giving people links to that, really helps.

On 15 May 2016 at 13:07, Chris Dent <cdent+os at anticdent.org> wrote:
> The fundamental problem is that we don't have shared understanding
> and we don't do what is needed to build share understanding. In fact
> we actively work against building it.

+1

> TL;DR: When we are apart we need to write more;
> when we are together we need to talk more but with less purpose.

They happen, but we should recognise the importance of those conversations.

> Most people in the OpenStack don't have that shared understanding
> and without that shared understanding the assumption problem you
> describe compounds. People make a list of goals that they believe
> are mutually shared but they are actually just a list of words for
> which everyone has a different interpretation.
...
> * Developing shared language and share understanding is a prerequisite
>   for
> * Developing shared goals which are a prerequisite for
> * Share actions

This is exactly why in Liberty Nova had a "DevRef Updates" a priority:
http://specs.openstack.org/openstack/nova-specs/priorities/liberty-priorities.html
We created things like this:
http://docs.openstack.org/developer/nova/project_scope.html

We didn't achieve all my aims, but we made some progress, and raised
some awareness of the need. Some of the blog posts (and ML posts)
outside the devref have probably been more successful. Many of those
have been peer reviewed prior to publication. (I think we should bring
the essence of those back into the central docs, where we can.)

On a micro level, the spec process has helped get review and submitter
use the same language. Frequently we used to come away from
discussions with everyone "agreeing" something slightly different. But
that only works in the context of a wider alignment.

> This myth-building happens to some extent already but there is not
> a strong culture in OpenStack of pointing people at the history.
> It's more common as a newbie to rock up in IRC with a question and
> get a brief synchronous answer when it would be better to be pointed
> at a written artifact that provides contextualizing background.

+1
When we have something already, we should totally do that.
Then follow up with a discussion to clarify the doc as required.
If we don't have it written down, its a good pointer towards the need.

> We've become trapped into the idea of using f2f or synchronous time
> for "working out the details of a single spec" because we haven't
> got the shared language that makes talking about details effective.
> If we get the shared language the details become so much easier to
> deal with, in any medium.

Frankly, the best summit and midcycle sessions for me are where we
spend time establish-ing a shared language. Coming out of a session
with a shared understanding of the problem and context, is (almost)
always my key aim.

Now, the problem you correctly mention, is the current conversations
are often additive to three or more years of previous discussions.

In the last few summits, Nova has pushed to provide "pre-reading" for
every summit session. Do we always succeed? No. But if its unclear, we
need folks to ask questions and help us to do better.

>> I think people prefer to use ML a lot and I am not a great fan of the
>> same. It is a multi-cast way of communication and it has assumptions
>> around time, space, intent of the audience & intent to actually read
>> them. Same is for gerrit/etherpad.
>
> I'm one of those people who prefers ML.

Agreed that with a shared language, the ML is more effective.

I do find video discussions are useful to resolve sticking points
between a small number of folks. Its important to create some artifact
to record the debate (and I don't mean publish the video, that doesn't
work).

> IRC meetings are just chaos.
>
> (IRC is good for two things:
>
> * Shooting the breeze and turning strangers into colleagues.
> * Dealing with emergent situations ("the gate's on fire, HALP!").

I think some IRC meeting work, in a standup like way, for those with a
previously established shared context.

> If your participants have somehow managed to achieve some shared
> understanding they can use that understanding when creating and
> discussing goals. When they get together in IRC for a weekly
> catchup and it is time to discuss "how's it going with the frobnitz"
> rather then everyone squirming because everyone has a different idea
> of what the frobnitz is (let alone how to fix it) people, although
> they may not agree on the solution, will at least agree on the
> problem domain so the scope of the discussion and the degree of what
> you're calling "disruption" (and I would call "discomfort") goes down,
> making room, finally, for shared action.

If that says what I think it says, I am +1 that.

Synchronous vs Asynchronous (and in-between), high vs low bandwidth
communication tools all have their place. None of those replace having
curated content for new/returning folks to gain the current shared
context

> The summary: spend more time and energy establishing shared
> understanding and documenting shared language. Do it in a way that
> is inclusive of newcomers. Do it because it is the most important
> part of the work you're doing, it is not overhead.

+1

I hate management speak, but I love the way these issues are described
in this book:
https://www.kenblanchard.com/Store/Books/Gung-Ho!

I attempted to describe the need for this shared context in my (badly
named) talk in Tokyo:
https://www.openstack.org/videos/video/tokyo-1937

Thanks,
John