In Denver we had a Forum session on how to facilitate driving common goals, here is a quick summary. We started by defining the different types of common goals in OpenStack. There are OpenStack-wide consistency goals (having common support for a feature across all OpenStack components, raising the minimal QA/doc/operations bar, improving overall "openstack" experience). And there are cross-project changes that only affect some projects: project refactoring (like extracting placement), multi-project features (like volume multi-attach) or architectural changes (like having common node-centric agents). The discussion then shifted to discussing why cross-project is hard. While I thought the projectteam-centric structure made the cross-project work less rewarding, discussion revealed that most of the difficulty comes from lack of initial directions / contacts, and lack of synchronous discussions to get buy-in from the various stakeholders. We then moved to discuss implementation models. The release goals (small, limited to one development cycle and affecting all teams) are great to drive consistency goals. SIGs are great to drive long-term cross-project changes, care for special interests, or global concerns that affect both software production and software consumption. That leaves a gap for short or mid-term cross-project changes. Popup teams are designed to fill that gap. Those would be used to drive a clear, limited cross-project objective. They are temporary like release goals, but can extend beyond a release cycle. They just need a clear disband criteria. During the rest of the session we discussed how to best implement them to facilitate that work. We ran out of time before solving the key question of whether the TC should approve the idea, the technical implementation, or the team membership itself. The implementation discussion continued during the TC meeting at the PTG on Saturday. The general consensus in the room was that the TC should look at the scope/goal of the proposed popup team (before any spec), and offer to "support" it if it looks like a viable goal and a desirable objective for OpenStack. Supported popup teams would get listed on the governance website, and get a experienced community member sponsor to serve as a liaison with the TC and mentor the popup team through initial steps (like getting the right connections in the various affected teams). Further discussion on implementation specs may reveal that the goal is impossible or not desirable, in which case the popup team can be disbanded. Action items to move this idea forward include documenting the popup team concept / approval criteria and create a home for them on the governance website (ttx), documenting best practices on how to get cross-project work done (ildiko), and documenting the difference between project teams, SIGs and popup teams (ricolin, ttx, persia). -- Thierry Carrez (ttx)