[all][tc] Formalizing cross-project pop-up teams
colleen at gazlene.net
Thu Jan 31 14:26:44 UTC 2019
On Thu, Jan 31, 2019, at 11:19 AM, Thierry Carrez wrote:
> 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
> Kubernetes encountered the same problem, with work organized around
> owners and permanent SIGs. They created the concept of a "working
> group" 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?
I like the idea. One question is, how would these groups be bootstrapped? At the moment, SIGs are formed by 1) people express an interest in a common idea 2) the SIG is proposed and approved by the TC and UC chairs 3) profit. With a more cross-project, deliverable-focused type of group, you would need to have buy-in from all project teams involved before bringing it up for approval by the TC - but getting that buy-in from many different groups can be difficult if you aren't already a blessed group. And if you didn't get buy-in first and the group became approved anyway, project teams may be resentful of having new objectives imposed on them when they may not even agree it's the right direction.
> Thierry Carrez (ttx)
More information about the openstack-discuss