Open Stack

On Fri, Feb 22, 2019 at 4:29 PM Doug Hellmann <doug at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190222/68598766/attachment.html>