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.ht... [2] http://lists.openstack.org/pipermail/openstack-discuss/2019-August/thread.ht... [3] http://lists.openstack.org/pipermail/openstack-discuss/2019-August/thread.ht...