Open Stack

Erno,

TBH, you clearly haven't taken the time to understand what I meant to
say here. Clearly, thus self-justifying my email about ML discussions.
Hence, I do not want to spend too much time writing a response. There
are a few things that struck, so comments inline. Also, I do not want to
comment on your response to Chris' feedback -- his feedback is something
I need more time to internalize.


On 5/15/16 12:45 PM, Erno Kuvaja wrote:
> 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.
>

Firstly, here's a definition of leadership from a _wiki_ like page (
http://www.businessdictionary.com/definition/leadership.html ) see point
# 4 under the involvement. Think about it more before commenting.

Secondly, this email is not about leadership, this is about
communication which is the most essential part of operations. If you did
not get that part, I have no words.

Since you agree this is a community, balance in the ecosystem is of
prime importance. The way you maintain that is through operating it.
Think about it more, and more, and more.

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

You haven't understood the bottom line here. Read my comments on the
intent.

> 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
>
>
> __________________________________________________________________________
> 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,
Nikhil