<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>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>Finally, how will this change impact the ATC/AUC status of the SIG members for voting rights in the TC/UC elections?</div><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><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 21, 2017 at 11:26 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"><span class="">Matt Riedemann wrote:<br>
> How does the re-branding or re-categorization of these groups solve the<br>
> actual feedback problem? If the problem is getting different people from<br>
> different groups together, how does this solve that? For example, how do<br>
> we get upstream developers aware of operator issues or product managers<br>
> communicating their needs and feature priorities to the upstream<br>
> developers?<br>
<br>
</span>My hope is that specific developers interested in a given use case or a<br>
given problem space would join the corresponding SIG and discuss with<br>
operators in the same SIG. As an example, imagine an upstream developer<br>
from CERN, able to join the Scientific SIG to discuss with operators and<br>
users with Scientific/Academic needs of the feature gap, and group with<br>
other like-minded developers to get that feature gap collectively addressed.<br>
<span class=""><br>
> No one can join all work groups or SIGs and be aware of all<br>
> things at the same time, and actually have time to do anything else.<br>
> Is the number of various work groups/SIGs a problem?<br>
<br>
</span>I would not expect everyone to join every SIG. I would actually expect<br>
most people to join 0 or 1 SIG.<br>
<span class=""><br>
> Maybe what I'd need is an example of an existing problem case and how<br>
> the new SIG model would fix that - concrete examples would be really<br>
> appreciated when communicating suggested governance changes.<br>
><br>
> For example, is there some feature/requirement/issue that one group has<br>
> wanted implemented/fixed for a long time but another group isn't aware<br>
> of it? How would SIGs fix that in a way that work groups haven't?<br>
<br>
</span>Two examples:<br>
<br>
- the "API WG" was started by people on the UC side, listed as a UC<br>
workgroup, and wasn't making much progress as it was missing devs. Now<br>
it's been reborn as a TC workgroup, led by a couple of devs, and is<br>
lacking app user input. Artificial barriers discourage people to join.<br>
Let's just call all of them SIGs.<br>
<br>
- the "Public Cloud WG" tries to cover an extremely important use case<br>
for all of OpenStack (we all need successful OpenStack public clouds).<br>
However, so far I've hardly seen a developer joining, because it's seen<br>
as an Ops group just trying to make requirements emerge. I want the few<br>
developers that OVH or CityCloud or other public clouds are ready to<br>
throw upstream to use the rebranded "Public Cloud SIG" as a rally point,<br>
to coordinate their actions. Because if they try to affect upstream<br>
separately, they won't go far, and we badly need them involved.<br>
<br>
Yes, it's mostly a rebranding exercise, but perception matters.<br>
Hope this clarifies,<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Thierry Carrez (ttx)<br>
</font></span><div class="HOEnZb"><div class="h5"><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><br>
</div></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 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>
</div>