[tc][election] candidate question: managing change
We are consistently presented with the challenges of trying to convince our large community to change direction, collaborate across team boundaries, and work on features that require integration of several services. Other threads with candidate questions include discussions of some significant technical changes people would like to see in OpenStack's implementation. Taking one of those ideas, or one of your own idea, as inspiration, consider how you would make the change happen if it was your responsibility to do so. Which change management approaches that we have used unsuccessfully in the past did you expect to see work? Why do you think they failed? Which would you like to try again? How would you do things differently? What new suggestions do you have for addressing this recurring challenge? -- Doug
On Fri, Feb 22, 2019 at 4:29 PM Doug Hellmann <doug@doughellmann.com> wrote:
We are consistently presented with the challenges of trying to convince our large community to change direction, collaborate across team boundaries, and work on features that require integration of several services. Other threads with candidate questions include discussions of some significant technical changes people would like to see in OpenStack's implementation. Taking one of those ideas, or one of your own idea, as inspiration, consider how you would make the change happen if it was your responsibility to do so.
Which change management approaches that we have used unsuccessfully in the past did you expect to see work? Why do you think they failed?
One of the ideas that we tested in the past which I was expecting to succeed was the Architecture WG [1]. It was a very interesting approach to see some experts discussing about common pitfalls and see what we could change, but I personnally feel we felt short in terms of deliverables because those discussions weren't really engaged with the corresponding project teams they were impacting. On the other hand, another WG, the API WG (now a SIG) is a great example of success because inputs were directly coming from contributors coming from different projects and seeing common patterns. I can also recall a few discussions we had at Summits (and later Forum) that were promising but did lack of resources for acting on changes. To summarize my thoughts I already said earlier, nothing can happen if you can't have contributors that are familiar with the respective projects that are impacted and that can dedicate time for it (meaning you also need to convince your respective managements of the great benefits it can be). Which would you like to try again? How would you do things differently?
There a couple of things I'd get things done. Say at least, OSC supporting projects microversions at their latest. Also, I'd like to see most of the projects supporting upgrades and follow the old Design Tenets we agreed on a couple of years before. How to make this work ? Well, no magic bullet : 1/ make sure that we can get projects sign-off on any initiative (for example a TC goal) and make sure you have a champion on each project that is reasonably expert on this project to address the need. 2/ have the SIGs/WGs providing us feedback (like Public WG tries to achieve) and make sure we can have resources matching those feature/bugfix requests. 3/ accept the fact that an architectural redesign can span multiple cycles and ensure that the change is itself iterative with no upgrade impact. What new suggestions do you have for addressing this recurring
challenge?
We currently address at the PTGs cross-project talks in a 1:1 fashion (for example Nova-Cinder). We also have Forum sessions that span multiple projects impact. Now that the PTG directly follows the Forum, it would be a good idea to make sure that ideas that pop up at the Forum are actually translated in real PTG discussions for each service. Yeah, we'll work 6 days and it's going to be stressful, but let's take the opportunity for focusing on real actionable items by having 6 days for it. -Sylvain [1] https://github.com/openstack/arch-wg
-- Doug
On Fri, Feb 22, 2019 at 10:29 AM Doug Hellmann <doug@doughellmann.com> wrote:
We are consistently presented with the challenges of trying to convince our large community to change direction, collaborate across team boundaries, and work on features that require integration of several services. Other threads with candidate questions include discussions of some significant technical changes people would like to see in OpenStack's implementation. Taking one of those ideas, or one of your own idea, as inspiration, consider how you would make the change happen if it was your responsibility to do so.
Which change management approaches that we have used unsuccessfully in the past did you expect to see work? Why do you think they failed?
I think there's two classes of approaches we've taken in the past: groups of OpenStack developers with time dedicated to making the change, and everything else. Guess which one worked? Whether we like it or not, this is a community of doers. We've seen lots of working groups with good ideas talk and talk, and while they may be able to convince people that their ideas are good, nothing gets done about them. One other thing that I've noticed with larger changes, or changes that are necessary to scale OpenStack, is that we often lack data or proper resources to prove that a change helps things. This is improving with companies like CERN or Vexxhost running closer to master and being able to deploy/test changes easily at a reasonable scale, but still could be better.
Which would you like to try again? How would you do things differently?
What new suggestions do you have for addressing this recurring challenge?
For these large changes, what we really need is a group of people with the time and resources to accomplish it. Finding that can be difficult. I would like to try something similar to the "help wanted" list for large cross-project changes that we want to see happen. Things like "remove rabbit" or "proper pub-sub for everything" might go on that list (these are examples, please don't look too hard into it). Maybe we need some number of +1s from operators to get a thing on this list. From there, we can get a small group to gather data and propose solutions. The next step is to propose and measure POCs of those solutions, but we'll probably need more people/resources for that. The TC/group can work together on messaging calls for help to companies that have these problems, and hopefully get a group of developers that can push forward and make things happen. AIUI, the "help wanted" list hasn't been very successful in getting contributors for those tasks. I think this proposal has a better chance of succeeding as it would be solving needs present in all/most production clouds. The things on the help needed list aren't pain points for many deployed clouds, but fixing large cross-project problems would be. I do realize it's hard to convince businesses to throw more money at OpenStack these days, so this might not work at all. But it's the best idea I have at the moment. :) // jim
Doug Hellmann wrote:
We are consistently presented with the challenges of trying to convince our large community to change direction, collaborate across team boundaries, and work on features that require integration of several services. Other threads with candidate questions include discussions of some significant technical changes people would like to see in OpenStack's implementation. Taking one of those ideas, or one of your own idea, as inspiration, consider how you would make the change happen if it was your responsibility to do so.
Which change management approaches that we have used unsuccessfully in the past did you expect to see work? Why do you think they failed?
Which would you like to try again? How would you do things differently?
What new suggestions do you have for addressing this recurring challenge?
I think it takes three ingredients: some individual(s) leading the change, over-communication, and leadership. As other mentioned we won't go anywhere if there is nobody signed up to drive the work. Cross-project work is going orthogonal to our organizational structure, so it requires extra work (something we should continue to fix, but that's another topic). Without someone committed to drive that against all odds, it just won't happen by fiat. You also need to over-communicate: in an open source community, people are often more annoyed at feeling excluded from the decision, than at the decision itself. Finally you need a leadership group to say that this large goal is desirable for the group -- that is where the TC comes in, and I would say we need to do more of it. -- Thierry Carrez (ttx)
participants (4)
-
Doug Hellmann
-
Jim Rollenhagen
-
Sylvain Bauza
-
Thierry Carrez