<div dir="ltr">+1 SIGs should have limited scope - shared interest in a particular area - even if that area is something broad like security the mission and work should be specific which could lead to working groups, additional SIGs, projects, etc so I want to be careful how I word it but yes limited scope is the ideal way to start a SIG imo.<br></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jan 11, 2019 at 11:14 AM Duc Truong <<a href="mailto:duc.openstack@gmail.com">duc.openstack@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">+1 on limiting the scope to autoscaling at first.  I prefer the name<br>
autoscaling since the mission is to improve automatic scaling.  If the<br>
mission is changed later, we can change the name of the SIG to reflect<br>
that.<br>
<br>
On Fri, Jan 11, 2019 at 8:24 AM Ben Nemec <<a href="mailto:openstack@nemebean.com" target="_blank">openstack@nemebean.com</a>> wrote:<br>
><br>
><br>
><br>
> On 1/11/19 10:14 AM, Adam Spiers wrote:<br>
> > Rico Lin <<a href="mailto:rico.lin.guanyu@gmail.com" target="_blank">rico.lin.guanyu@gmail.com</a>> wrote:<br>
> >> Dear all<br>
> >><br>
> >> To continue the discussion of whether we should have new SIG for<br>
> >> autoscaling.<br>
> >> I think we already got enough time for this ML  [1], and it's time to<br>
> >> jump to the next step. As we got a lot of positive feedbacks from ML<br>
> >> [1], I think it's definitely considered an action to create a new SIG,<br>
> >> do some init works, and finally Here are some things that we can start<br>
> >> right now, to come out with the name of SIG, the definition and mission.<br>
> >> Here's my draft plan: To create a SIG name `Automatic SIG`, with given<br>
> >> initial mission to improve automatic scaling with (but not limited to)<br>
> >> OpenStack. As we discussed in forum [2], to have scenario tests and<br>
> >> documents will be considered as actions for the initial mission. I<br>
> >> gonna assume we will start from scenarios which already provide some<br>
> >> basic tests and documents which we can adapt very soon and use them to<br>
> >> build a SIG environment. And the long-term mission of this SIG is to<br>
> >> make sure we provide good documentation and test coverage for most<br>
> >> automatic functionality.<br>
> >> I suggest `Automatic SIG` instead of `Autoscaling SIG` to make sure we<br>
> >> can provide more value if there are more needs in the future. Just<br>
> >> like the example which Adam raised `self-optimizing` from people who<br>
> >> are using watcher [3]. Let me know if you got any concerns about this<br>
> >> name.<br>
> ><br>
> > I'm +1 for creating the SIG, although "Automatic SIG" doesn't sound<br>
> > quite right to me, because it's not clear what is being automated. For<br>
> > example from the outside people might think it was a SIG about CI, or<br>
> > about automated testing, or both - or even some kind of automatic<br>
> > creation of new SIGs ;-)<br>
> > Here are some alternative suggestions:<br>
> > - Optimization SIG<br>
> > - Self-optimization SIG<br>
> > - Auto-optimization SIG<br>
> > - Adaptive Cloud SIG<br>
> > - Self-adaption SIG<br>
> > - Auto-adaption SIG<br>
> > - Auto-configuration SIG<br>
> ><br>
> > although I'm not sure these are a huge improvement on "Autoscaling SIG"<br>
> > - maybe some are too broad, or too vague.  It depends on how likely it<br>
> > is that the scope will go beyond just auto-scaling.  Of course you could<br>
> > also just stick with the original idea of "Auto-scaling" :-)<br>
><br>
> I'm inclined to argue that limiting the scope of this SIG is actually a<br>
> feature, not a bug. Better to have a tightly focused SIG that has very<br>
> specific, achievable goals than to try to boil the ocean by solving all<br>
> of the auto* problems in OpenStack. We all know how "one SIG to rule<br>
> them all" ends. ;-)<br>
><br>
> >> And to clarify, there will definitely some cross SIG co-work between<br>
> >> this new SIG and Self-Healing SIG (there're some common requirements<br>
> >> even across self-healing and autoscaling features.). We also need to<br>
> >> make sure we do not provide any duplicated work against self-healing<br>
> >> SIG. As a start, let's only focus on autoscaling scenario, and make<br>
> >> sure we're doing it right before we move to multiple cases.<br>
> ><br>
> > Sounds good!<br>
> >> If no objection, I will create the new SIG before next weekend and<br>
> >> plan a short schedule in Denver summit and PTG.<br>
> ><br>
> > Thanks for driving this!<br>
><br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><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></div></div></div></div></div></div></div></div></div>