From f4a167170300291413144313a7e60e04b34dc348 Mon Sep 17 00:00:00 2001 From: Thierry Carrez Date: Thu, 22 Jun 2017 13:47:54 +0200 Subject: [PATCH] Update guide to match recent changes Mention new resources, like StoryBoard, the Guiding Principles, the Licensing requirements, or the User Committee governance website. relax language around IRC meetings to not make it sound like they are necessary. Update TC governance URLs to match new location. Change-Id: I6bfd920780f07f8452837230db12f897c1272f9d --- doc/source/introduction.rst | 16 +++++++++++++--- doc/source/open-community.rst | 13 +++++++------ doc/source/open-source.rst | 26 ++++++++++++++++---------- doc/source/oslo.rst | 2 +- doc/source/project-setup.rst | 2 +- doc/source/testing.rst | 2 +- 6 files changed, 39 insertions(+), 22 deletions(-) diff --git a/doc/source/introduction.rst b/doc/source/introduction.rst index 8871fbc..af7dbb4 100644 --- a/doc/source/introduction.rst +++ b/doc/source/introduction.rst @@ -34,13 +34,19 @@ The Four Opens The best short definition of "the OpenStack Way" is the four opens as defined in the governance document approved by the Technical -Committee. +Committee: -http://governance.openstack.org/reference/opens.html +https://governance.openstack.org/tc/reference/opens.html + +These were further refined in a set of guiding principles that apply to all +OpenStack projects: + +https://governance.openstack.org/tc/reference/principles.html In the following chapters, we'll further elaborate on those basic principles and explain more precisely what they mean for OpenStack project teams. + A quick history of OpenStack governance ======================================= @@ -75,6 +81,9 @@ The reponsibilities of the Project Policy Board were split between two bodies: * The `Technical Committee`_, which manages the technical matters and has authority over the open source upstream OpenStack Project +The Foundation bylaws also established a third body, the `User Committee`_, +to more accurately reflect the views and needs of the users of OpenStack. + The Technical Committee was originally formed by all the PTLs + five members directly elected by all the contributors. In June 2013, to accommodate the growth in the number of project teams and PTLs, the Technical Committee @@ -83,4 +92,5 @@ renewed every 6 months. .. _OpenStack Foundation: http://www.openstack.org/foundation/ .. _Board of Directors: http://www.openstack.org/foundation/board-of-directors/ -.. _Technical Committee: http://governance.openstack.org/ +.. _Technical Committee: https://governance.openstack.org/tc/ +.. _User Committee: https://governance.openstack.org/uc/ diff --git a/doc/source/open-community.rst b/doc/source/open-community.rst index 7ee296d..2223d99 100644 --- a/doc/source/open-community.rst +++ b/doc/source/open-community.rst @@ -14,8 +14,8 @@ its success and growth in the OpenStack ecosystem. Public Meetings on IRC ====================== -OpenStack projects are required to have team meetings on the Freenode -:term:`IRC` network in one of the publicly logged team meeting +OpenStack projects are required to have their team meetings (if any) on the +Freenode :term:`IRC` network in one of the publicly logged team meeting channels managed by the OpenStack infrastructure team. As part of working in an open community, the logging of meetings allows those who cannot participate at the meeting's designated time to read the logs @@ -83,7 +83,7 @@ Community Support Channels As a project in the OpenStack ecosystem, you will inevitably field requests for support from users of your software. These can come in the following ways: -* Bugs on Launchpad_ +* Bugs on Launchpad_ or StoryBoard_ * Mailing list requests * IRC message requests * ask.openstack.org_ @@ -91,7 +91,7 @@ support from users of your software. These can come in the following ways: A project must be prepared to provide best effort support for these types of requests. Recommended courses of action include: -* Triaging bugs on Launchpad_ at least weekly. +* Triaging bugs (on Launchpad_ or StoryBoard_) at least weekly. * Responding to project queries on the various mailing lists. * Working in-channel on IRC to answer questions. * Looking weekly at ask.openstack.org_ for open queries related to your @@ -190,9 +190,10 @@ defines the rules for the election schedule. Dates are generally based on the release cycle (for PTL elections) and summit dates (for the TC elections). -.. _should be logged: http://governance.openstack.org/reference/irc.html +.. _should be logged: https://governance.openstack.org/tc/reference/irc.html .. _etiquette rules: https://wiki.openstack.org/wiki/MailingListEtiquette .. _Launchpad: https://launchpad.net/openstack +.. _StoryBoard: https://storyboard.openstack.org .. _ask.openstack.org: https://ask.openstack.org/ .. _Technical Committee website: https://governance.openstack.org/tc/ .. _TC office hours: https://governance.openstack.org/tc/#office-hours @@ -205,7 +206,7 @@ release cycle (for PTL elections) and summit dates (for the TC elections). .. _Planet OpenStack: http://planet.openstack.org/ .. _Cross Project Meeting: https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting .. _posted: http://releases.openstack.org -.. _decision: http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html +.. _decision: https://governance.openstack.org/tc/resolutions/20141128-elections-process-for-leaderless-programs.html .. _cross project repository: https://review.openstack.org/#/q/project:openstack/openstack-specs .. _Cross Project Specification Liaison: cross-project.html#cross-project-specification-liaisons .. _adding your blog: https://wiki.openstack.org/wiki/AddingYourBlog diff --git a/doc/source/open-source.rst b/doc/source/open-source.rst index 599de7f..af78949 100644 --- a/doc/source/open-source.rst +++ b/doc/source/open-source.rst @@ -27,11 +27,15 @@ ensure the "fully functional open source" principle is satisfied. Acceptable Licensing ==================== -OpenStack projects must utilize the `Apache License, 2.0`_ for the source code -they produce. This is the license used by all existing OpenStack software. -New projects are required to utilize this license as well, as it's specifically -called out in the OpenStack Foundation bylaws. The Apache License, 2.0, -provides the following benefits: +Licensing requirements are described in the following governance document: + +https://governance.openstack.org/tc/reference/licensing.html + +Generally speaking, OpenStack projects must utilize the `Apache License, 2.0`_ +for the source code they produce. This is the license used by all existing +OpenStack software. New projects are required to utilize this license as well, +as it's specifically called out in the OpenStack Foundation bylaws. The +Apache License, 2.0, provides the following benefits: * OSI approved * GPLv3 compatible @@ -43,10 +47,12 @@ Dependencies and Optional Modules When utilizing third party modules or libraries which are not Apache 2.0 licensed, contributors need to understand how the interaction between the -modules will work and the compatibility of the licenses involved. If there -are doubts or concerns, it is recommended to raise the issue in the -`Technical Committee Meeting`_ to discuss with the Technical Committee how to -proceed. In general, err on the side of caution here. +modules will work and the compatibility of the licenses involved. Please read +the `licensing requirements`_, and if there are any remaining doubts or +concerns, it is recommended to contact the Technical Committee (using the +openstack-dev mailing-list with the [tc] prefix, or on the #openstack-tc IRC +channel) to discuss with the Technical Committee how to proceed. In general, +err on the side of caution here. With regards to dependencies, any third-party libraries or modules need to be vetted in the `global requirements`_. This ensures the added requirement of @@ -54,5 +60,5 @@ including the third party module goes through review and will not conflict with broad cross-project efforts, such as the Python 3 porting effort. .. _Apache License, 2.0: http://www.apache.org/licenses/LICENSE-2.0 -.. _Technical Committee Meeting: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee +.. _licensing requirements: https://governance.openstack.org/tc/reference/licensing.html .. _global requirements: https://git.openstack.org/cgit/openstack/requirements/plain/README.rst diff --git a/doc/source/oslo.rst b/doc/source/oslo.rst index cba399a..24e534d 100644 --- a/doc/source/oslo.rst +++ b/doc/source/oslo.rst @@ -139,7 +139,7 @@ For more details, refer to the Oslo `naming policy spec`_. .. _`Taking the Long View: How the Oslo Program Reduces Technical Debt`: https://www.openstack.org/summit/openstack-paris-summit-2014/session-videos/presentation/taking-the-long-view-how-the-oslo-program-reduces-technical-debt .. _Published Oslo Specs: http://specs.openstack.org/openstack/oslo-specs/ .. _Oslo in the OpenStack wiki: https://wiki.openstack.org/wiki/Oslo -.. _growing set of libraries of Python code: http://governance.openstack.org/reference/projects/oslo.html +.. _growing set of libraries of Python code: https://governance.openstack.org/tc/reference/projects/oslo.html .. _The Oslo Incubator: http://specs.openstack.org/openstack/oslo-specs/specs/policy/incubator.html .. _Oslo Liaison program spec: http://specs.openstack.org/openstack/oslo-specs/specs/policy/liaisons.html .. _CrossProjectLiaisons: https://wiki.openstack.org/wiki/CrossProjectLiaisons diff --git a/doc/source/project-setup.rst b/doc/source/project-setup.rst index b5d153d..beec7d1 100644 --- a/doc/source/project-setup.rst +++ b/doc/source/project-setup.rst @@ -61,4 +61,4 @@ below. Python JavaScript -.. _Consistent Testing Interface: http://governance.openstack.org/reference/project-testing-interface.html +.. _Consistent Testing Interface: https://governance.openstack.org/tc/reference/project-testing-interface.html diff --git a/doc/source/testing.rst b/doc/source/testing.rst index eb79be2..9a8379d 100644 --- a/doc/source/testing.rst +++ b/doc/source/testing.rst @@ -63,7 +63,7 @@ Gerrit code review system under the name *Jenkins*. In order to facilitate projects interacting with the automated test system in a standardized way, the Technical Committee has adopted the `Consistent Testing Interface -`_ +`_ which describes what facilities a project must provide for both developers and the automated systems to run tests on the project.