On Thu, Jan 31, 2019 at 4:22 AM Thierry Carrez thierry@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/p... [8] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing/p... [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...
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/gover...
-- Thierry Carrez (ttx)