Open Stack

Hi all,


Lately I have been involved in discussions that have resulted in giving
a wrong idea to the approach I take in operating the (Glance) team(s).
While my approach is consistency, coherency and agility in getting
things done (especially including the short, mid as well as long term
plans), it appears that it wasn't something evident. So, I have decided
to write this email so that I can collectively gather feedback and share
my thoughts on the right(eous) approach.


My experience has been that OpenStack is relatively slow. In fact the
feedback I get from people who are secondary (short span contributors)
is that it's very slow. There's a genuine reason for that and it's not
as simple as you are an Open Source/Community project or that people are
unreasonable or that there's lot of bike-shedding, etc.


We are developing something that is usable, operationally friendly and
that it's easier to contribute & maintain but, many strong influencers
are missing on the most important need for OpenStack -- efficient way of
communication. I think we have the tools and right approach on paper and
we've mandated it in the charter too, but that's not enough to operate
things. Also, many people like to work on the assumption that all the
tools of communication are equivalent or useful and there are no
side-effects of using them ever. I strongly disagree. Please find the
reason below:


Let me start from scratch:-


* What is code really?

Code is nothing but a way to communicate your decisions. These decisions
(if, then, else, while, etc.) are nothing but a way to consistently
produce a repeatable output using a machine.  (
https://en.wikipedia.org/wiki/Turing_machine )


* If it's that simple, why is there even a problem?

Decisions when taken in tandem or in parallel can result into a more
complex phenomenon that is not perceptibly evident. That results into
assumptions.


* So, what can be the blocker?

Nothing, but working with these assumptions is really the blocker. That
is exactly why many people in their feedback say we have a "people
problem" in OpenStack. But it's not really the people problem, it is the
assumption problem.

Assumptions are very very bad:

With 'n' problems in a domain and 'm' people working on all those
problems, individually, we have the assumption problem of the order of
O((m*e)^n) where you can think of 'e' as the convergence factor.
Convergence factor being the ability of a group to come to an agreement
of the order of 'agree to agree', 'agree to disagree' (add percentages
to each for more granularity). There is also another assumption (for the
convergence factor) that everyone wants to work in the best interest of
solving the problems in that domain.


* How do I attempt to solve this situation?

I think the first and foremost step is understanding the 'intent' behind
every step -- whether it is a proposal, code, email, etc.

Another important step is to reduce the communication gap -- be it be
meetings, emails, chats, etc. I think the distinguishing factor of each
of these modes of communication should be taken place while
communicating. For example, the process of communication involves ->
intent, thought, ability to communicate, language barriers/restrictions
by the speaker and for the audience it is the other way around ->
language barrier/restrictions, ability to comprehend, internalize (give
it a shape in your thoughts) and then catch the intent. This is a long
process behind each and every step of the communication whether one
sentence or if it's a long review. So, when the intent is important to
communicate we need to use the medium of communication that is most
suitable to communicate the intent, in case of recommended tools it is
irc on regular basis and otherwise they are meetups. We sometimes use
video/audio conf calls etc. High bandwidth communication is extremely
important to increase the convergence factor and solve the problem.
Let's start using them more and more. Please.

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.

Same applies to the broadcast media too but to a smaller extent as that
content is static and focuses on one thing.

Multi-cast medium of communication is more disruptive as it involves a
possibility of divergence from the topic, strongly polarizing opinions
due to the small possibility of catching of the intent. So, let us use
it 'judiciously' and preferably only as a newspaper.

Another step is to arrange/show-up in meetings, yes this is tedious but
extremely vital. This is the place where you can actually determine if
the convergence factor is more or less. I find that a lot of people take
meetings lightly and their approach isn't establishing a deterministic
behavior in the team. Many times, it becomes a disruptive behavior and
the convergence decreases significantly.

I have always been persistent of mid-cycles as they have helped Glance
team (whoever present) to come to a state of agreeing to agree or at
least agreeing to disagree. Both of which are enough to remain 'unstuck'
and focus on getting things done.

Team bonding, one to one feedback etc. processes are adopted as well.
But OpenStack is one team and you can potentially have a significantly
high dynamism in the flexibility of the team so all that is relatively
less important.

This cycle I am experimenting with the focus approach (thanks to Doug
for leading a good example to [release] tag). It is my anticipation that
focusing on the things per week will get people to have more synchronous
communication and less of loss of context.

Though, I think every team needs to be synchronous about their approach
and not use delayed mechanisms like ML or gerrit.



Another important point I wish to raise:

* I find it is very important for people who actually have a strong say
in things to focus less on code or even individual reviews and focus
more on awareness, collaboration and establishing convergence factor.
Leave the nitty gritty details to those who have more bandwidth in hand
for it.

* Let's abolish statistical evaluation to all things or to the very
least make them less important when it comes to the contribution. It
results into a bad experience of lack of focus, loss of context in
different problems and doesn't really show the real contribution someone
is giving to the problem solving. We are all adults, we do not need
teachers (even if it's a computer) to give us grades.

* I think if someone has a very strong say then they need to keep a
(near to) synchronous communication to the development process. We need
to keep the context, keep our convergence intact and move forward with a
common understanding. Otherwise it is VERY disruptive for someone
investing their time, money, energy and interest in OpenStack.

* Also, one very important thing that I keep hearing: "I do not like
that" without any other information, as an argument to disregard
technical proposals. I think it is very disruptive and irrational way to
express arguments. We are not buying flowers in OpenStack, we need to
keep rationality in check when we express our opinions. It reduces
convergence factor and increases dubiety among the developers &
reviewers. Then we have a ecosystem where people do not understand why
we do things the way we do it. We should not stop businesses just
because someone doesn't like something, please no. Lack of rationale can
actually do that.


I think the most important thing is to have belief on our practices. For
that we need to enforce our standards and ensure people follow it. Once
we have more strictness on less disruption, we will have more confidence
in moving forward faster. We only have a governance today that is merely
a guideline (Constitution), what we really need is a judiciary.



Rest of the discussion, I leave upto you -- whether you think this is
important or you don't. At least, I will have a good night sleep
considering that I raised some serious concerns!



Thank you for reading,

Yours sincerely,

-- 

Nikhil Komawar