<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 21, 2017 at 12:02 PM, 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="">Shamail Tahir wrote:<br>
> In the past, governance has helped (on the UC WG side) to reduce<br>
> overlaps/duplication in WGs chartered for similar objectives. I would<br>
> like to understand how we will handle this (if at all) with the new SIG<br>
> proposa?<br>
<br>
</span>I tend to think that any overlap/duplication would get solved naturally,<br>
without having to force everyone through an application process that may<br>
discourage natural emergence of such groups. I feel like an application<br>
process would be premature optimization. We can always encourage groups<br>
to merge (or clean them up) after the fact. How much<br>
overlaps/duplicative groups did you end up having ?<br></blockquote><div><br></div><div>Fair point, it wasn't many. The reason I recalled this effort was because we had to go through the exercise after the fact and that made the volume of WGs to review much larger than had we asked the purpose whenever they were created. As long as we check back periodically and not let the work for validation/clean up pile up then this is probably a non-issue. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> Also, do we have to replace WGs as a concept or could SIG<br>
> augment them? One suggestion I have would be to keep projects on the TC<br>
> side and WGs on the UC side and then allow for spin-up/spin-down of SIGs<br>
> as needed for accomplishing specific goals/tasks (picture of a  diagram<br>
> I created at the Forum[1]).<br>
<br>
</span>I feel like most groups should be inclusive of all community, so I'd<br>
rather see the SIGs being the default, and ops-specific or dev-specific<br>
groups the exception. To come back to my Public Cloud WG example, you<br>
need to have devs and ops in the same group in the first place before<br>
you would spin-up a "address scalability" SIG. Why not just have a<br>
Public Cloud SIG in the first place?<br></blockquote><div><br></div><div>+1, I interpreted originally that each use-case would be a SIG versus the SIG being able to be segment oriented (in which multiple use-cases could be pursued) </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> [...]<br>
<span class="">> Finally, how will this change impact the ATC/AUC status of the SIG<br>
> members for voting rights in the TC/UC elections?<br>
<br>
</span>There are various options. Currently you give UC WG leads the AUC<br>
status. We could give any SIG lead both statuses. Or only give the AUC<br>
status to a subset of SIGs that the UC deems appropriate. It's really an<br>
implementation detail imho. (Also I would expect any SIG lead to already<br>
be both AUC and ATC somehow anyway, so that may be a non-issue).<br></blockquote><div><br></div><div>We can discuss this later because it really is an implementation detail. Thanks for the answers. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
--<br>
Thierry Carrez (ttx)<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><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></div>