<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 31, 2019 at 4:22 AM Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">TL;DR:<br>Maybe to help with cross-project work we should formalize temporary <br>teams with clear objective and disband criteria, under the model of <br>Kubernetes "working groups".<br>
<br>Long version:<br>
<br>Work in OpenStack is organized around project teams, who each own a set <br>of git repositories. One well-known drawback of this organization is <br>that it makes cross-project work harder, as someone has to coordinate <br>activities that ultimately affects multiple project teams.<br>
<br>We tried various ways to facilitate cross-project work in the past. It <br>started with a top-level repository of cross-project specs, a formal <br>effort which failed due to a disconnect between the spec approvers (TC), <br>the people signed up to push the work, and the teams that would need to <br>approve the independent work items.<br>
<br>This was replaced by more informal "champions", doing project-management <br>and other heavy lifting to get things done cross-project. This proved <br>successful, but champions are often facing an up-hill battle and often <br>suffer from lack of visibility / blessing / validation.<br>
<br>SIGs are another construct that helps holding discussions and <br>coordinating work around OpenStack problem spaces, beyond specific <br>project teams. Those are great as a permanent structure, but sometimes <br>struggle to translate into specific development work, and are a bit <br>heavy-weight just to coordinate a given set of work items.<br>
<br>Community goals fill the gap between champions and SIGs by blessing a <br>given set of cross-community goals for a given release. However, given <br>their nature (being blessed by the TC at every cycle), they are a better <br>fit for small, cycle-long objectives that affect most of the OpenStack <br>project teams, and great to push consistency across all projects.<br>
<br>It feels like we are missing a way to formally describe a short-term, <br>cross-project objective that only affects a number of teams, is not tied <br>to a specific cycle, and organize work around a temporary team <br>specifically formed to reach that objective. A team that would get <br>support from the various affected project teams, increasing chances of <br>success.<br></blockquote><div><br></div><div>FWIW - I've participated in groups that have attempted to self-organize like this in the past, but without a formal blessing.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>[0] <a href="http://lists.openstack.org/pipermail/openstack-dev/2016-November/107137.html">http://lists.openstack.org/pipermail/openstack-dev/2016-November/107137.html</a></div><div>[1] <a href="https://review.openstack.org/#/c/398500/">https://review.openstack.org/#/c/398500/</a><br></div><div>[2] <a href="https://etherpad.openstack.org/p/keystone-policy-meeting">https://etherpad.openstack.org/p/keystone-policy-meeting</a></div><div>[3] <a href="http://lists.openstack.org/pipermail/openstack-dev/2017-October/123069.html">http://lists.openstack.org/pipermail/openstack-dev/2017-October/123069.html</a></div><div>[4] <a href="http://lists.openstack.org/pipermail/openstack-dev/2017-October/123331.html">http://lists.openstack.org/pipermail/openstack-dev/2017-October/123331.html</a><br></div><div>[5] <a href="https://review.openstack.org/#/c/523973/">https://review.openstack.org/#/c/523973/</a></div><div>[6] <a href="https://governance.openstack.org/tc/goals/queens/policy-in-code.html">https://governance.openstack.org/tc/goals/queens/policy-in-code.html</a><br></div><div>[7] <a href="http://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing/policy-goals.html">http://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing/policy-goals.html</a></div><div>[8] <a href="http://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing/policy-security-roadmap.html">http://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing/policy-security-roadmap.html</a></div><div>[9] <a href="https://trello.com/b/bpWycnwa/policy-roadmap">https://trello.com/b/bpWycnwa/policy-roadmap</a></div><div>[10] <a href="https://review.openstack.org/#/c/581800/">https://review.openstack.org/#/c/581800/</a></div><div>[11] <a href="http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-07-03-16.00.log.html#l-346">http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-07-03-16.00.log.html#l-346</a></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>Kubernetes encountered the same problem, with work organized around <br>owners and permanent SIGs. They created the concept of a "working <br>group"[1] with a clear limited objective, and a clear disband criteria. <br>I feel like adopting something like it in OpenStack could help with work <br>that affects multiple projects. We would not name it "working group" <br>since that's already overloaded in OpenStack, but maybe "pop-up team" to <br>stress the temporary nature of it. We've been sort-of informally using <br>those in the past, but maybe formalizing and listing them could help <br>getting extra visibility and prioritization.<br>
<br>Thoughts? Alternate solutions?<br>
<br>[1] <br>
<a href="https://github.com/kubernetes/community/blob/master/committee-steering/governance/wg-governance.md" rel="noreferrer">https://github.com/kubernetes/community/blob/master/committee-steering/governance/wg-governance.md</a><br>
<br>-- <br>Thierry Carrez (ttx)<br>
<br>
</blockquote></div></div></div></div></div></div></div></div></div></div></div></div></div></div>