How splitting the Design Summit enhances the development process
I was recently privately asked how I expected the split of the current OpenStack Design Summit into two different events to enhance the overall OpenStack development process. Here is the answer I gave...
We are working on splitting the "Design Summit" into a more open requirements-gathering and feedback forum at the Summit on one side, and a separated event for project team members on the other side. I expect this change will greatly enhance the development process, for the following reasons:
Key upstream developers and PTLs were too busy during the Summit week to actually watch and listen. Having them more available during the Summit week (where all of our community is present) should help a lot in getting the right priorities across. The feedback sessions were also not very well balanced (being organized as part of the upstream developer-centric event called the "Design Summit"). Making it more like a regular Summit event will help make it a neutral exchange forum between community peers (rather than dev kings listening to grievances in their throne hall).
Project teams were lacking time to work together as a team: building trust, organizing the work, agreeing on priorities and assigning tasks. The current "Design Summit" doesn't work so well for that because it doubles as a general forum and a lot of people outside the team members were attending the sessions. There were also too many distractions to hang out between team members and build social bonds. This is why a lot of teams organized specific, separated events (the "midcycles"): to get more time together. The new "Project Teams Gathering" event is all about providing that time to work together as a team.
Partly as a result of separate midcycle events, project teams operated in silos and were unlikely to be exposed or take on critical cross-project work. They would also skip the cross-project workshops at the Design Summit since so much is happening at the same time. The new event should provide specific time for cross-project work, without anything running against it. It should encourage team members from a vertical team (Nova, Neutron...) to join and participate in horizontal / cross-project efforts (QA, Infra, technology convergence, release theme...), to break out of their silo and become true "OpenStack" contributors.
The timing of the "Design Summit" event was inefficient. It was too late to organize work, too early to get feedback on the recent release. By splitting the events, we put the main Summit further away from the release -- giving time for packagers, deployers, solutions builders to build a product and start experimenting with the new release. The quality of the feedback we get should therefore improve a lot. It also lets us put the new event closer to the start of the development cycle (closer to the previous cycle feature freeze), ensuring there is less "down" time between cycles (almost two months in the current setup).
So, in summary, I expect the new split event format to solve long-standing issues that made the "Design Summit" no longer efficient. It should increase our productivity, but also greatly improve the feedback loops between downstream and upstream.