openstack/governance
Code Issues Proposed changes

Merge "Update and simplify comparison of working groups"

Browse Source
This commit is contained in:
Zuul 2020-08-28 12:58:24 +00:00 committed by Gerrit Code Review
commit b8d0be8b48
2 changed files with 102 additions and 149 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

251
reference/comparison-of-official-group-structures.rst
View File

@ -1,193 +1,146 @@
======================================= =======================================
Comparison of Official Group Structures Comparison of Official Group Structures
======================================= =======================================
This document aims to explain and compare the difference between a community
goal, project team, SIG (special interest group), working group, and a pop-up
team. The intention of this document is to provide a clear view between these
different groups and OpenStack-wide goal. We hope to answer questions such as,
what is the timing to create a SIG? and do I need a SIG or pop-up team to
drive my plan?
The OpenStack community is working to provide multiple different groups and This document aims to compare the various official work groups we have in
goal formats to help drive the community forward. To ensure you're able to OpenStack, and explain the difference between a community goal, project team,
achieve your goals, it's important to know which format you need to drive your SIG (special interest group), working group, pop-up teams... If you are still
mission. unsure, even after you read through this document, please raise your question
on the `mailing-list`_ or on IRC: #openstack-tc so people might be able to
help you.
If you are still unsure, even after you read through this document, please Groups can be organized around two axis: whether they address a long-term or
raise your question on `Mailing List`_ or on IRC: #openstack-tc so short-term mission, and whether that mission is more around development or
people might be able to help you. governance. Missions in OpenStack are either under the oversight of the Board
of Directors (trademark, Foundation affairs) or the Technical Committee
(open source project).
.. image:: ./team-formats.png .. image:: ./team-formats.png
:width: 100% :width: 100%
Mission oriented: Long-term missions Project teams
==================================== =============
There are currently three types of group for long-term missions: a SIG (special
interest group), a working group, and a project team.
Long-term mission has no time limitation.
The life cycle should be considered by whether or not the mission of the group
is completed. A long-term mission can be widely scoped. For example, the aim of
a long-term mission group can be to produce software, share use cases, build
documentations, to build cross-project test jobs, or overall communications.
The specific interest can be well-defined, well maintained, and easier to adopt
across OpenStack. For example, self-healing SIG is working on help with
general self-healing use cases, so whoever wishes to start using self-healing
functionality has the confidence to adopt it in their own environment.
Produces the software: Project teams
------------------------------------
:doc:`Project teams </reference/projects/index>` are responsible for producing :doc:`Project teams </reference/projects/index>` are responsible for producing
the OpenStack software up to release. They are either producing a specific set the "OpenStack" software releases. They are either producing a specific subset
of deliverables (like Compute service deliverables), or provide functions that of OpenStack deliverables (like Compute service deliverables), or provide
are integral to the production of the software (Release management, QA...). functions that are integral to the production of the software (like Release
Project teams are governed by TC and lead by individual project PTL (project management or QA).
team leader). Project team is required when planning for release a deliverable
service. These projects maintain service repository, make sure on time release Project teams are under the oversight of the TC, and traditionally lead by PTLs
for service, manage bug reports, and control the code quality (like (project team leaders). Since their collective output is assembled to make the
consistency review) are all part of the jobs for the project team. "OpenStack" coordinated releases every 6 months, extra accountability is
required of project teams to make OpenStack as a whole reach high quality
standards. In particular, we require named liaisons for deliverable release
management, security vulnerability management, and QA/CI infrastructure
liaison.
Beyond that, project teams own git repositories, review proposed code changes,
manage bug reports, answer questions on the mailing-list, define the future
roadmap for their deliverables, and help communicate recent changes. To that
effect, team members hold regular team meetings and participate in various
community events.
OpenStack has a large number of existing project teams. if you would like to OpenStack has a large number of existing project teams. if you would like to
create a new project team, you can reference create a new project team, you can reference
:doc:`new projects requirements </reference/new-projects-requirements>` :doc:`new projects requirements </reference/new-projects-requirements>`
documentations for more details. documentations for more details.
Special Interest Group (SIG) Special Interest Groups (SIGs)
---------------------------- ==============================
`SIGs`_ (and `SIG wiki page`_) are governed by both TC and UC and lead by SIG
chairs, their function being to gather people (A user, developer, or operator)
who are interested in a specific mission to join discussion and driving actions
across community. You can also consider SIG as a bridge between developers,
operators and users.
SIGs are teams within the community where we collaborate to bring unified `SIGs`_ are groups with a long-term mission, but which are not directly
discussions for all community members who share a common interest. responsible for producing components of the "OpenStack" software release.
As examples, SIGs can be but are not limited to being a first stage They usually gather like-minded individuals that want to advance a specific
in the development of new projects, feature requests, standards facet of OpenStack (like usage of OpenStack in scientific communities) that
adoption, policy implementation, adjacent community work, and just extends beyond a limited set of code repositories. They generally regroup
general discussions. developers, operators and end users interested in the same topics. Some of
those topics are very development oriented (like enabling support for multiple
architectures), while some others are more governance-oriented (like helping
first-time contributors).
You can check for `process to create a SIG`_ for creat a new SIG. SIGs are under the oversight of the TC, and traditionally lead by a number of
co-leads. Since they are not directly in charge of producing OpenStack, only
limited accountability is required, and SIGs do not have any required named
liaisons.
Meta SIG SIGs can own git repositories and produce software, but that software will be
~~~~~~~~ considered add-on software to the main "OpenStack" software releases.
This is just a SIG for `SIGs`_ so to speak. A SIG to discuss OpenStack SIGs
themselves, to encourage workgroups to become SIGs, accompany them along the
way, give them tools and processes to be efficient. More generally, this SIG
will discuss how to best close the loop between users and developers of
OpenStack. The SIG chair is assigned by both TC and UC.
Working Group (WG) You can check for `process to create a SIG`_ for creating a new SIG.
------------------
Working Group (WG) is governed by UC and lead by group leaders to help
users represent and achieve their needs through collaboration in the upstream
community. It's recommended to build a SIG instead of WG if you wish to make
sure the group is under governance of both UC and TC.
If your mission required deliverable services, you can either consider ask Pop-up teams
project teams to help host those services or libraries, or you should consider ============
create a project team if that's more appropriate.
Mission oriented: Short-term missions
=====================================
Mission oriented means the group or goal is build up to serve a specific
mission. Once mission is completed, the group or goal should be consider as no
longer needed anymore.
There are two short-term mission formats, a pop-up team and a
:doc:`community goal </goals/index>`. These both require collaborative
work from multiple teams.
Pop-up team
-----------
Pop-up teams are lightweight structures aiming to provide quick start for short Pop-up teams are lightweight structures aiming to provide quick start for short
term (time-limited) cross-project mission. A pop-up team can be supported by term (time-limited) cross-project mission. In particular, pop-up teams should
the Technical Committee, and should be lead by (at least) two co-leads. have a disband criteria: an end status goal at which point the pop-up team
should be disbanded. These cross-project and time-limited aspects are what
differentiates them from Project teams or SIGs.
Mission of a pop-up team could transfer to a OpenStack-wide cycle goal. Pop-up teams are under the oversight of the TC, and traditionally lead by a
For example, TC members can accept mission of a pop-up team as particular number of co-leads. Since they are not directly in charge of producing
cycle goal (at which point former members of the proposing pop-up team could OpenStack, only limited accountability is required, and pop-up teams do
go on to become its goal champions). not have any required named liaisons.
You can reference create process of popup team in Pop-up teams do not own code repositories, they usually work on code
repositories from existing project teams to reach their goals.
You can read more about the process to create a pop-up team in
:doc:`popup team guideline </reference/popup-teams>` :doc:`popup team guideline </reference/popup-teams>`
if you consider to create one. if you consider to create one.
.. note:: Community goals
All pop-up teams, SIGs and WGs shouldn't maintain any releasable ===============
deliverable. If deliverable repo is required, it should be maintained
under a project team (please also note that SIGs/WGs/pop-up teams still
can create and maintain their own code repositories). Like pop-up team
`Image encryption`, requiring multiple project teams (Nova, Cinder, and
Glance) to maintain and release their implementation in project
repositories.
OpenStack-wide goal champion :doc:`Community goals </goals/index>` are per-release objectives, set by the
---------------------------- Technical Committee for all project teams. Those are used to achieve
A :doc:`community goal </goals/index>` (OpenStack-wide goal) is lead by goal user-visible common changes, push for basic levels of consistency and user
champions. It is used to achieve visible common changes, push for basic levels experience, and efficiently improve certain areas which suffer from technical
of consistency and user experience, and efficiently improve certain areas where debt. The main difference with pop-up teams is that it's a time-limited scope
technical debt payments have become too high across all OpenStack projects. rather than an objective-limited scope, and they generally aim at affecting
These are usually scoped by cycle. all project teams rather than a limited set of them.
If you have a time-limited mission to push to multiple teams but not to entire Community goals are driven by goal champions and executed in each project team.
community, you can consider for build a pop-up team to drive it. And if it's a They do not require specific git repositories or deliverables.
OpenStack-wide goal material but not yet mature enough to announce as a
OpenStack-wide goal for current or following cycle, to form a pop-up team and
drive it before it can be a community goal might be another way you can
consider.
If you have a mission which affects projects OpenStack-wide, then you're If you have an improvement which affects projects OpenStack-wide, then you
free to propose it as a community goal. The Technical Committee will be can propose it as a community goal. The Technical Committee will be
responsible for selecting :doc:`community goal </goals/index>` for each cycle. responsible for selecting :doc:`community goal </goals/index>` for each cycle.
The goal is not necessarily a cross-project feature or bug, it can also be any
OpenStack-wide mission (like :doc:`/goals/selected/train/pdf-doc-generation`
goal). Community goals are defined for a specific development cycle, because
we need to be specific on what we need each team to complete that mission and
how they can do it. That's why it's a short-term mission. But the follow up
mission might still be another goal for another cycle (like
:doc:`/goals/selected/stein/python3-first` goal can be consider as follow up
action from other python3 goals).
.. note:: Technical Committee and TC working groups
All OpenStack-wide goal shouldn't maintain any releasable =========================================
deliverable. If deliverable repo is required, it should be maintained
under a project team.
Governance The `Technical Committee (TC)`_ is an elected governance body, representing all
========== contributors to the open source project.
Committees exist to help `govern`_ the community and provide leadership. It may delegate rights (and duties) to `TC working groups`_ (like the Election
You can self-nominate for the below committees and become a committee member, officials which have a delegation for running elections).
or provide feedback to committee. If you find it's hard or confusing to push
your mission into community, or you find the current structure can't fulfill
your goal, we encourage you to encounter with these committees that might be
able to help:
* Technical Committee (TC) The TC owns git repositories (generally around governance documents) but does
* User Committee (UC) not produce OpenStack deliverables by itself.
* Board of Directors (BoD)
OpenStack Foundation or Board-level committees and working groups Board of Directors, Board committees and working groups
================================================================= =======================================================
We have another level of `committees and working groups`_ like The Foundation `Board of Directors`_ is a governance body, representing all
`Edge Computing Group`_ which are directly driven by OpenStack Foundation Foundation members. It is composed of three tiers: Platinum representatives
(OSF) or Board of directors. (selected by each Platinum member), Gold representatives (elected among the
Gold members), and Independent representatives (elected by all the individual
members of the Foundation).
Others The Board of Directors has oversight over the Foundation, whose mission is to
====== develop, support, protect, and promote OpenStack and other Open Infrastructure
We have some other formate of team like `Election officials`_ helps on multiple projects.
community functionality.
.. _Mailing List: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss It may delegate rights (and duties) to Board `committees and working groups`_,
.. _govern: https://governance.openstack.org/ which are usually staffed by directors themselves.
.. _mailing-list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
.. _SIGs: https://governance.openstack.org/sigs/ .. _SIGs: https://governance.openstack.org/sigs/
.. _committees and working groups: https://wiki.openstack.org/wiki/Governance/Foundation#Committees_.26_Working_Groups
.. _Edge Computing Group: https://wiki.openstack.org/wiki/Edge_Computing_Group
.. _Election officials: https://wiki.openstack.org/wiki/Election_Officiating_Guidelines
.. _SIG wiki page: https://wiki.openstack.org/wiki/OpenStack_SIGs
.. _process to create a SIG: https://governance.openstack.org/sigs/#process-to-create-a-sig .. _process to create a SIG: https://governance.openstack.org/sigs/#process-to-create-a-sig
.. _Technical Committee (TC): https://governance.openstack.org/tc/
.. _TC working groups: https://governance.openstack.org/tc/reference/working-groups.html
.. _Board of Directors: https://www.openstack.org/foundation/board-of-directors/
.. _committees and working groups: https://wiki.openstack.org/wiki/Governance/Foundation#Committees_.26_Working_Groups

BIN
reference/team-formats.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 144 KiB

After

Width:  |  Height:  |  Size: 42 KiB