<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 21, 2017 at 8:59 AM, Thierry Carrez <span dir="ltr"><<a href="mailto:thierry@openstack.org" target="_blank">thierry@openstack.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi everyone,<br>
<br>
One of the areas identified as a priority by the Board + TC + UC<br>
workshop in March was the need to better close the feedback loop and<br>
make unanswered requirements emerge. Part of the solution is to ensure<br>
that groups that look at specific use cases, or specific problem spaces<br>
within OpenStack get participation from a wide spectrum of roles, from<br>
pure operators of OpenStack clouds, to upstream developers, product<br>
managers, researchers, and every combination thereof. In the past year<br>
we reorganized the Design Summit event, so that the design / planning /<br>
feedback gathering part of it would be less dev- or ops-branded, to<br>
encourage participation of everyone in a neutral ground, based on the<br>
topic being discussed. That was just a first step.<br>
<br>
In OpenStack we have a number of "working groups", groups of people<br>
interested in discussing a given use case, or addressing a given problem<br>
space across all of OpenStack. Examples include the API working group,<br>
the Deployment working group, the Public clouds working group, the<br>
Telco/NFV working group, or the Scientific working group. However, for<br>
governance reasons, those are currently set up either as a User<br>
Committee working group[1], or a working group depending on the<br>
Technical Committee[2]. This branding of working groups artificially<br>
discourages participation from one side to the others group, for no<br>
specific reason. This needs to be fixed.<br>
<br>
We propose to take a page out of Kubernetes playbook and set up "SIGs"<br>
(special interest groups), that would be primarily defined by their<br>
mission (i.e. the use case / problem space the group wants to<br>
collectively address). Those SIGs would not be Ops SIGs or Dev SIGs,<br>
they would just be OpenStack SIGs. While possible some groups will lean<br>
more towards an operator or dev focus (based on their mission), it is<br>
important to encourage everyone to join in early and often. SIGs could<br>
be very easily set up, just by adding your group to a wiki page,<br>
defining the mission of the group, a contact point and details on<br>
meetings (if the group has any). No need for prior vetting by any<br>
governance body. The TC and UC would likely still clean up dead SIGs<br>
from the list, to keep it relevant and tidy. Since they are neither dev<br>
or ops, SIGs would not use the -dev or the -operators lists: they would<br>
use a specific ML (openstack-sigs ?) to hold their discussions without<br>
cross-posting, with appropriate subject tagging.<br>
<br>
Not everything would become a SIG. Upstream project teams would remain<br>
the same (although some of them, like Security, might turn into a SIG).<br>
Teams under the UC that are purely operator-facing (like the Ops Tags<br>
Team or the AUC recognition team) would likewise stay as UC subteams.<br>
<br>
Comments, thoughts ?<br>
<br>
[1]<br>
<a href="https://wiki.openstack.org/wiki/Governance/Foundation/UserCommittee#Working_Groups_and_Teams" rel="noreferrer" target="_blank">https://wiki.openstack.org/<wbr>wiki/Governance/Foundation/<wbr>UserCommittee#Working_Groups_<wbr>and_Teams</a><br>
[2] <a href="https://wiki.openstack.org/wiki/Upstream_Working_Groups" rel="noreferrer" target="_blank">https://wiki.openstack.org/<wbr>wiki/Upstream_Working_Groups</a><br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Melvin Hillsman & Thierry Carrez<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a></font></span></blockquote><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">​I don't think this is necessarily where you're heading on this, but one thing that's been kinda nice IMO working in some other upstream communities (like K8's) that use the SIG model.  There's one channel for something like storage, and to your point it's for everybody and anybody interested in that topic.  Whether they're a developer, deployer or end-user.  I actually think this works really well because it ensures that the same people that are developing code are also directly exposed to and interacting with various consumers of their code. </div></div><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline"><br></div></div><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">It also means people that will be consuming the code also may actually get to contribute directly to the development process.  This would be a huge win in my opinion.  The example is that rather than having a cinder channel just for dev related conversations and a general openstack channel for support and questions, throw all Cinder related things into a single channel.  This means devs are actually in touch with ops and users which is something that I think would be extremely beneficial.</div></div><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline"><br></div></div><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">​</div> </div></div><br></div></div>