On 6/21/2017 9:59 AM, Thierry Carrez wrote:
Hi everyone,
One of the areas identified as a priority by the Board + TC + UC
workshop in March was the need to better close the feedback loop and
make unanswered requirements emerge. Part of the solution is to ensure
that groups that look at specific use cases, or specific problem spaces
within OpenStack get participation from a wide spectrum of roles, from
pure operators of OpenStack clouds, to upstream developers, product
managers, researchers, and every combination thereof. In the past year
we reorganized the Design Summit event, so that the design / planning /
feedback gathering part of it would be less dev- or ops-branded, to
encourage participation of everyone in a neutral ground, based on the
topic being discussed. That was just a first step.
In OpenStack we have a number of "working groups", groups of people
interested in discussing a given use case, or addressing a given problem
space across all of OpenStack. Examples include the API working group,
the Deployment working group, the Public clouds working group, the
Telco/NFV working group, or the Scientific working group. However, for
governance reasons, those are currently set up either as a User
Committee working group[1], or a working group depending on the
Technical Committee[2]. This branding of working groups artificially
discourages participation from one side to the others group, for no
specific reason. This needs to be fixed.
We propose to take a page out of Kubernetes playbook and set up "SIGs"
(special interest groups), that would be primarily defined by their
mission (i.e. the use case / problem space the group wants to
collectively address). Those SIGs would not be Ops SIGs or Dev SIGs,
they would just be OpenStack SIGs. While possible some groups will lean
more towards an operator or dev focus (based on their mission), it is
important to encourage everyone to join in early and often. SIGs could
be very easily set up, just by adding your group to a wiki page,
defining the mission of the group, a contact point and details on
meetings (if the group has any). No need for prior vetting by any
governance body. The TC and UC would likely still clean up dead SIGs
from the list, to keep it relevant and tidy. Since they are neither dev
or ops, SIGs would not use the -dev or the -operators lists: they would
use a specific ML (openstack-sigs ?) to hold their discussions without
cross-posting, with appropriate subject tagging.
Not everything would become a SIG. Upstream project teams would remain
the same (although some of them, like Security, might turn into a SIG).
Teams under the UC that are purely operator-facing (like the Ops Tags
Team or the AUC recognition team) would likewise stay as UC subteams.
Comments, thoughts ?
[1]
https://wiki.openstack.org/wiki/Governance/Foundation/UserCommittee#Working_Groups_and_Teams
[2] https://wiki.openstack.org/wiki/Upstream_Working_Groups
How does the re-branding or re-categorization of these groups solve the
actual feedback problem? If the problem is getting different people from
different groups together, how does this solve that? For example, how do
we get upstream developers aware of operator issues or product managers
communicating their needs and feature priorities to the upstream
developers? No one can join all work groups or SIGs and be aware of all
things at the same time, and actually have time to do anything else.
Is the number of various work groups/SIGs a problem?
Maybe what I'd need is an example of an existing problem case and how
the new SIG model would fix that - concrete examples would be really
appreciated when communicating suggested governance changes.
For example, is there some feature/requirement/issue that one group has
wanted implemented/fixed for a long time but another group isn't aware
of it? How would SIGs fix that in a way that work groups haven't?
--
Thanks,
Matt
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
