<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>Nikhil:</div><div>"""<span style="font-size:12.8px">Lately I have been involved in discussions that have resulted in giving</span></div><span style="font-size:12.8px">a wrong idea to the approach I take in operating the (Glance) team(s)."""</span></div><div class="gmail_quote"><span style="font-size:12.8px"><br></span></div><div class="gmail_quote"><span style="font-size:12.8px">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.<br></span><div><br></div><div>Nikhil:</div><div>"""<span style="font-size:12.8px">We are developing something that is usable, operationally friendly and</span></div><span style="font-size:12.8px">that it's easier to contribute & maintain but, many strong influencers</span><br style="font-size:12.8px"><span style="font-size:12.8px">are missing on the most important need for OpenStack -- efficient way of</span><br style="font-size:12.8px"><span style="font-size:12.8px">communication."""</span></div><div class="gmail_quote"><span style="font-size:12.8px"><br></span></div><div class="gmail_quote"><span style="font-size:12.8px">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.</span></div><div class="gmail_quote"><span style="font-size:12.8px"><br></span></div><div class="gmail_quote"><span style="font-size:12.8px">Nikhil:</span></div><div class="gmail_quote"><span style="font-size:12.8px">"""</span><span style="font-size:12.8px">Also, many people like to work on the assumption that all the</span></div><span style="font-size:12.8px">tools of communication are equivalent or useful and there are no</span><br style="font-size:12.8px"><span style="font-size:12.8px">side-effects of using them ever."""</span></div><div class="gmail_extra"><span style="font-size:12.8px">"""</span><span style="font-size:12.8px">I think people prefer to use ML a lot and I am not a great fan of the</span></div><span style="font-size:12.8px">same."""</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">This is great to recognize, now lets work on that and get the expectations right.</span></div><div><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px">Secondary would be the more real time forums, namely IRC and design summits.</span></div><div>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.</div><div><br></div><div>Nikhil:</div><div>"""<span style="font-size:12.8px">Multi-cast medium of communication is more disruptive as it involves a</span></div><span style="font-size:12.8px">possibility of divergence from the topic, strongly polarizing opinions</span><br style="font-size:12.8px"><span style="font-size:12.8px">due to the small possibility of catching of the intent. So, let us use</span><br style="font-size:12.8px"><span style="font-size:12.8px">it 'judiciously' and preferably only as a newspaper."""</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px">* "BLOGGING; Never Before Have So Many People with So Little to Say Said So Much to So Few."</span></div><div><span style="font-size:12.8px">    - Despair, Inc. <a href="http://despair.com/products/blogging">http://despair.com/products/blogging</a></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Nikhil:</span></div><div><span style="font-size:12.8px">"""</span><span style="font-size:12.8px">Though, I think every team needs to be synchronous about their approach</span></div><span style="font-size:12.8px">and not use delayed mechanisms like ML or gerrit."""</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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?</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Chris:</span></div><div>"""<span style="font-size:12.8px">The fundamental problem is that we don't have shared understanding</span></div><span style="font-size:12.8px">and we don't do what is needed to build share understanding."""</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Chris:</span></div><div><span style="font-size:12.8px">"""</span><span style="font-size:12.8px">My experience of most OpenStack communications is that the degree of</span></div><span style="font-size:12.8px">shared understanding on some very fundamental things (e.g. "What are</span><br style="font-size:12.8px"><span style="font-size:12.8px">we building?") is extremely low. It's really not that surprising</span><br style="font-size:12.8px"><span style="font-size:12.8px">that there is discomfort."""</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Chris:</span></div><div><span style="font-size:12.8px">"""</span><span style="font-size:12.8px">people, although</span></div><span style="font-size:12.8px">they may not agree on the solution, will at least agree on the</span><br style="font-size:12.8px"><span style="font-size:12.8px">problem domain so the scope of the discussion and the degree of what</span><br style="font-size:12.8px"><span style="font-size:12.8px">you're calling "disruption" (and I would call "discomfort") goes down,</span><br style="font-size:12.8px"><span style="font-size:12.8px">making room, finally, for shared action."""</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">There are couple of things we could do to fix the above:</span></div><div><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px">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).</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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!</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">- Erno</span></div></div>