<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 21, 2017 at 10:44 AM, Shamail Tahir <span dir="ltr"><<a href="mailto:itzshamail@gmail.com" target="_blank">itzshamail@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>In the past, governance has helped (on the UC WG side) to reduce overlaps/duplication in WGs chartered for similar objectives. I would like to understand how we will handle this (if at all) with the new SIG proposa? Also, do we have to replace WGs as a concept or could SIG augment them? One suggestion I have would be to keep projects on the TC side and WGs on the UC side and then allow for spin-up/spin-down of SIGs as needed for accomplishing specific goals/tasks (picture of a  diagram I created at the Forum[1]).</div><div><br></div></div></blockquote><div><br></div><div>I believe we still have WGs that overlap for specific objectives - like scalability - and having a Scalability SIG could be more efficient rather than the objective existing in multiple WGs who still have to gather resources to address the objective. Spin up/down can still happen though I think of a SIG as something that while it would spin down at some point, it may be quite some time before it does, depending on the special interest.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>The WGs could focus on defining key objectives for users of a shared group (market vertical like Enterprise or Scientific WG, horizontal function like PWG) and then SIGs could be created based on this list to accomplish the objective and spin-down. Similarly a project team could determine a need to gather additional data/requirements or need help with a certain task could also spin-up a SIG to accomplish it (e.g. updating an outdated docs set, discussion on a specific spec that needs to be more thoroughly crafted, etc.)</div><div><br></div></div></blockquote><div><br></div><div>I think SIGs like Documentation, Public Cloud, Scalability, make sense rather than being created to address a more specific objective. A WG could spin off from a SIG but does not seem reasonable for it to be the other way around since the idea behind a working group is to work on something specific - AUC Recognition - and then those members fold back into 0 or 1 SIG. I could be off but I get the feeling that WGs can come together and find commonality amongst each other within a SIG and get more accomplished/quicker aggregating resources around what they already share interest in.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>Finally, how will this change impact the ATC/AUC status of the SIG members for voting rights in the TC/UC elections?</div></div></blockquote><div><br></div><div>Personally I think AUC could go to all members of the SIGs and ATC for those meeting the criteria but this may be a conversation to have between TC/UC where extra-ATC is provided as it does not seem fair, though fair may be irrelevant or relative, for UC elections to be wholly subjected to all SIG members and not TC elections.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>[1] <a href="https://drive.google.com/file/d/0B_yCSDGnhIbzS3V1b1lpZGpIaHBmc29SaUdiYzJtX21BWkl3/" target="_blank">https://drive.google.com/<wbr>file/d/0B_<wbr>yCSDGnhIbzS3V1b1lpZGpIaHBmc29S<wbr>aUdiYzJtX21BWkl3/</a></div><div><br></div><div>Thanks,</div><div>Shamail</div><div><br></div><div>PS: I wish we had a single thread on this topic so discussions happening on the various MLs could be cross referenced.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Wed, Jun 21, 2017 at 10:59 AM, Melvin Hillsman <span dir="ltr"><<a href="mailto:mrhillsman@gmail.com" target="_blank">mrhillsman@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div><div>Hi everyone,</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Comments, thoughts ?</div><div><br></div><div>[1] <a href="https://wiki.openstack.org/wiki/Governance/Foundation/UserCommittee#Working_Groups_and_Teams" target="_blank">https://wiki.openstack.org/wik<wbr>i/Governance/Foundation/UserCo<wbr>mmittee#Working_Groups_and_<wbr>Teams</a></div><div>[2] <a href="https://wiki.openstack.org/wiki/Upstream_Working_Groups" target="_blank">https://wiki.openstack.org/wik<wbr>i/Upstream_Working_Groups</a></div><span class="m_-7811102309963451142HOEnZb"><font color="#888888"><div><br></div><div>-- </div><div>Melvin Hillsman & Thierry Carrez</div></font></span></div>
</div>
<br></div></div>______________________________<wbr>_________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.open<wbr>stack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-operators</a><br>
<br></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div class="m_-7811102309963451142gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div style="font-size:small">Thanks,</div><div style="font-size:small">Shamail Tahir</div><div style="font-size:small">t: @ShamailXD</div><div style="font-size:small">tz: Eastern Time</div></div></div></div></div>
</font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><span style="font-size:small">-- </span><br style="font-size:small"><div style="font-size:small"><div dir="ltr"><div dir="ltr">Kind regards,<br><br>Melvin Hillsman</div><div dir="ltr"><a href="mailto:mrhillsman@gmail.com" style="color:rgb(17,85,204)" target="_blank">mrhillsman@gmail.com</a><br>mobile: (832) 264-2646<br><br>Learner | Ideation | Belief | Responsibility | Command</div></div></div></div></div></div></div></div></div>
</div></div>