<div dir="ltr">seems like I forget to cc uc-ml. My reply to the dev-ml copied below:<div><br></div><div><span style="font-size:12.8px">to put my public cloud wg hat on, I think the lack of coordination is a common problems among OpenStack WGs but I think transitioning WGs to SIGs will not help solving the issue alone.</span><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">I think from my observations from existing WGs, the mechanism that are now in place works great, we have many productive output coming out of WGs. </div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">The core problem here is how WG chairs establish a working method with PTLs of related project each cycle, so that both side understand each other and important matters getting solved in the near cycles. The dev circles and non-dev circles are fairly isolated at the moment.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Merely rebranding WGs won't solve this core problem, I would recommend the following actions:</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">1. In addition to the current TC/UC/Projects/WG mechanism, allow people to establish adhoc SIGs without any procedure overhead (getting approved by any entity). Folks in the spontaneously established SIGs could find their best way to get their requirement done. We could have an overall wiki page for collection/registration of all the SIGs created.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">2. Enhance dev/non-dev comms. I doubt more meetings will be the solution.</div><blockquote style="font-size:12.8px;margin:0px 0px 0px 40px;border:none;padding:0px"><div>a. I would suggest projects when doing their planning at Forum or PTG, always leave a spot for requirement from WGs. And WG chairs should participate this dev meetings if their WG has done related work. </div><div>b. Moreover the foundation could start promotion of project/WG collaboration best practices, or even specify in the release document that certain feature are based upon feedback from a certain WGs.</div></blockquote><blockquote style="font-size:12.8px;margin:0px 0px 0px 40px;border:none;padding:0px">c. WG should have cycle-based releases of works so that they got a sense of timing, no lost in a permanent discussion mode for issues.</blockquote><br style="font-size:12.8px"><div style="font-size:12.8px">My 2 cents</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 21, 2017 at 11:11 PM, Melvin Hillsman <span dir="ltr"><<a href="mailto:mrhillsman@gmail.com" target="_blank">mrhillsman@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"><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/<wbr>wiki/Governance/Foundation/<wbr>UserCommittee#Working_Groups_<wbr>and_Teams</a></div><div>[2] <a href="https://wiki.openstack.org/wiki/Upstream_Working_Groups" target="_blank">https://wiki.openstack.org/<wbr>wiki/Upstream_Working_Groups</a></div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-- </div><div>Melvin Hillsman & Thierry Carrez</div></font></span></div>
</div>
<br>______________________________<wbr>_________________<br>
User-committee mailing list<br>
<a href="mailto:User-committee@lists.openstack.org">User-committee@lists.<wbr>openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/user-<wbr>committee</a><br>
<br></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"><div><div dir="ltr">Zhipeng (Howard) Huang</div><div dir="ltr"><br></div><div dir="ltr">Standard Engineer</div><div>IT Standard & Patent/IT Product Line</div><div dir="ltr">Huawei Technologies Co,. Ltd</div><div dir="ltr">Email: <a href="mailto:huangzhipeng@huawei.com" target="_blank">huangzhipeng@huawei.com</a></div><div dir="ltr">Office: Huawei Industrial Base, Longgang, Shenzhen</div><div dir="ltr"><br></div><div dir="ltr">(Previous)<br><div>Research Assistant</div><div>Mobile Ad-Hoc Network Lab, Calit2</div><div>University of California, Irvine</div><div>Email: <a href="mailto:zhipengh@uci.edu" target="_blank">zhipengh@uci.edu</a></div><div>Office: Calit2 Building Room 2402</div><div><br></div><div>OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado</div></div></div></div></div></div></div></div></div>
</div>