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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
