openstack/governance
Code Issues Proposed changes

Begin integrating vision feedback and editing for style

Browse Source 
This patch, a followup to Ifde9f19cfa07c62320e2ce09f6d5e803357aa0b4,
attempts to do two main things:

* react to some of the feedback provided on the original document
  and in the related survey and summit sessions

* adjust the writing to be somewhat more structured (work in
  progress) and tighter

Notable changes include:

* adding section headers (current wording stubs for review)

* making room for a preamble which sets the stage for what the
  document is; many original readers did not understand the "this is
  a blog posting from the future" format

* making room for a bullet list of summary

* shrinking, slightly, the constellation section

* Being more consistent throughout about case and using the active
  voice. This is a bit difficult given the future-but-looking-back-
  format. It's not yet perfect but I hope at least improved. The
  change in voice probably has the most significant impact in terms
  of causing a large diff.

* Removing superflous "very" and "really" style words where they
  were superfluous. More of this could be done, but it might remove
  the somewhat folksy tone which appears to be there on purpose.

* Things like "drive-by" having been changed to use phrasing that
  hopefully has less risk of offending.

* Entries which felt too ambiguous or didn't add much value (such as
  the git-bot) have been removed or de-emphasized.

From my standpoint this continue to be a bit too long and too
story-like. It is not yet well suited for being read on the web.
Clearly, early drafts should be story like because that greatly
helps the authors to flesh out their ideas. But as an artifact to be
read in a useful fashion by others, that may be ideal. We probably
want to find a sweet spot in the middle.

This should be considered a work in progress both in terms of the
language and structure and the actual content. Not all feedback has
yet been incorporated.

Change-Id: I7374ccaf1c992cad0f1b1e7a0eacd17f3badd75b
This commit is contained in:
Chris Dent 2017-07-05 12:56:45 +01:00
parent c32b3761a5
commit f3ba38f791
1 changed files with 162 additions and 147 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

309
reference/technical-committee-vision-2019.rst
View File

