Open Stack

 ---- On Thu, 13 Sep 2018 00:47:27 +0900 Matt Riedemann <mriedemos at gmail.com> wrote ---- 
 > 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 agree on this and i feel this is real value  we can add with current situation where contributors are less in almost all of the projects. When we set goal for any cycle, we should have user/operator/SIG weightage on priority in selection checklist and categorize the goal into respective category/tag something like "user-oriented"  or "coding-oriented"(only developer/maintaining code benefits).  And then we concentrate more on first category and leave second one more on project team. Project team further can plan the second catagory items as per their bandwidth and priority.  I am not saying code/developer oriented goals should not be initiated by TC but those should be on low priority list kind of. 

-gmann

 > 
 > 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 Development Mailing List (not for usage questions)
 > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
 > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 >