Open Stack

Rather than take a tangent on Kristi's candidacy thread [1], I'll bring 
this up separately.

Kristi said:

"Ultimately, this list isn’t exclusive and I’d love to hear your and 
other people's opinions about what you think the I should focus on."

Well since you asked...

Some feedback I gave to the public cloud work group yesterday was to get 
their RFE/bug list ranked from the operator community (because some of 
the requests are not exclusive to public cloud), and then put pressure 
on the TC to help project manage the delivery of the top issue. I would 
like all of the SIGs to do this. The upgrades SIG should rank and 
socialize their #1 issue that needs attention from the developer 
community - maybe that's better upgrade CI testing for deployment 
projects, maybe it's getting the pre-upgrade checks goal done for Stein. 
The UC should also be doing this; maybe that's the UC saying, "we need 
help on closing feature gaps in openstack client and/or the SDK". I 
don't want SIGs to bombard the developers with *all* of their 
requirements, but I want to get past *talking* about the *same* issues 
*every* time we get together. I want each group to say, "this is our top 
issue and we want developers to focus on it." For example, the extended 
maintenance resolution [2] was purely birthed from frustration about 
talking about LTS and stable branch EOL every time we get together. It's 
also the responsibility of the operator and user communities to weigh in 
on proposed release goals, but the TC should be actively trying to get 
feedback from those communities about proposed goals, because I bet 
operators and users don't care about mox removal [3].

I want to see the TC be more of a cross-project project management 
group, like a group of Ildikos and what she did between nova and cinder 
to get volume multi-attach done, which took persistent supervision to 
herd the cats and get it delivered. Lance is already trying to do this 
with unified limits. Doug is doing this with the python3 goal. I want my 
elected TC members to be pushing tangible technical deliverables forward.

I don't find any value in the TC debating ad nauseam about visions and 
constellations and "what is openstack?". Scope will change over time 
depending on who is contributing to openstack, we should just accept 
this. And we need to realize that if we are failing to deliver value to 
operators and users, they aren't going to use openstack and then "what 
is openstack?" won't matter because no one will care.

So I encourage all elected TC members to work directly with the various 
SIGs to figure out their top issue and then work on managing those 
deliverables across the community because the TC is particularly well 
suited to do so given the elected position. I realize political and 
bureaucratic "how should openstack deal with x?" things will come up, 
but those should not be the priority of the TC. So instead of 
philosophizing about things like, "should all compute agents be in a 
single service with a REST API" for hours and hours, every few months - 
immediately ask, "would doing that get us any closer to achieving top 
technical priority x?" Because if not, or it's so fuzzy in scope that no 
one sees the way forward, document a decision and then drop it.

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134490.html
[2] 
https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.html
[3] https://governance.openstack.org/tc/goals/rocky/mox_removal.html

-- 

Thanks,

Matt