Open Stack

+1
________________________________________
From: Thierry Carrez [thierry at openstack.org]
Sent: Thursday, January 31, 2019 2:19 AM
To: openstack-discuss at lists.openstack.org
Subject: [all][tc] Formalizing cross-project pop-up teams

TL;DR:
Maybe to help with cross-project work we should formalize temporary
teams with clear objective and disband criteria, under the model of
Kubernetes "working groups".

Long version:

Work in OpenStack is organized around project teams, who each own a set
of git repositories. One well-known drawback of this organization is
that it makes cross-project work harder, as someone has to coordinate
activities that ultimately affects multiple project teams.

We tried various ways to facilitate cross-project work in the past. It
started with a top-level repository of cross-project specs, a formal
effort which failed due to a disconnect between the spec approvers (TC),
the people signed up to push the work, and the teams that would need to
approve the independent work items.

This was replaced by more informal "champions", doing project-management
and other heavy lifting to get things done cross-project. This proved
successful, but champions are often facing an up-hill battle and often
suffer from lack of visibility / blessing / validation.

SIGs are another construct that helps holding discussions and
coordinating work around OpenStack problem spaces, beyond specific
project teams. Those are great as a permanent structure, but sometimes
struggle to translate into specific development work, and are a bit
heavy-weight just to coordinate a given set of work items.

Community goals fill the gap between champions and SIGs by blessing a
given set of cross-community goals for a given release. However, given
their nature (being blessed by the TC at every cycle), they are a better
fit for small, cycle-long objectives that affect most of the OpenStack
project teams, and great to push consistency across all projects.

It feels like we are missing a way to formally describe a short-term,
cross-project objective that only affects a number of teams, is not tied
to a specific cycle, and organize work around a temporary team
specifically formed to reach that objective. A team that would get
support from the various affected project teams, increasing chances of
success.

Kubernetes encountered the same problem, with work organized around
owners and permanent SIGs. They created the concept of a "working
group"[1] with a clear limited objective, and a clear disband criteria.
I feel like adopting something like it in OpenStack could help with work
that affects multiple projects. We would not name it "working group"
since that's already overloaded in OpenStack, but maybe "pop-up team" to
stress the temporary nature of it. We've been sort-of informally using
those in the past, but maybe formalizing and listing them could help
getting extra visibility and prioritization.

Thoughts? Alternate solutions?

[1]
https://github.com/kubernetes/community/blob/master/committee-steering/governance/wg-governance.md

--
Thierry Carrez (ttx)