Open Stack

On Thu, Jan 31, 2019, at 11:19 AM, Thierry Carrez wrote:
> 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?

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.

Colleen

> 
> [1] 
> https://github.com/kubernetes/community/blob/master/committee-steering/governance/wg-governance.md
> 
> -- 
> Thierry Carrez (ttx)
>