Open Stack

On Thu, Jan 31, 2019 at 4:22 AM Thierry Carrez <thierry at openstack.org>
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.
>

FWIW - I've participated in groups that have attempted to self-organize
like this in the past, but without a formal blessing.

We started by socializing the problem and the need for a solution [0]. We
scheduled reoccurring meetings around it [1], attempted to document
progress [2], and spin up specific efforts to help us design a solution
that worked for our community [3][4]. After we felt comfortable with what
we had, we attempted to use cross-project specs [5] (which we abandoned for
the reasons you mentioned) and community goals to start moving the needle
[6]. We also attempted to document the outcomes using project
specifications [7][8] and other tools [9]. The difference between what we
did and what you're proposing, in my opinion, is that we didn't define our
disband criteria very well [10][11] and no one officially blessed us by any
means. We were just a group that collected around an issue we cared about
solving. I do think the effort was useful and helped us make progress on a
challenging problem, which we're still trying to resolve.

Outside of having a formal name, do we expect the "pop-up" teams to include
processes that make what we went through easier? Ultimately, we still had
to self-organize and do a bunch of socializing to make progress.

[0]
http://lists.openstack.org/pipermail/openstack-dev/2016-November/107137.html
[1] https://review.openstack.org/#/c/398500/
[2] https://etherpad.openstack.org/p/keystone-policy-meeting
[3]
http://lists.openstack.org/pipermail/openstack-dev/2017-October/123069.html
[4]
http://lists.openstack.org/pipermail/openstack-dev/2017-October/123331.html
[5] https://review.openstack.org/#/c/523973/
[6] https://governance.openstack.org/tc/goals/queens/policy-in-code.html
[7]
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing/policy-goals.html
[8]
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing/policy-security-roadmap.html
[9] https://trello.com/b/bpWycnwa/policy-roadmap
[10] https://review.openstack.org/#/c/581800/
[11]
http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-07-03-16.00.log.html#l-346


> 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)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190131/647cd4c6/attachment.html>