<div dir="ltr"><div>Responses inline:</div><div><br></div><div class="gmail_quote"><div dir="ltr">On Mon, Aug 29, 2016 at 5:36 PM David F Flanders <<a href="mailto:flanders@openstack.org">flanders@openstack.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>One of the recent suggestions has been to converge some of the WGs to<br>
help ease the burden of these logistical tasks.<br></blockquote><div><br></div><div>Focus is good.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Other options include:<br>
<br>
  * having a shared IRC channel for all WG activity to help create<br>
more water-cooler conversation between chairs?<br></blockquote><div><br></div><div>Having a common communication channel is how the other teams in openstack have become so cohesive (I'm thinking of infra for example). Whether that's IRC or something else I don't care, though using IRC will certainly build familiarity with the tool so that there's less friction across the board. Also, it's on a common ground with other teams, so asking a question to nova, keystone, etc becomes super easy.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> * sharing of logistical duties between WG chairs, etc<br></blockquote><div><br></div><div><div>How about reducing the necessary logistics? Maintaining a WG requires a minimum overhead / fixed cost, based on how many timezones need to be served, how often the group meets, and how many documents and communications need to be maintained. That should be adjusted up or down, based on whether the market supports the additional cost:<span style="line-height:1.5"> Are there enough active contributors in other timezones to warrant adding the additional cost of a timezone-sensitive meeting? Is there not enough activity to justify meeting every week? Judge these things against what the WG produces, and advice can become pretty clear</span><span style="line-height:1.5">; the trick is recognizing when demand is shrinking, and to contract overhead to a manageable level. It's easy to expand bureaucracy, it's hard to shrink it.</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">As an example, the Hackathon WG started in the App Eco WG, however very quickly demand and visibility increased to warrant them creating their own group. More demand makes the overhead worthwhile, and now they're one of the most productive WG's we have. </span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">In the meantime, the App Eco WG shifted to focus on supporting the SDK efforts, which have turned into a heavy dev/documentation effort. Perhaps it's time to create an SDK team under the TC, on par with Infra and OpenStack itself? That would reduce the duties of the App Eco WG to a level where it may be rolled back up into the Enterprise WG, until research results from UX and the Hackathons warrant starting a new effort.</span></div></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">Michael</span></div></div></div>