openstack
/
project-team-guide
Code Issues Proposed changes

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
This commit is contained in:
Thierry Carrez 2017-06-22 13:47:54 +02:00
parent a2a4fb9ebc
commit f4a1671703
6 changed files with 39 additions and 22 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
doc/source/introduction.rst
View File

@ -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/

13
doc/source/open-community.rst
View File

@ -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

26
doc/source/open-source.rst
View File

@ -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

2
doc/source/oslo.rst
View File

@ -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

2
doc/source/project-setup.rst
View File

@ -61,4 +61,4 @@ below.
Python<project-setup/python>
JavaScript<project-setup/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

2
doc/source/testing.rst
View File

@ -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
<http://governance.openstack.org/reference/project-testing-interface.html>`_
<https://governance.openstack.org/tc/reference/project-testing-interface.html>`_
which describes what facilities a project must provide for both
developers and the automated systems to run tests on the project.