@ -1,175 +1,190 @@
===================================== =====================================
Technical Committee Vision for 2019 Technical Committee Vision for 2019
===================================== =====================================
It's March of 2019 and we are getting ready for the upcoming Forum at This document was written in June of 2017 as if it were created in
the OpenStack Summit. The OpenStack community has evolved quite a bit March 2019, looking back at what the OpenStack Technical Committee has been
over the last couple of years. Where do we even begin? 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, To help with setting the context of this vision, please review these documents:
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.
Constellations have become the new standard way to start exploring * `Why and How Visioning Works <https://www.zingtrain.com/content/why-and-how-visioning-works>`_
OpenStack. For more advanced users, the project navigator helps * `OpenStack Technical Committee Mission <https://governance.openstack.org/tc/reference/charter.html#mission>`_
connect the dots from constellations into which projects to * `Guiding Principles <https://governance.openstack.org/tc/reference/principles.html>`_
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.
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 The first OpenStack Summit of 2019 is great time to review how the
about using single or minimal components of OpenStack, including using OpenStack community has evolved over the last few years. We've made
Keystone for authenticating services not related to OpenStack at progress on a new way to understand reference architectures, on using
all. Everyone was really thrilled by that as the landscape of individual components of OpenStack on their own, on working with other
technology does not begin and end with OpenStack. This happened communities in the cloud ecosystem, and on encouraging and mentoring
because we started thinking differently about adjacent contributions and leadership from an increasingly diverse community.
Communities. The TC identified OpenStack services that would be of
value in new use cases and scenarios in conjunction with other Navigating with Constellations
communities and ensured that they can be run as projects independent ------------------------------
of others. We have done the heavy lifting that makes it easy to
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 integrate Keystone into projects written in Go, Nodejs, or Java, so
that new projects starting off can easily start with a multi-tenancy that new projects can begin with a multi-tenancy user/project story.
user/project story. It also makes it seamless for users to combine This work also makes it seamless for users to combine services from
services from OpenStack, and all these other communities in their OpenStack and other communities in their composite applications. Users
composite applications. The users love not having to hard code love not having to hard code credentials from different services
credentials from different services throughout their environment. throughout their environment.
We have learned a lot from adjacent communities in the process, and .. TODO(cdent): We need an example going the other direction. A tech
have made some substantial changes to the way we do things based on from an adjacent community that OpenStack has chosen
these collaborations. The TC is proactive in reaching out to to adopt (perhaps even replacing something).
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.
The outreach included both technical and non-technical aspects. Since We have learned a lot from adjacent communities and have made some
the OpenStack ecosystem is mature and has excellent systems and substantial changes to the way we do things. The TC is proactive in
processes in place for dealing with governance, vulnerabilities, reaching out to communities with overlapping interests. This includes
continuous integration infrastructure, leadership development, etc., consumers of OpenStack as well as components which play a critical
the TC shares the best practices with other newly forming communities role in deployment of an OpenStack solution. We have also
to help bootstrap them. On the technical side, the TC worked closely shared some of our hard learned lessons and success stories to help
with leadership teams of the other communities to find opportunities them on their journey. We now have a repeatable system for engaging
to share code as services, libraries, reduce scope and complexity of with new communities that allows us to share some of our past insights
some projects to remove duplicated effort. This has empowered and help where we can while still being respectful of how every
contributors to easily move between OpenStack and other communities community has their own culture and needs. We continuously ask the
and develop synergies to benefit everyone. The TC worked with the groups we have close partnerships with for feedback to ensure
OpenStack Infrastructure, Quality Assurance, and similar teams to make their satisfaction with the partnership. We focus on the quality of
sure there is a common understanding of how to deal with new language partnership, rather than quantity of groups we interact with, so the
ecosystems, new projects that will need continuous integration, appropriate amount of resources can be focused on success. It is a
mirroring needs, and works to expand available resources as well as regular occurrence that TC members are or have been contributors within
ensure that there is no undue impact on limited resources. these other communities.
Reaching out to so many other communities, and sharing lessons between The outreach includes both technical and non-technical aspects. Since
us, really confirmed for all of us how critical diversity is to the the OpenStack ecosystem has mature systems and processes in place for
future of OpenStack. There are so many good ideas out there, and so dealing with governance, vulnerabilities, continuous integration
many people that are motivated to help move the conversation infrastructure, leadership development, etc., the TC is able to share
forward. The diverse community also drives a lot of empathy in our best practices with other newly forming communities to help them to
contributors. It has been much easier to understand and empathize with bootstrap. On the technical side, the TC works closely with leadership
the wide range of challenges and problems people are trying to solve teams of the other communities to find opportunities to remove
with OpenStack when we have so many different perspectives in our duplicated effort. This collaboration has provided opportunities for
community. Diversity, on many axes, is now a key value in OpenStack contributors to move easily between OpenStack and other communities
itself, and we have seen our contributor base get measurably more and develop synergies that benefit everyone. The TC works with the
diverse in each of the last three releases. 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 More than 50% of the contributors to the most recent OpenStack release
identified strongly as an OpenStack user or operator. This has helped identified strongly as an OpenStack user or operator. This has helped
grow different patterns and culture of contributions, that are more different patterns and a different culture of contribution to emerge;
focused on near term needs of the operators in the field. It has also there is more focus on the near term needs of the operators in the
brought much more sympathy to the needs of part time contributors who field. It has also brought more sympathy to the needs of part time
can't complete a perfect patch to get it accepted. A small organic contributors who for whatever reason are unable to see a patch through
team of shepherds have been taking the drive-by contributions and to merging. A small organic team of shepherds have been taking these
working them into the system, either by taking over the patches or by contributions and working them into the system, either by taking over
applying follow-up changes. The new bot that converts github pull the patches or by applying follow-up changes.
requests to gerrit change-sets, instead of discarding them, imported
several patches in each of the last three months.
The TC itself has changed in the process. We now regularly have people The TC itself has changed too. We now regularly have people
from the operator community and user committee both on the TC and 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 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 women and representatives from APAC and European countries. These
changes did not happen overnight, or by accident. We now have very changes did not happen overnight, nor by accident. They are the result
heavy emphasis on mentoring in the community, with multiple different of heavy emphasis on mentoring in the community, with multiple different
efforts underway. There is the new OpenStack Ladder program, inspired 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 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 For members of the community that are already engaged, we have built
into our ladder program a specific mentoring program around into our ladder program a specific mentoring program around
inter-project work. This is not only technical mentoring, but focuses inter-project work. This is not only technical mentoring, but focuses
on the skills needed to interface with multiple communities, and work on the skills needed to interface with multiple communities, and work
to build consensus across sometimes large cultural boundaries. We have 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 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 or more projects. This inter-project work has not only given OpenStack
operator experience, but this spanning of project communities has made a unified user and operator experience, but has made our community
our community feel more whole as well. feel more whole as well.
With more community members having successes in inter-project work, it It is now commonplace for popup teams to form around inter-project
is now commonplace for popup teams to form around these kind of work, often led by members of the mentoring program. They engage with
efforts, often lead by members of the mentoring program. They will key members from different project teams within OpenStack, or projects
engage with key members from different project teams within OpenStack, in other communities, or both. Members of the user and operators
or projects in other communities, or both. Members of the user and and communities are often a part of these popup teams. People find it
operators communities are often a part of these popup teams. People exciting and energizing to dive into such crucial work early in their
find it exciting and energizing to dive into such crucial work early OpenStack engagement. Success breeds success, and as the velocity of
in their OpenStack engagement. Success breeds success, and as the this work has increased we have seen a renewed investment from member
velocity of this work has increased we have seen a renewed investment companies to keep accelerating this work.
from member companies to keep accelerating this work.
Much of the work done by these inter-project teams has come from the Much of the work done by these inter-project teams has come from the
improved feedback loop between user, operators and developers. Indeed improved feedback loop between users, operators and developers. Indeed
this feedback, coupled with the increase in diversity of this feedback, coupled with the increase in diversity of contributions,
contributions, makes it hard to distinguish between users, operators makes the interactions — as well as the contributions — between users,
and developers. One visible success story has been the TC curated Top operators and developers seamless. One visible success story has been
10 hit list. It has brought renewed focus on some of the hard problems the TC curated Top 10 hit list. It has brought renewed focus on some of
we need to go after in the near term. It is now commonplace that key the hard problems we need to address in the near term. It is now
features that identified in the Top 10 hit list get completed in a commonplace that key features that were identified in the Top 10 hit
single cycle. Not only does it easily express some of the most list get completed in a single cycle. Not only does the list easily
important work that we need to get done as a community, but the express some of the most important work that we need to get done as a
process of creating it made us all understand OpenStack that much community, but the process of creating it has made us all understand
more. OpenStack that much more.
When TC members and other community leaders started taking deep dives When community members started taking deep dives into projects to
into projects they normally don’t contribute to, there was a ton of which they don't normally contribute, there was a ton of
enlightenment. Old prejudices took a backseat as we walked a mile in enlightenment. Old prejudices took a backseat as we walked a mile in
each other’s shoes. This new understanding is part of why hierarchical each other’s shoes. This new understanding is part of why hierarchical
quotas are now implemented and working in many services, and are now 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. to have this supported over the next year.
Over the past year, the TC has proudly celebrated the good work done 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 community. It has been particularly satisfying to see the breadth of
talent now involved in the technical leadership of the OpenStack talent now involved in the technical leadership of the OpenStack
community. More companies are investing longer term contributors to 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 delivery to their products and services delivered using OpenStack. We
now have between 50 and 100 contributors with significant commits to now have between 50 and 100 contributors with significant commits to
two or more Projects every release cycle. Importantly, we have two or more Projects every release cycle. Importantly, we have
retained 75% of those contributors over the last three retained 75% of those contributors over the last three releases.
releases. Moreover, 50% of these contributors are part time, yet still Moreover, 50% of these contributors are part time, yet still able to
able to get actively involved in critical inter-project work. And we be actively involved in critical inter-project work. We regularly see
regularly see those folks that leave our community become leaders and those people that leave our community become leaders and mentors in
mentors in other Open Source projects in the ecosystem. We have grown 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 not just OpenStack, but Open Source as a whole, and that is something
we can all be proud of. we can all be proud of.