Document the role of the TC
There are a lot of misconceptions around what the role of the Technical Committee is in OpenStack governance. Create a living document to clarify that. Change-Id: I4700ce494bb2f1158e56dfb23110db219d5e2dfb
This commit is contained in:
@@ -13,6 +13,7 @@ Reference documents which need to be revised over time.
|
|||||||
projects/index
|
projects/index
|
||||||
technical-vision
|
technical-vision
|
||||||
help-most-needed
|
help-most-needed
|
||||||
|
role-of-the-tc
|
||||||
new-projects-requirements
|
new-projects-requirements
|
||||||
new-language-requirements
|
new-language-requirements
|
||||||
licensing
|
licensing
|
||||||
|
|||||||
106
reference/role-of-the-tc.rst
Normal file
106
reference/role-of-the-tc.rst
Normal file
@@ -0,0 +1,106 @@
|
|||||||
|
=========================================
|
||||||
|
Role of the OpenStack Technical Committee
|
||||||
|
=========================================
|
||||||
|
|
||||||
|
The OpenStack Technical Committee ("TC") is chartered under the
|
||||||
|
`OpenStack Foundation bylaws`_ (section 4.13) with the task of managing
|
||||||
|
"technical matters relating to the OpenStack Project". Its first and foremost
|
||||||
|
role is therefore to define the technical governance of the OpenStack
|
||||||
|
project. The current model uses a two-level structure (with project
|
||||||
|
teams responsible for sets of git repositories or specific tasks,
|
||||||
|
electing their own leadership) which means that the TC is not directly
|
||||||
|
in charge of organizing day-to-day work. OpenStack being an open
|
||||||
|
collaboration with volunteers, the TC also does not command development
|
||||||
|
resources that can be applied to priorities or to meet certain deadlines.
|
||||||
|
|
||||||
|
So what is the role of the TC under the current OpenStack technical
|
||||||
|
governance model? This living document aims to answer that question.
|
||||||
|
|
||||||
|
Defining the OpenStack open source project governance model
|
||||||
|
===========================================================
|
||||||
|
|
||||||
|
The main role of the TC is to define the model under which the OpenStack
|
||||||
|
open source project is governed. Defining governance means defining the
|
||||||
|
processes of interaction and decision-making among the actors involved
|
||||||
|
in producing OpenStack, through the creation, reinforcement, or
|
||||||
|
reproduction of social norms and institutions. It is therefore the duty of
|
||||||
|
the TC to describe the community structure, systems, operating principles,
|
||||||
|
and values by creating and maintaining corresponding documentation. This is
|
||||||
|
done in the :doc:`Technical Committee charter <charter>`,
|
||||||
|
the `TC governance website`_ documents and other TC-maintained publications
|
||||||
|
such as the `Project Team guide`_.
|
||||||
|
|
||||||
|
The TC is just one of the governance bodies more widely involved in
|
||||||
|
OpenStack governance. An important part of its role is therefore to
|
||||||
|
handle the relationships with other OpenStack governance bodies like
|
||||||
|
the OSF Board of Directors, or the OpenStack User Committee.
|
||||||
|
|
||||||
|
Refining and applying the current OpenStack governance model
|
||||||
|
============================================================
|
||||||
|
|
||||||
|
While the governance model itself is changed very rarely, it is
|
||||||
|
constantly tweaked to better handle corner cases as they are discovered,
|
||||||
|
using amendments to the :doc:`TC charter <charter>`, resolutions, or changes
|
||||||
|
in other TC-maintained documents.
|
||||||
|
|
||||||
|
The current governance model institutes a two-level structure with
|
||||||
|
:doc:`project teams <projects/index>` in charge of specific sets of git
|
||||||
|
repositories or tasks. The TC is reponsible for making sure the model
|
||||||
|
is followed, and fair elections are held for every project team.
|
||||||
|
Finally, while most conflicts should be resolved at the project team level,
|
||||||
|
the TC remains ultimately responsible in case issues cannot be solved at
|
||||||
|
that level, for example in case there is a dispute between two project
|
||||||
|
teams on the common way forward.
|
||||||
|
|
||||||
|
Scope of the project
|
||||||
|
====================
|
||||||
|
|
||||||
|
The `OpenStack Foundation bylaws`_ explicitly state in section 4.13 that
|
||||||
|
the TC's authority over technical matters includes the authority to
|
||||||
|
determine the scope of the "OpenStack" released software.
|
||||||
|
|
||||||
|
Under the current governance model, that means the TC constantly refines
|
||||||
|
the rules used to decide which teams are part of the project and which
|
||||||
|
groups are independent (and building on the work of the project). It
|
||||||
|
reviews applications from new project teams that want to place their work
|
||||||
|
under the oversight of the TC, effectively deciding the scope of the project.
|
||||||
|
|
||||||
|
As part of this authority on scope, the TC also provides technical input
|
||||||
|
to the trademark programs defined at the OSF Board level, for example by
|
||||||
|
designating sections of code which are required to be present in an
|
||||||
|
OpenStack installation in order for it to be eligible to use the "OpenStack
|
||||||
|
Powered" trademark.
|
||||||
|
|
||||||
|
Encouraging a unified OpenStack experience
|
||||||
|
==========================================
|
||||||
|
|
||||||
|
While most technical details are handled at the project team level, you
|
||||||
|
still need a body caring about the "OpenStack" experience, beyond each
|
||||||
|
component user experience. It is part of the TC role to take that step
|
||||||
|
back and consider OpenStack as "one platform" that users and operators
|
||||||
|
choose to leverage. This includes looking at gaps between established
|
||||||
|
project teams, driving a common user experience (common operational
|
||||||
|
behavior, limited dependencies, base quality levels, minimum feature
|
||||||
|
set...), pushing cross-project initiatives and influencing its general
|
||||||
|
direction. One way to achieve that is through the definition of OpenStack
|
||||||
|
:doc:`release goals <../goals/index>`.
|
||||||
|
|
||||||
|
|
||||||
|
Ensuring a healthy, open collaboration
|
||||||
|
======================================
|
||||||
|
|
||||||
|
The TC is responsible for making sure the OpenStack project follows
|
||||||
|
the :doc:`four opens <opens>` and operates as a truly open collaboration
|
||||||
|
on a level playing field. This includes checking that project teams follow
|
||||||
|
open source :doc:`licensing rules <licensing>`, are not artificially limiting
|
||||||
|
the features of the open source software to sell a proprietary "enterprise"
|
||||||
|
version, operate in a transparent and accessible manner, and encourage
|
||||||
|
cultural, professional and personal diversity in contributions.
|
||||||
|
|
||||||
|
Beyond that, TC members are engaged in proactively assessing the health of
|
||||||
|
the various project teams, and provide advice and help to team members.
|
||||||
|
|
||||||
|
|
||||||
|
.. _OpenStack Foundation bylaws: https://www.openstack.org/legal/bylaws-of-the-openstack-foundation/
|
||||||
|
.. _TC governance website: https://governance.openstack.org/tc/
|
||||||
|
.. _Project Team guide: http://docs.openstack.org/project-team-guide
|
||||||
Reference in New Issue
Block a user