Open Stack

I'm glad we have this request/letter

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).

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.

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).
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.

But first of all, we need to collect more feedback from all group (will do
it after PTG or after sessions)

will be super if TCs can go for this idea!!


[1]
http://lists.openstack.org/pipermail/openstack-sigs/2018-August/000453.html

On Wed, Sep 12, 2018 at 9:47 AM 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 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-sigs mailing list
> openstack-sigs at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
>


-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-sigs/attachments/20180912/29365cb9/attachment-0001.html>