Merge "Begin integrating vision feedback and editing for style"
This commit is contained in:
commit
fe6fe223de
|
@ -1,175 +1,190 @@
|
|||
|
||||
=====================================
|
||||
Technical Committee Vision for 2019
|
||||
=====================================
|
||||
|
||||
It's March of 2019 and we are getting ready for the upcoming Forum at
|
||||
the OpenStack Summit. The OpenStack community has evolved quite a bit
|
||||
over the last couple of years. Where do we even begin?
|
||||
This document was written in June of 2017 as if it were created in
|
||||
March 2019, looking back at what the OpenStack Technical Committee has been
|
||||
involved with over the last few years. The aim is to describe an aspirational
|
||||
yet realistic end goal. It doesn't intend to list out all the tasks needed to
|
||||
reach the end goal, nor does it intend to stop evolving the direction as the
|
||||
enviroment changes between now and 2019.
|
||||
|
||||
We have finally released our 4th Constellation for OpenStack,
|
||||
available at https://orion.openstack.org. This new way of looking at
|
||||
OpenStack reference architectures has successfully given people
|
||||
concrete approaches to get started with OpenStack. Users have been
|
||||
excited that not only do these constellations come with a dedicated
|
||||
website explaining which set of projects make up this constellation,
|
||||
but they have dedicated documentation for each one as well. A custom
|
||||
install guide, an operators guide for the constellation in question, a
|
||||
consolidated API reference for the environment, as well as a
|
||||
validation script based on tempest that helps determine if the
|
||||
environment is fully configured interoperable with other similar
|
||||
constellation deployments completes the picture. Many of the
|
||||
deployment tools are now providing high level macros to install a
|
||||
specific constellations, which gives users a great way to see
|
||||
different configurations of OpenStack without getting lost.
|
||||
To help with setting the context of this vision, please review these documents:
|
||||
|
||||
Constellations have become the new standard way to start exploring
|
||||
OpenStack. For more advanced users, the project navigator helps
|
||||
connect the dots from constellations into which projects to
|
||||
contribute. The old confusion about git namespaces is a thing of the
|
||||
past, given how convenient and user friendly these new views
|
||||
are. Users have definitely reported via the user survey a higher ease
|
||||
of initial understanding of OpenStack. This Constellation based view
|
||||
has helped shape the overall project map. As we have been going
|
||||
through and building these constellations we found several components
|
||||
that did not fit well. We removed components that either overlapped
|
||||
with work in adjacent communities or were not consistent with the
|
||||
OpenStack mission. Other projects were refactored to clarify their
|
||||
scope as they were placed on the map.
|
||||
* `Why and How Visioning Works <https://www.zingtrain.com/content/why-and-how-visioning-works>`_
|
||||
* `OpenStack Technical Committee Mission <https://governance.openstack.org/tc/reference/charter.html#mission>`_
|
||||
* `Guiding Principles <https://governance.openstack.org/tc/reference/principles.html>`_
|
||||
|
||||
While the Constellation view has helped understand some prebuilt
|
||||
patterns with OpenStack that are successful, it has also demonstrated
|
||||
that there is more than one way to remix these components into
|
||||
interesting architectures. Having multiple deeply worked examples has
|
||||
helped clarify that OpenStack components can work well in many
|
||||
configurations and use cases. As a result, new use cases are now
|
||||
easier to envision and has led to the use of individual OpenStack
|
||||
components in other deployments.
|
||||
----
|
||||
|
||||
At the most recent OpenStack summit, three users gave presentations
|
||||
about using single or minimal components of OpenStack, including using
|
||||
Keystone for authenticating services not related to OpenStack at
|
||||
all. Everyone was really thrilled by that as the landscape of
|
||||
technology does not begin and end with OpenStack. This happened
|
||||
because we started thinking differently about adjacent
|
||||
Communities. The TC identified OpenStack services that would be of
|
||||
value in new use cases and scenarios in conjunction with other
|
||||
communities and ensured that they can be run as projects independent
|
||||
of others. We have done the heavy lifting that makes it easy to
|
||||
The first OpenStack Summit of 2019 is great time to review how the
|
||||
OpenStack community has evolved over the last few years. We've made
|
||||
progress on a new way to understand reference architectures, on using
|
||||
individual components of OpenStack on their own, on working with other
|
||||
communities in the cloud ecosystem, and on encouraging and mentoring
|
||||
contributions and leadership from an increasingly diverse community.
|
||||
|
||||
Navigating with Constellations
|
||||
------------------------------
|
||||
|
||||
We have released our 4th Constellation for OpenStack. This new way of
|
||||
looking at OpenStack reference architectures gives people concrete
|
||||
approaches for getting started. Users are excited not only about the
|
||||
dedicated website describing which projects make up each
|
||||
constellation, but also that each has dedicated documentation: A
|
||||
custom install guide, an operator's guide, and a consolidated API
|
||||
reference for the environment. There's also a validation script based
|
||||
on tempest that helps determine if the environment is fully configured
|
||||
and interoperable with other similar deployments. Many of the tools
|
||||
used for OpenStack deployment now provide high level macros to install
|
||||
specific constellations, giving new users a straightforward way to
|
||||
experience different configurations of OpenStack without getting lost.
|
||||
|
||||
In addition to making the initial understanding of OpenStack easier,
|
||||
constellations have also provided other benefits: For users who want
|
||||
to help improve OpenStack, the project navigator connects the dots
|
||||
from constellations to individual projects. Building constellations
|
||||
has helped identify several components that do not fit well. They were
|
||||
removed either because they overlapped with more active work in
|
||||
adjacent communities or because they were not consistent with the
|
||||
OpenStack mission. Having multiple deeply worked examples has
|
||||
clarified that OpenStack components can be remixed in many
|
||||
configurations and use cases. New use cases are easier to envision
|
||||
leading to individual OpenStack components being used in other
|
||||
deployments.
|
||||
|
||||
Working with Adjacent Communities
|
||||
---------------------------------
|
||||
|
||||
At the previous OpenStack summit, three users gave presentations about
|
||||
using single or minimal components of OpenStack, including using
|
||||
Keystone for authenticating services not related to OpenStack.
|
||||
Everyone was thrilled to see that the landscape of technology does not
|
||||
begin and end with OpenStack. The seed of this work was thinking
|
||||
differently about adjacent Communities. The OpenStack community in
|
||||
conjunction with other communities identified services that would be
|
||||
of value in new scenarios and ensured that they can be run
|
||||
independently. We have done the heavy lifting to make it easy to
|
||||
integrate Keystone into projects written in Go, Nodejs, or Java, so
|
||||
that new projects starting off can easily start with a multi-tenancy
|
||||
user/project story. It also makes it seamless for users to combine
|
||||
services from OpenStack, and all these other communities in their
|
||||
composite applications. The users love not having to hard code
|
||||
credentials from different services throughout their environment.
|
||||
that new projects can begin with a multi-tenancy user/project story.
|
||||
This work also makes it seamless for users to combine services from
|
||||
OpenStack and other communities in their composite applications. Users
|
||||
love not having to hard code credentials from different services
|
||||
throughout their environment.
|
||||
|
||||
We have learned a lot from adjacent communities in the process, and
|
||||
have made some substantial changes to the way we do things based on
|
||||
these collaborations. The TC is proactive in reaching out to
|
||||
communities with overlapping interests including consumers of
|
||||
OpenStack as well as components which play a critical role in
|
||||
deployment of a OpenStack Solution. In addition, we have also been
|
||||
able been able to share some of our hard learned lessons and success
|
||||
stories to help them on their journey. We now have a very repeatable
|
||||
system for engaging with new communities, sharing some of our past
|
||||
insights, and helping where we can, while being respectful of how
|
||||
every community has their own culture and needs as they grow. The 5-10
|
||||
groups we have formed close partnerships with are continuously asked
|
||||
for feedback to ensure their satisfaction with our partnership. Our
|
||||
partnerships focus on this quality of partnership, rather than
|
||||
quantity of groups we interact with, so the appropriate amount of
|
||||
resources can be focused on success. It is a regular occurrence that
|
||||
TC members are or have been committers within these other communities.
|
||||
.. TODO(cdent): We need an example going the other direction. A tech
|
||||
from an adjacent community that OpenStack has chosen
|
||||
to adopt (perhaps even replacing something).
|
||||
|
||||
The outreach included both technical and non-technical aspects. Since
|
||||
the OpenStack ecosystem is mature and has excellent systems and
|
||||
processes in place for dealing with governance, vulnerabilities,
|
||||
continuous integration infrastructure, leadership development, etc.,
|
||||
the TC shares the best practices with other newly forming communities
|
||||
to help bootstrap them. On the technical side, the TC worked closely
|
||||
with leadership teams of the other communities to find opportunities
|
||||
to share code as services, libraries, reduce scope and complexity of
|
||||
some projects to remove duplicated effort. This has empowered
|
||||
contributors to easily move between OpenStack and other communities
|
||||
and develop synergies to benefit everyone. The TC worked with the
|
||||
OpenStack Infrastructure, Quality Assurance, and similar teams to make
|
||||
sure there is a common understanding of how to deal with new language
|
||||
ecosystems, new projects that will need continuous integration,
|
||||
mirroring needs, and works to expand available resources as well as
|
||||
ensure that there is no undue impact on limited resources.
|
||||
We have learned a lot from adjacent communities and have made some
|
||||
substantial changes to the way we do things. The TC is proactive in
|
||||
reaching out to communities with overlapping interests. This includes
|
||||
consumers of OpenStack as well as components which play a critical
|
||||
role in deployment of an OpenStack solution. We have also
|
||||
shared some of our hard learned lessons and success stories to help
|
||||
them on their journey. We now have a repeatable system for engaging
|
||||
with new communities that allows us to share some of our past insights
|
||||
and help where we can while still being respectful of how every
|
||||
community has their own culture and needs. We continuously ask the
|
||||
groups we have close partnerships with for feedback to ensure
|
||||
their satisfaction with the partnership. We focus on the quality of
|
||||
partnership, rather than quantity of groups we interact with, so the
|
||||
appropriate amount of resources can be focused on success. It is a
|
||||
regular occurrence that TC members are or have been contributors within
|
||||
these other communities.
|
||||
|
||||
Reaching out to so many other communities, and sharing lessons between
|
||||
us, really confirmed for all of us how critical diversity is to the
|
||||
future of OpenStack. There are so many good ideas out there, and so
|
||||
many people that are motivated to help move the conversation
|
||||
forward. The diverse community also drives a lot of empathy in our
|
||||
contributors. It has been much easier to understand and empathize with
|
||||
the wide range of challenges and problems people are trying to solve
|
||||
with OpenStack when we have so many different perspectives in our
|
||||
community. Diversity, on many axes, is now a key value in OpenStack
|
||||
itself, and we have seen our contributor base get measurably more
|
||||
diverse in each of the last three releases.
|
||||
The outreach includes both technical and non-technical aspects. Since
|
||||
the OpenStack ecosystem has mature systems and processes in place for
|
||||
dealing with governance, vulnerabilities, continuous integration
|
||||
infrastructure, leadership development, etc., the TC is able to share
|
||||
best practices with other newly forming communities to help them to
|
||||
bootstrap. On the technical side, the TC works closely with leadership
|
||||
teams of the other communities to find opportunities to remove
|
||||
duplicated effort. This collaboration has provided opportunities for
|
||||
contributors to move easily between OpenStack and other communities
|
||||
and develop synergies that benefit everyone. The TC works with the
|
||||
OpenStack Infrastructure, Quality Assurance, and similar teams from
|
||||
other communities to make sure there is a common understanding of how
|
||||
to deal with new language ecosystems, new projects that will need
|
||||
continuous integration, and works to expand available resources as
|
||||
well as ensure that there is no undue impact on limited resources.
|
||||
|
||||
Embracing Community Diversity
|
||||
-----------------------------
|
||||
|
||||
Reaching out to other communities has confirmed how critical diversity
|
||||
is to the future of OpenStack. There are so many good ideas, and so
|
||||
many people that are motivated to help. A diverse community drives a
|
||||
lot of empathy in our contributors. It is much easier to
|
||||
understand and empathize with the wide range of challenges and
|
||||
problems people are trying to solve with OpenStack when there are
|
||||
many different perspectives in our community. Diversity, on many axes,
|
||||
is now a key value in OpenStack itself, and we have seen our
|
||||
contributor base get measurably more diverse in each of the last three
|
||||
releases.
|
||||
|
||||
More than 50% of the contributors to the most recent OpenStack release
|
||||
identified strongly as an OpenStack user or operator. This has helped
|
||||
grow different patterns and culture of contributions, that are more
|
||||
focused on near term needs of the operators in the field. It has also
|
||||
brought much more sympathy to the needs of part time contributors who
|
||||
can't complete a perfect patch to get it accepted. A small organic
|
||||
team of shepherds have been taking the drive-by contributions and
|
||||
working them into the system, either by taking over the patches or by
|
||||
applying follow-up changes. The new bot that converts github pull
|
||||
requests to gerrit change-sets, instead of discarding them, imported
|
||||
several patches in each of the last three months.
|
||||
different patterns and a different culture of contribution to emerge;
|
||||
there is more focus on the near term needs of the operators in the
|
||||
field. It has also brought more sympathy to the needs of part time
|
||||
contributors who for whatever reason are unable to see a patch through
|
||||
to merging. A small organic team of shepherds have been taking these
|
||||
contributions and working them into the system, either by taking over
|
||||
the patches or by applying follow-up changes.
|
||||
|
||||
The TC itself has changed in the process. We now regularly have people
|
||||
from the operator community and user committee both on the TC and
|
||||
The TC itself has changed too. We now regularly have people
|
||||
from the operator community and user committee on the TC and also
|
||||
assisting with many of the TC initiated efforts. The TC now looks much
|
||||
more like our contributor base. The TC membership now includes several
|
||||
more like our contributor base. The TC membership includes several
|
||||
women and representatives from APAC and European countries. These
|
||||
changes did not happen overnight, or by accident. We now have very
|
||||
heavy emphasis on mentoring in the community, with multiple different
|
||||
changes did not happen overnight, nor by accident. They are the result
|
||||
of heavy emphasis on mentoring in the community, with multiple different
|
||||
efforts underway. There is the new OpenStack Ladder program, inspired
|
||||
by the Drupal Ladder program, has aimed to bring more traditional
|
||||
by the Drupal Ladder program, which aims to bring more
|
||||
users and operators into the contributor space and ensure that they
|
||||
don’t feel overwhelmed getting their first patch in.
|
||||
don’t feel overwhelmed by our contribution processes.
|
||||
|
||||
Growing New Leaders
|
||||
-------------------
|
||||
|
||||
For members of the community that are already engaged, we have built
|
||||
into our ladder program a specific mentoring program around
|
||||
inter-project work. This is not only technical mentoring, but focuses
|
||||
on the skills needed to interface with multiple communities, and work
|
||||
to build consensus across sometimes large cultural boundaries. We have
|
||||
10 mentors and over 50 participants in this program, who are spending
|
||||
10 mentors and over 50 participants in this program who are spending
|
||||
more than 40% of their OpenStack time focused on efforts spanning two
|
||||
or more projects. This has not only given OpenStack a unified user and
|
||||
operator experience, but this spanning of project communities has made
|
||||
our community feel more whole as well.
|
||||
or more projects. This inter-project work has not only given OpenStack
|
||||
a unified user and operator experience, but has made our community
|
||||
feel more whole as well.
|
||||
|
||||
With more community members having successes in inter-project work, it
|
||||
is now commonplace for popup teams to form around these kind of
|
||||
efforts, often lead by members of the mentoring program. They will
|
||||
engage with key members from different project teams within OpenStack,
|
||||
or projects in other communities, or both. Members of the user and and
|
||||
operators communities are often a part of these popup teams. People
|
||||
find it exciting and energizing to dive into such crucial work early
|
||||
in their OpenStack engagement. Success breeds success, and as the
|
||||
velocity of this work has increased we have seen a renewed investment
|
||||
from member companies to keep accelerating this work.
|
||||
It is now commonplace for popup teams to form around inter-project
|
||||
work, often led by members of the mentoring program. They engage with
|
||||
key members from different project teams within OpenStack, or projects
|
||||
in other communities, or both. Members of the user and operators
|
||||
communities are often a part of these popup teams. People find it
|
||||
exciting and energizing to dive into such crucial work early in their
|
||||
OpenStack engagement. Success breeds success, and as the velocity of
|
||||
this work has increased we have seen a renewed investment from member
|
||||
companies to keep accelerating this work.
|
||||
|
||||
Much of the work done by these inter-project teams has come from the
|
||||
improved feedback loop between user, operators and developers. Indeed
|
||||
this feedback, coupled with the increase in diversity of
|
||||
contributions, makes it hard to distinguish between users, operators
|
||||
and developers. One visible success story has been the TC curated Top
|
||||
10 hit list. It has brought renewed focus on some of the hard problems
|
||||
we need to go after in the near term. It is now commonplace that key
|
||||
features that identified in the Top 10 hit list get completed in a
|
||||
single cycle. Not only does it easily express some of the most
|
||||
important work that we need to get done as a community, but the
|
||||
process of creating it made us all understand OpenStack that much
|
||||
more.
|
||||
improved feedback loop between users, operators and developers. Indeed
|
||||
this feedback, coupled with the increase in diversity of contributions,
|
||||
makes the interactions — as well as the contributions — between users,
|
||||
operators and developers seamless. One visible success story has been
|
||||
the TC curated Top 10 hit list. It has brought renewed focus on some of
|
||||
the hard problems we need to address in the near term. It is now
|
||||
commonplace that key features that were identified in the Top 10 hit
|
||||
list get completed in a single cycle. Not only does the list easily
|
||||
express some of the most important work that we need to get done as a
|
||||
community, but the process of creating it has made us all understand
|
||||
OpenStack that much more.
|
||||
|
||||
When TC members and other community leaders started taking deep dives
|
||||
into projects they normally don’t contribute to, there was a ton of
|
||||
When community members started taking deep dives into projects to
|
||||
which they don't normally contribute, there was a ton of
|
||||
enlightenment. Old prejudices took a backseat as we walked a mile in
|
||||
each other’s shoes. This new understanding is part of why hierarchical
|
||||
quotas are now implemented and working in many services, and are now
|
||||
|
@ -178,7 +193,7 @@ as well as a number of non OpenStack projects in adjacent communities
|
|||
to have this supported over the next year.
|
||||
|
||||
Over the past year, the TC has proudly celebrated the good work done
|
||||
by those who stepped up to lead and work on crucial work in the
|
||||
by those who stepped up to lead and work on crucial needs in the
|
||||
community. It has been particularly satisfying to see the breadth of
|
||||
talent now involved in the technical leadership of the OpenStack
|
||||
community. More companies are investing longer term contributors to
|
||||
|
@ -186,10 +201,10 @@ the OpenStack project, because they can see a clearer path for value
|
|||
delivery to their products and services delivered using OpenStack. We
|
||||
now have between 50 and 100 contributors with significant commits to
|
||||
two or more Projects every release cycle. Importantly, we have
|
||||
retained 75% of those contributors over the last three
|
||||
releases. Moreover, 50% of these contributors are part time, yet still
|
||||
able to get actively involved in critical inter-project work. And we
|
||||
regularly see those folks that leave our community become leaders and
|
||||
mentors in other Open Source projects in the ecosystem. We have grown
|
||||
retained 75% of those contributors over the last three releases.
|
||||
Moreover, 50% of these contributors are part time, yet still able to
|
||||
be actively involved in critical inter-project work. We regularly see
|
||||
those people that leave our community become leaders and mentors in
|
||||
other Open Source projects in the ecosystem. We have helped to improve
|
||||
not just OpenStack, but Open Source as a whole, and that is something
|
||||
we can all be proud of.
|
||||
|
|
Loading…
Reference in New Issue