Open Stack

I'm not sure why I'm spending one of these very rare sunny Sunday
afternoons on this but perhaps it's just important enough.

Thanks Nikhil and Chris for such a verbal start for the discussion. I will
at least try to keep my part shorter. I will quote both of your e-mails by
name from which one it came from.

Nikhil:
"""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)."""

At very start, please change your approach and start leading the team
instead of trying to operate it. This is community rather than huge team in
big enterprise and our contributors have different corporational and
cultural backgrounds and reasonings why they are contributing into it, not
organization with resources in PTLs disposal.

Nikhil:
"""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."""

With the community size of OpenStack spanning probably about every timezone
that has land we can communicate how much we ever want and not reach
everybody in time. After all the individual projects are responsible for
the release and providing that something that their mission statement
mandates. We can put all our efforts to communicate being nice, friendly
and easy but if we do not deliver we do not need to do this for long.

Nikhil:
"""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 think people prefer to use ML a lot and I am not a great fan of the
same."""

This is great to recognize, now lets work on that and get the expectations
right.
Community wide the primary mean is the mailing list (and just perhaps
extending to specs and gerrit reviews). You don't like it, I don't like it,
but it's what we have to deal with.
Secondary would be the more real time forums, namely IRC and design summits.
Anything apart from that (yes; hangouts, bluejeans, midcycles are great for
building the team and filing out misunderstandings and disagreements on
individual level) is tertiary and worthless unless used purely to bring the
discussion to the primary media. This is the only way to include the
community asynchronous way without expecting that 2/3 of the timezones
needs to participate at inconvenient or impossible times or find the
funding to travel.

Nikhil:
"""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."""

Seriously? If you want to publish in unidirectional manner, please write a
blog* like everyone else, but don't try to transform our primary
communications to such. Thankfully this opening was already start for right
direction.
* "BLOGGING; Never Before Have So Many People with So Little to Say Said So
Much to So Few."
    - Despair, Inc. http://despair.com/products/blogging

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

10AM IST (UTC +0100) seems to be good time, half an hour every morning
should be fine to get me synced up after I've gone through the pressing
stuff from e-mails and 17:00 IST (UTC +0100) is probably good time for
another to keep us in synchronous. I'm sure the rest of the team is willing
to sacrifice half an hour of their mornings and evenings for same.
Hopefully you can facilitate, or perhaps the synchronous approach is not
that good after all?

Chris:
"""The fundamental problem is that we don't have shared understanding
and we don't do what is needed to build share understanding."""

This seems to be so spot on. We might be appear talking about same thing,
having agreement what we should do and months later realize that we were
not talking about same thing at all and start from the beginning.

Chris:
"""My experience of most OpenStack communications is that the degree of
shared understanding on some very fundamental things (e.g. "What are
we building?") is extremely low. It's really not that surprising
that there is discomfort."""

I'm not sure if you meant that but this issue seems to span across all the
layers. By that I mean that if you ask few persons that question 'What are
we building?' you get different responses regardless if that is component,
project or OpenStack tent level. What I do not know is at which level it
would be the best to start solving. Can people agree what their project or
component is doing if they don't agree on the big picture or is it
impossible to agree on the big picture if they can't agree what they are
doing at the component/project level.

Chris:
"""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."""

One thing that IMO our community is attacking wrong way that increases this
"disruption" or "discomfort" is the current attitude of not tolerating
rejection. We need to grow up and start understand that some things just
will and have to be rejected at the times. It's not helping anyone if the
community talks about some proposals for months and it's not moving to any
direction because the community can't get to an agreement on that. I've
seen two major reasons for viable proposals leaving into this limbo.

First thing leading to viable proposals being on that argument limbo, not
moving anywhere and finally the people proposing them going to do something
else "Because the community is so slow and impossible to deal with" is
time. When we do have backlog of goals or priorities over more that a cycle
and we haven't even agreed on them fully, it's really difficult to justify
committing the time on something else. Obviously when people see something
amazing popping up and perhaps solving some persistent issues the
priorities can and should be changed.

The second is the amount of bikeshedding we do on technical level, which
directly leads to the first. We don't even get to the point when we would
have something one could test because the first proposed implementation
patches already gets people to realize that there is no shared
understanding what we were doing and gets back to the bikeshedding around
the drawing board. When most of this happens either synchronously or even
worse in the small group syncups this is squirrel wheel we never get out as
when these people thinks that everything has been agreed, the next guy
walks in who has not even heard of the latest changes he can't agree with.

There are couple of things we could do to fix the above:
1) Start failing early. If the proposal does not fit to the project
currently lets start rejecting those instead of wasting everyone's time on
that limbo. Being it time constraints or purely technical reasons, being
honest "No we cannot do this now or anytime in close future (within cycle)
because we don't have time/because it does not fit to our current
priorities and might affect them". Personally I think that nothing is worse
than promising someone to work with them to get new feature in and current
cycle+3 it's still not merged nor even agreed when it would happen and just
faints away.
2) Start utilizing more of the feature branches. Let people prove that
something a) can be done and b) can be tested before released. Our current
model makes it really difficult to do any level of trial and error,
specially on our APIs. Put them in the feature branch if there is doubts
about them or it takes more than a cycle to finish, get to work and make it
possible for people to test out before committing it to the release. Good
example of this work IMO is the Images API v2 Image Import Refactoring work
for interoperability. We have been now bikeshedding about it for cycle and
half and nothing has been actually done to show that it fixes the issues
promised.
3) Not be afraid of forking. This is Open Source after all and by our
license there is nothing we can nor should do to prevent it. If some
feature is super important to contributing organization X and we can't
currently facilitate, we actually should encourage them to fork, test if it
was the solution to solve issue / fill the use case and have code + backing
up data when coming back to the community for the next proposal.
4) Be open and asynchronous to get all the key parties possibility to chip
in by the time decision is made (no, IRC logs are not asynchronous
communication).

Lets try to remember that we are Open Source community doing things
together rather than closed source company project with public and
transparent processes and decision making.

I think my "keeping it short" got longer than the two previous guys
together, but thanks for reading and lets be amazing doing amazing things!

- Erno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160515/c2770b80/attachment.html>