Write down OpenStack principles
Beyond the Four Opens, the OpenStack community (and the Technical Committee as its direct representation) operates on a lot of unwritten principles, which were transmitted by oral tradition by the elders and appear from time to time as a snippet of wisdom in the middle of a TC meeting. It is more than time for us to document those principles, to make them clearer to everyone and harder to ignore. To give credit where due, the bulk of this document was written by Monty Taylor, with input from a number of other folks including (but not limited to) the list of co-authors below. Change-Id: I0134b0aa9b512ee61fbb908d23e7260ff2491bba Co-Authored-By: Monty Taylor <mordred@inaugust.com> Co-Authored-By: Doug Hellmann <doug@doughellmann.com> Co-Authored-By: John Garbutt <john@johngarbutt.com>
This commit is contained in:
Thierry Carrez
parent
e2d60a26bc
commit
f019d697c6
|
|
@ -7,6 +7,8 @@ Reference documents which need to be revised over time.
|
|||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
opens
|
||||
principles
|
||||
charter
|
||||
projects/index
|
||||
new-projects-requirements
|
||||
|
|
@ -18,5 +20,4 @@ Reference documents which need to be revised over time.
|
|||
tags/index
|
||||
Template for new tags <tag-template>
|
||||
Requirements for previously-used incubation/integration process <incubation-integration-requirements>
|
||||
opens
|
||||
house-rules
|
||||
|
|
|
|||
|
|
@ -0,0 +1,116 @@
|
|||
==================
|
||||
Guiding Principles
|
||||
==================
|
||||
|
||||
OpenStack has a set of guiding principles that are used to inform and shape
|
||||
decisions. These principles are not aspirational. Rather, they form the
|
||||
bedrock upon which the OpenStack community and software are built.
|
||||
|
||||
First and foremost, OpenStack follows :doc:`reference/opens`. All four of
|
||||
them are essential, and most of the principles described in this document
|
||||
derive from them. In their personal interactions, our community members
|
||||
are also bound by the rules described in the
|
||||
`OpenStack Community Code of Conduct
|
||||
<https://www.openstack.org/legal/community-code-of-conduct/>`__.
|
||||
|
||||
One OpenStack
|
||||
-------------
|
||||
|
||||
OpenStack is one community with one common mission, producing one framework
|
||||
of collaborating components. Our organization into separate source code
|
||||
repositories and teams allows contributors to focus on their areas of
|
||||
interest and expertise, but does not make OpenStack a loose collection of
|
||||
disconnected projects.
|
||||
|
||||
OpenStack First, Project Team Second, Company Third
|
||||
---------------------------------------------------
|
||||
|
||||
OpenStack leaders are expected to put the needs of OpenStack first in
|
||||
their decision making, before the needs of any individual project team.
|
||||
They are also expected to put the needs of their project team before the
|
||||
needs of the organization they work for, if any. They can of course
|
||||
represent the needs of their project team or their company, but in case
|
||||
of conflicts of interest, they should be ready to put those needs aside
|
||||
and make the best call for OpenStack as a whole.
|
||||
|
||||
Representative Democracy
|
||||
------------------------
|
||||
|
||||
While we strive to build community consensus around decisions, all decisions
|
||||
are finally made or delegated by people who have been democratically elected.
|
||||
|
||||
One Contributor, One Vote
|
||||
-------------------------
|
||||
|
||||
The voice of the contributor community is essential, and forms the basis
|
||||
of our democracy. A person with a thousand patches in an OpenStack release
|
||||
should not have a voice a thousand times as strong (and writing patches is
|
||||
not the only way to contribute). Efforts to limit the electorate to those
|
||||
who make quantifiable contributions, no matter the form, are intended only
|
||||
to prevent gaming of the system, not as a value judgement on relative worth
|
||||
of the various different forms of community contributions.
|
||||
|
||||
Changes in Leadership are Good
|
||||
------------------------------
|
||||
|
||||
It is important for the long-term health of OpenStack that its democratically
|
||||
elected leaders change over time to remain representative of the body of
|
||||
contributors. OpenStack does not have and does not want any sort of dictator,
|
||||
benevolent or otherwise. Leaders (and other community members) in OpenStack
|
||||
are encouraged to participate in mentoring activities (external or internal
|
||||
to the OpenStack community) to help cultivate the next generation of
|
||||
contributors and leaders. No one should consider their role as permanent.
|
||||
Leaders, specifically, should consider stepping down from their role when
|
||||
they can't fully focus on it anymore, and always ensure a good transition
|
||||
path with their successors.
|
||||
|
||||
OpenStack is Built for our Users
|
||||
--------------------------------
|
||||
|
||||
OpenStack is ultimately built to be deployed and used. We need to factor the
|
||||
needs of our existing and anticipated users (operators but also application
|
||||
developers) when making decisions.
|
||||
|
||||
Empowering Businesses, on a Level Playing Field
|
||||
-----------------------------------------------
|
||||
|
||||
From the beginning, OpenStack has striven to support businesses who build
|
||||
products on or with OpenStack, and help them be successful. However,
|
||||
OpenStack should not empower one business over another, or else our community
|
||||
would not truly be a place where everyone can collaborate. While the needs of
|
||||
the constituent businesses are essential, they must be balanced with each other
|
||||
lest OpenStack decisions unwittingly be made by unelected people behind
|
||||
closed doors.
|
||||
|
||||
OpenStack Primarily Produces Software
|
||||
-------------------------------------
|
||||
|
||||
While the software that OpenStack produces has well defined and documented
|
||||
APIs, the primary output of OpenStack is software, not API definitions.
|
||||
We expect people who say they run "OpenStack" to run the software produced by
|
||||
and in the community, rather than alternative implementations of the API.
|
||||
|
||||
We all should Always Follow the OpenStack Way
|
||||
---------------------------------------------
|
||||
|
||||
No one is outside of the rules. We derive considerable value from the
|
||||
empowerment that everyone in the community enjoys from equal application
|
||||
of our key values, principles, and common processes. If parts of OpenStack
|
||||
exist outside of the rules, everyone suffers. While it can be tempting to
|
||||
circumvent process for expedience, doing so is not scalable from a community
|
||||
perspective. It leads to the subversion of democracy and an abdication of our
|
||||
principles of Open Design and Open Community. Large code changes designed
|
||||
outside of community processes, and decisions made outside of OpenStack
|
||||
governance are generally rejected because they, by definition, did not
|
||||
include the community.
|
||||
|
||||
Participation is Voluntary
|
||||
--------------------------
|
||||
|
||||
The leadership of OpenStack should not need to find itself in a position
|
||||
of enforcing the rules because participation in the OpenStack community is
|
||||
a choice made by its participants in the first place. If you disagree with
|
||||
the principles or processes we follow, we encourage you to either participate
|
||||
in improving them within our community governance rules, or seek a different
|
||||
community that is better aligned with your ideals or opinions.
|
||||
|
||||
Loading…
Reference in New Issue