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
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
