<div dir="ltr">Well Public Cloud WG has prepared the ammo as you know and to discuss with TC on Friday :)<div><br></div><div>A hundred percent with you on this matter.</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Sep 12, 2018 at 9:47 AM Matt Riedemann <<a href="mailto:mriedemos@gmail.com">mriedemos@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Rather than take a tangent on Kristi's candidacy thread [1], I'll bring <br>
this up separately.<br>
<br>
Kristi said:<br>
<br>
"Ultimately, this list isn’t exclusive and I’d love to hear your and <br>
other people's opinions about what you think the I should focus on."<br>
<br>
Well since you asked...<br>
<br>
Some feedback I gave to the public cloud work group yesterday was to get <br>
their RFE/bug list ranked from the operator community (because some of <br>
the requests are not exclusive to public cloud), and then put pressure <br>
on the TC to help project manage the delivery of the top issue. I would <br>
like all of the SIGs to do this. The upgrades SIG should rank and <br>
socialize their #1 issue that needs attention from the developer <br>
community - maybe that's better upgrade CI testing for deployment <br>
projects, maybe it's getting the pre-upgrade checks goal done for Stein. <br>
The UC should also be doing this; maybe that's the UC saying, "we need <br>
help on closing feature gaps in openstack client and/or the SDK". I <br>
don't want SIGs to bombard the developers with *all* of their <br>
requirements, but I want to get past *talking* about the *same* issues <br>
*every* time we get together. I want each group to say, "this is our top <br>
issue and we want developers to focus on it." For example, the extended <br>
maintenance resolution [2] was purely birthed from frustration about <br>
talking about LTS and stable branch EOL every time we get together. It's <br>
also the responsibility of the operator and user communities to weigh in <br>
on proposed release goals, but the TC should be actively trying to get <br>
feedback from those communities about proposed goals, because I bet <br>
operators and users don't care about mox removal [3].<br>
<br>
I want to see the TC be more of a cross-project project management <br>
group, like a group of Ildikos and what she did between nova and cinder <br>
to get volume multi-attach done, which took persistent supervision to <br>
herd the cats and get it delivered. Lance is already trying to do this <br>
with unified limits. Doug is doing this with the python3 goal. I want my <br>
elected TC members to be pushing tangible technical deliverables forward.<br>
<br>
I don't find any value in the TC debating ad nauseam about visions and <br>
constellations and "what is openstack?". Scope will change over time <br>
depending on who is contributing to openstack, we should just accept <br>
this. And we need to realize that if we are failing to deliver value to <br>
operators and users, they aren't going to use openstack and then "what <br>
is openstack?" won't matter because no one will care.<br>
<br>
So I encourage all elected TC members to work directly with the various <br>
SIGs to figure out their top issue and then work on managing those <br>
deliverables across the community because the TC is particularly well <br>
suited to do so given the elected position. I realize political and <br>
bureaucratic "how should openstack deal with x?" things will come up, <br>
but those should not be the priority of the TC. So instead of <br>
philosophizing about things like, "should all compute agents be in a <br>
single service with a REST API" for hours and hours, every few months - <br>
immediately ask, "would doing that get us any closer to achieving top <br>
technical priority x?" Because if not, or it's so fuzzy in scope that no <br>
one sees the way forward, document a decision and then drop it.<br>
<br>
[1] <br>
<a href="http://lists.openstack.org/pipermail/openstack-dev/2018-September/134490.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2018-September/134490.html</a><br>
[2] <br>
<a href="https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.html" rel="noreferrer" target="_blank">https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.html</a><br>
[3] <a href="https://governance.openstack.org/tc/goals/rocky/mox_removal.html" rel="noreferrer" target="_blank">https://governance.openstack.org/tc/goals/rocky/mox_removal.html</a><br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt<br>
<br>
_______________________________________________<br>
openstack-sigs mailing list<br>
<a href="mailto:openstack-sigs@lists.openstack.org" target="_blank">openstack-sigs@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" 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>