Open Stack

>> reliance on a central (OSC) team for implementation and reviews.
<snip>>> Would moving tools like cinder or glance to OSC plugins help solve
<snip>
> upside is project teams could move things themselves faster, like they
> do with their own python-*client projects today. They are also the ones
> that know better how their API works.
<snip>
> The downside of project teams owning their parts of the CLI are losing a
> unified vision
<snip>
> we would have to trust them
<snip>
> I would still want Dean
> overseeing things happening at the component level though, at least
> until there are more obvious OSC-wide cores, i.e. component core(s)
> +1/+2 a thing but Dean has final say.

This is becoming a familiar theme for projects/efforts with touchpoints
across OpenStack.

Docs deliverables have been moved into individual projects, and "the
docs team" is becoming a SIG [1]. But who is the Dean of docs, making
sure we retain a common structure, style, and voice across all of these
deliverables?

SDK is making forays into the "trust component SMEs" arena [2].

The API-SIG is undergoing a similar existential exercise [3], and it is
unclear where its deliverables will end up.

And this issue with OSC is not new.

All of these have their own nuances, but also quite a bit in common. Can
we brainstorm ways that might address more than one in a satisfactory
way? Here's one idea:

Deliverables live in projects under the governance of their component;
so for example nova-docs and nova-osc-plugin and nova-sdk-plugin would
be under nova governance, with core teams managed by nova. But patches
in those projects require an additional vote of a different flavor (a
"Rollcall-Vote"?) from the related SIG or core team in order to merge.

Thoughts?

efried

[1]
http://lists.openstack.org/pipermail/openstack-discuss/2019-August/thread.html#8571
[2]
http://lists.openstack.org/pipermail/openstack-discuss/2019-August/thread.html#8362
[3]
http://lists.openstack.org/pipermail/openstack-discuss/2019-August/thread.html#8673