168 lines
8.1 KiB
ReStructuredText
168 lines
8.1 KiB
ReStructuredText
==================
|
|
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:`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 is split into separate source
|
|
code repositories and teams allowing contributors to focus on their areas of
|
|
interest and expertise, but does not make OpenStack a loose collection of
|
|
disconnected projects.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
Contribution Is Our Currency
|
|
----------------------------
|
|
|
|
Change happens in OpenStack because anyone in the community can identify an
|
|
issue and volunteer to do the necessary work. Contribution is the mechanism
|
|
of change and how trust is built between community members. Though elected
|
|
leadership exists, that leadership is not solely responsible for change.
|
|
The entire OpenStack community is empowered to identify problems and, where
|
|
possible, assemble the teams to resolve them.
|
|
|
|
We Value Constructive Peer Review
|
|
---------------------------------
|
|
|
|
Peer review is a fundamental part of our culture. Reviewing submissions of
|
|
code and documentation helps us find mistakes and become better programmers
|
|
or writers. Peer review helps us build trust among team members and gives
|
|
us an opportunity to teach each other about different parts of our software,
|
|
CI system, and processes. Without the goodwill of contributors and reviewers,
|
|
we would have no community.
|
|
|
|
We want review comments to be constructive so that the review process fulfills
|
|
its purpose. We do not want reviews to be used to block contributions based on
|
|
minor issues, often called "nits". The focus should always be on incremental
|
|
improvement of the system as a whole, rather than ensuring each individual
|
|
change is perfect.
|
|
|
|
We encourage reviewers who find minor aspects of a change they feel need to
|
|
be changed, to engage the author in discussion versus downvoting, and
|
|
collaborate on how best to move the change forward. Often this may result
|
|
in a follow-up change, or revising the change under review.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
OpenStack Leaders Exist to Serve Their Community
|
|
------------------------------------------------
|
|
|
|
OpenStack leaders hold their positions only in order to serve the people
|
|
they lead. The TC only exists to serve the technical community. PTLs
|
|
exist to serve the contributors and users of their projects.
|
|
|
|
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.
|
|
|
|
We value clear, friendly, and open communication
|
|
------------------------------------------------
|
|
|
|
OpenStack is a geographically distributed community, with members from different
|
|
cultures whose first language may not be English. Both of those characteristics
|
|
can make communication more difficult and lead to misunderstandings, but we
|
|
encourage everyone to consciously work to overcome that challenge through careful
|
|
and constructive writing and by looking for positive interpretations of unclear
|
|
messages. Communicating clearly improves our ability to collaborate to solve
|
|
technical challenges more effectively.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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, you may of course seek a different
|
|
community that is better aligned with your ideals or opinions. However, if
|
|
you are committed to the mission of OpenStack and our Four Open ideals, we
|
|
encourage you to contribute to OpenStack and participate in improving the
|
|
OpenStack processes and the documenting of our principles from within our
|
|
community according to our rules of governance.
|