a1c444beed
During numerous discussions at the Vancouver 2018 Forum, the topic of discouraging review cultural behaviors came up repeatedly. This has come up before, but never to the point where prior community participants and leaders who took the opportunity to reconnect with the community came into the room and explicitly stated that it was the review culture as to why they left. The common frustration that was repeatedly raised was having to revise patches over and over due to varying nitpicks where negative feedback was left forcing the patch to be updated in order to gain any additional review feedback. We recognize that this is counter productive, and that we need to change our review culture, so we are updating the principles to express the aspects of peer review that we value. Co-Authored-By: Doug Hellmann <doug@doughellmann.com> Change-Id: I3b615784824de2a15a911780fe8c37928f2c453e
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.
|