<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><br></div><div>I'm glad we have this request/letter</div><div><br></div><div>I have raised the same discussion around PTG with TCs, PTLs, UCs (as many as I can find this week). Also on Ops-meetup, K8S-SIG, FC SIG session. And on Self-healing SIG's ML [1](the session is not started yet so as TC's session).</div><div><br></div><div>I propose we expose SIGs/WGs and provide a single window (just like we have discussed in ML about integrating Mailing lists) for users and ops so if they got any issues/bugs/features they can have a more stride forward place to put their story in a single place so it's easier to go from story to multi-project tasks for each team to trace and work on. and other users/ops can easier to find similar issues. Which will also easier to trigger a cross-project meeting for some real scenarios. Also potentially cross-project gatting, and cycle goal cross projects.</div><div><br></div><div>After asking opinions around, generally, the feedbacks are mostly good (there are some concerns, I will send more detail out later, once PTG is done).</div><div>So in order to accomplish this task, we need to redefine project teams, SIGs and WGs's permission to make sure the flow from users/ops to developers and back to users/ops is clear.</div><div><br></div><div>But first of all, we need to collect more feedback from all group (will do it after PTG or after sessions)</div><div><br></div><div><span class="gmail-gr_ gmail-gr_1272 gmail-gr-alert gmail-gr_spell gmail-gr_inline_cards gmail-gr_run_anim gmail-ContextualSpelling gmail-ins-del gmail-multiReplace" id="gmail-1272" style="display:inline;border-bottom:2px solid transparent;background-repeat:no-repeat">will</span> be super if TCs can go for this idea!!</div><div><br></div><div><br></div><div>[1] <a href="http://lists.openstack.org/pipermail/openstack-sigs/2018-August/000453.html" target="_blank">http://lists.openstack.org/pipermail/openstack-sigs/2018-August/000453.html</a></div></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" target="_blank">mriedemos@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">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></div></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="m_-7125744647498215391gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="background-image:none!important"><div style="font-size:small"><div><table border="0" cellpadding="0" cellspacing="0" style="color:rgb(0,0,0);font-size:medium;font-family:verdana"><tbody><tr><td colspan="3" align="left" valign="center"><span style="font-size:13px;font-family:verdana">May The Force of Open<font color="#ff0000">Stack</font> Be With You,</span> <br><b><i><font face="georgia, serif" size="4">Rico Lin<br></font></i></b>irc: ricolin</td></tr><tr><td colspan="3" align="left" valign="center" style="height:10px;border-bottom-width:1px;border-bottom-style:dashed;border-bottom-color:rgb(221,221,221)"></td></tr><tr><td colspan="3"></td></tr></tbody></table><br></div></div></div><font size="2" face="tahoma, sans-serif" color="#999999"></font></div></div></div></div></div></div></div></div></div></div>