diff --git a/.zuul.yaml b/.zuul.yaml index e26a4cc..416895a 100644 --- a/.zuul.yaml +++ b/.zuul.yaml @@ -3,6 +3,8 @@ - build-openstack-docs-pti check: jobs: - - tox-linters: - voting: false + - tox-linters + gate: + jobs: + - tox-linters diff --git a/doc/source/introduction.rst b/doc/source/introduction.rst index a83cbdf..0e90ba1 100644 --- a/doc/source/introduction.rst +++ b/doc/source/introduction.rst @@ -6,7 +6,8 @@ Where do the Four Opens originate from? They came from a need to do things differently. Free software started in the 80’s by defining four (initially three) -freedoms [#fourfreedoms]_ that any free software should grant its users. Freedom +freedoms [#fourfreedoms]_ that any free software should grant its +users. Freedom 0 was the freedom to run the program as you wish, for any purpose. Freedom 1 was the freedom to study how the program works, and change it so it does your computing as you wish. Freedom 2 was the freedom to redistribute copies so you @@ -25,7 +26,7 @@ by 2010 most open source projects were actually closed one way or another: their core development may be done behind closed walls, or their governance may be locked down to ensure control by its main sponsor. Sure, their end product was licensed under an open source license, but those were not really community -projects anymore. +projects anymore. The control of a specific party over the code is discouraging contributors to participate: those are seen as free labor and are not on a level playing field diff --git a/doc/source/opencommunity.rst b/doc/source/opencommunity.rst index 406134a..0187cce 100644 --- a/doc/source/opencommunity.rst +++ b/doc/source/opencommunity.rst @@ -26,15 +26,21 @@ and downstream, but communities are complex organisms, and the reality is much more dynamic. It's important to establish common goals and build strong connections between the forces, because operating in silos will dilute the power of the community. Each force affects the others and they have to be -working in harmony to achieve anything. +working in harmony to achieve anything. Open Community defines how to best align these forces through: -- Common mission & goals. - Effective governance & leadership. - Diversity & - Inclusiveness. - Contributor recognition & motivation. - Communication. - - Branding & positioning (example of collaboration across forces, product - definition). - Education & On-boarding. - Marketing & events. - Ambassadors - & meet-ups. - Cross-community collaboration (NIH). +- Common mission & goals. +- Effective governance & leadership. +- Diversity & Inclusiveness. +- Contributor recognition & motivation. +- Communication. +- Branding & positioning (example of collaboration across forces, product + definition). +- Education & On-boarding. +- Marketing & events. +- Ambassadors & meet-ups. +- Cross-community collaboration (NIH). Common Mission & Goals ---------------------- @@ -200,10 +206,10 @@ ultimately realized that we excluded a large portion of the world where Google products were inaccessible/unavailable. Host meetings in way that can be archived and searched so that the -conversations are accessible to all time-zones and participants who do not speak -English as their first language. Internationalization (translation, tool -choices like google docs, time-zones), in general, helps foster a more diverse -group of contributors. +conversations are accessible to all time-zones and participants who do +not speak English as their first language. Internationalization +(translation, tool choices like google docs, time-zones), in general, +helps foster a more diverse group of contributors. Board meetings in particular should be open so that anyone can dial in. Notes/re-cap should be sent out to the community at large via mailing lists diff --git a/doc/source/opendevelopment.rst b/doc/source/opendevelopment.rst index f492533..96c6ce0 100644 --- a/doc/source/opendevelopment.rst +++ b/doc/source/opendevelopment.rst @@ -24,7 +24,8 @@ evaluating a patch can include: not introduce regressions? - Documentation: does a new feature include documentation on what it does and how to properly configure it? -- Purpose: does the code implement a feature identified in the open design process? +- Purpose: does the code implement a feature identified in the open + design process? Automation, like automated unit, integration, and style checking, can go a long way to establishing a baseline standard for new code. Code review by trusted diff --git a/doc/source/opensource.rst b/doc/source/opensource.rst index 52bb806..d677f5c 100644 --- a/doc/source/opensource.rst +++ b/doc/source/opensource.rst @@ -52,12 +52,13 @@ The "Open Source" Principle in Practice "Open Source" begins with the choice of license a community applies to its project. In most cases at the OpenStack Foundation, we use v2.0 of the Apache -License [#apachev2]_. The license meets the requirements of being able to modify and +License [#apachev2]_. The license meets the requirements of being able +to modify and redistribute a work. It includes a number of provisions that also protect end-users by granting copyright and patent licenses to all end users, while limiting liability to the original copyright holder. This patent protection is one of the distinguishing features in comparison to other open source licenses, -like the MIT License. +like the MIT License. In practice, individual and corporate contributors need to understand the consequences of contributing code to an Apache Licensed project, particularly @@ -73,7 +74,7 @@ authorized to submit changes to the project and understands that their contributions will be used in accordance with the license. A CLA, being a stronger document, is also considered a barrier to entry. A DCO, in contrast, lowers the barrier to entry by removing the requirement to consent to a legal -document [#CLAvDCO]_. +document [#CLAvDCO]_. Apache 2.0 is very liberal in allowing companies to modify and use the code in any way they want, and doesn't place requirements to release changes (although