As a result of community discussion, the OpenStack Foundation is evolving the format of the events it produces for the community starting in 2017. The proposal is to split the current Design Summit, which is held every six months as part of the main OpenStack Summit, into two parts: a “Forum” at the main Summit for cross-community discussions and user input (we call this the “what” discussions), and a separate “Project Teams Gathering” event for project team members to meet and get things done (the “how” discussions and sprinting). The intention is to alleviate the need for a separate mid-cycle, so development teams would continue to meet four times per year, twice with the community at large and twice in a smaller, more focused environment. The release cycle would also shift to create more space between the release and Summit. The change triggered a lot of fears and questions — the intent of this FAQ is to try to address them.
Note that we held a community town hall to explain the evolving format of the OpenStack Design Summit. You can watch this recording to learn more about it.
Q: How is the change helping upstream developers?
A: During the Summit week, upstream developers have a lot of different goals. We leverage the Summit to communicate new things (give presentations), learn new things (attend presentations), get feedback from users and operators over our last release, gather pain points and priorities for upcoming development, propose changes and see what the community thinks of them, recruit and on-board new team members, have essential cross-project discussions, meet with our existing project team members, kickstart the work on the new cycle, and get things done. There is just not enough time in 4 or 5 days to do all of that, so we usually drop half of those goals. Most will skip attending presentations. Some will abandon the idea of presenting. Some will drop cross-project discussions, resulting in them not having the critical mass of representation to actually serve their purpose. Some will drop out of their project team meeting to run somewhere else. The time conflicts make us jump between sessions, resulting in us being generally unavailable for listening to feedback, pain points, or newcomers. By the end of the week we are so tired we can’t get anything done. We need to free up time during the week. There are goals that can only be reached in the Summit setting, where all of our community is represented — we should keep those goals in the Summit week. There are goals that are better reached in a distraction-free setting — we should organize a separate event for them.
Q: What is the “Forum” ?
A: “Forum” is the codename for the part of the Design Summit (Ops+Devs) that would still happen at the main Summit event. It will primarily be focused on strategic discussions and planning for the next release (the “what”), essentially the start of the next release cycle even though development will not begin for another 3 months. We should still take advantage of having all of our community (Devs, Ops, End users…) represented to hold cross-community discussions there. That means getting feedback from users and operators over specific projects in our last release, gathering pain points and priorities for upcoming development, proposing changes and see what the community thinks of them, and recruiting and on-boarding new team members. We’d like to do that in a neutral space (rather than have separate “Ops” and “Dev” days) so that the discussion is not influenced by who owns the session. This event would happen at least two months after the previous release, to give users time to test and bring valuable feedback.
Q: What is the “Project Teams Gathering” ?
A: “Project Teams Gathering” is the codename for the part of the Design Summit that will now happen as a separate event. It will primarily provide space for project teams to make implementation decisions and start development work (the “how”). This is where we’d have essential cross-project discussions, meet with our existing project team members, generate shared understanding, kickstart the development work on the new cycle, and generally get things done. OpenStack project teams would be given separate rooms to meet for one or more days, in a loose format (no 40-min slots). If you self-identify as a member of a specific OpenStack project team, you should definitely join. If you are not part of a specific project team (or can’t pick one team), you could still come but your experience of the event would likely not be optimal, since the goal of the attendees at this event is to get things done, not listen to feedback or engage with newcomers. This event would happen around the previous release time, when developers are ready to fully switch development work to the new cycle.
Q: How is the change helping OpenStack as a whole?
A: Putting the larger Summit event further away from last release should dramatically improve the feedback loop. Currently, calling for feedback at the Summit is not working: users haven’t had time to use the last release at all, so most of the feedback we collect is based on the 7-month old previous release. It is also the wrong timing to push for new features: we are already well into the new cycle and it’s too late to add new priorities to the mix. The new position of the “Forum” event with respect to the development cycle should make it late enough to get feedback from the previous release and early enough to influence what gets done on the next cycle. By freeing up developers time during the Summit week, we also expect to improve the Summit experience for all attendees: developers will be more available to engage and listen. The technical content at the conference will also benefit from having more upstream developers available to give talks and participate in panels. Finally, placing the Summit further away from the release should help vendors prepare and announce products based on the latest release, making the Summit marketplace more attractive and relevant.
Q: When will the change happen ?
A: Summits are booked through 2017 already, so we can’t really move them anytime soon. Instead, we propose to stagger the release cycle. There are actually 7 months between Barcelona and Boston, so we have an opportunity there to stagger the cycle with limited impact. The idea would be to do a 5-month release cycle (between October and February), place our first project teams gathering end-of-February, then go back to 6-month cycles (March-August) and have the Boston Summit (and Forum) in the middle of it (May). So the change would kick in after Barcelona, in 2017. That gives us time to research venues and refine the new event format.
Q: What about mid-cycles ?
A: Mid-cycle sprints were organized separately by project teams as a way to gather team members and get things done. They grew in popularity as the distractions at the main Summit increased and it became hard for project teams to get together, build social bonds and generally be productive at the Design Summit. We hope that teams will get back that lost productivity and social bonding at the Project Teams Gathering, eliminating the need for separate team-specific sprints.
Q: This Project Teams Gathering thing is likely to be a huge event too. How am I expected to be productive there? Or to be able to build social bonds with my small team?
A: Project Teams Gatherings are much smaller events compared to Summits (think 400-500 people rather than 7500). Project teams are placed in separate rooms, much like a co-located midcycle sprint. The only moment where everyone would meet would be around lunch. There would be no evening parties: project teams would be encouraged to organize separate team dinners and build strong social bonds.
Q: Does that new format actually help with cross-project work?
A: Cross-project work was unfortunately one of the things a lot of attendees dropped as they struggled with all the things they had to do during the Summit week. Cross-project workshops ended up being less and less productive, especially in getting to decisions or work produced. Mid-cycle sprints ended up being where the work can be done, but them being organized separately meant it is very costly for a member of a cross-project team (infrastructure, docs, QA, release management…) to attend them all. We basically set up our events in a way that made cross-project work prohibitively expensive, and then wondered why we had so much trouble recruiting people to do it. The new format ensures that we have a place to actually do cross-project work, without anything running against it, at the Project Teams Gathering. It dramatically reduces the number of places a Documentation person (for example) needs to travel to get some work done in-person with project team members. It gives project team members in vertical teams an option to break out of their silo and join such a cross-project team. It allows us to dedicate separate rooms to specific cross-project initiatives, beyond existing horizontal teams, to get specific cross-project work done.
Q: Are devs still needed at the main Summit?
A: Upstream developers are still very much needed at the main Summit. The Summit is (and always was) where the feedback loop happens. All project teams need to be represented there, to engage in planning, collect the feedback on their project, participate in cross-community discussions, reach out to new people and on-board new developers. We also very much want to have developers give presentations at the conference portion of the Summit (we actually expect that more of them will have free time to present at the conference, and that the technical content at the Summit will therefore improve). So yes, developers are still very much needed at the main Summit.
Q: My project team falls apart if the whole team doesn’t meet in person every 3 months. We used to do that at the Design Summit and at our separate mid-cycle project team meeting. I fear we’ll lose our ability to all get together every 3 months.
A: As mentioned earlier, we hope the Project Teams Gathering to be a lot more productive than the current Design Summit, reducing the need for mid-cycle sprints. That said, if you really still need to organize a separate mid-cycle sprint, you should definitely feel free to do so. We plan to provide space at the main Summit event so that you can hold mid-cycle sprints there and take advantage of the critical mass of people already around. If you decide to host a mid-cycle sprint, you should communicate that your team mid-cycle will be co-located with the Summit and that team member attendance is strongly encouraged.
Q: We are a small team. We don’t do mid-cycles currently. It feels like that with your change, we’ll have to travel to two events per cycle instead of one.
A: You need to decide if you feel the need to get the team all together to get some work done. If you do, you should participate (as a team) to the Project Teams Gathering. If you don’t, your team should skip it. The PTL and whoever is interested in cross-project work in your team should still definitely come to the Project Teams Gathering, but you don’t need to get every single team member there as you would not have a team room there. In all cases, your project wants to have some developers present at the Summit to engage with the rest of the community.
Q: The project I’m involved with is mostly driven by a single vendor, most of us work from the same office. I’m not sure it makes sense for all of us to travel to a remote location to get some work done !
A: You are right, it doesn’t. We’ll likely not provide specific space at the Project Teams Gathering for single-vendor project teams. The PTL (and whoever else is interested) should probably still come to the Project Teams Gathering to participate in cross-project work. And you should also definitely come to the Summit to engage with other organizations and contributors and increase your affiliation diversity to the point where you can take advantage of the Project Teams Gathering.
Q: I’m a translator, should I come to the Project Teams Gathering?
A: The I18n team is of course free to meet at the Project Teams Gathering. However, given the nature of the team (large number of members, geographically-dispersed, coming from all over our community, ops, devs, users), it probably makes sense to leverage the Summit to get translators together instead. The Summit constantly reaches out to new communities and countries, while the Project Teams Gathering is likely to focus on major developer areas. We’ll likely get better outreach results by holding I18n sessions or workshops at the “Forum” instead.
Q: A lot of people attend the current Design Summit to get a peek at how the sausage is made, which potentially results in getting involved. Doesn’t the new format jeopardize that on-boarding?
A: It is true that the Design Summit was an essential piece in showing how open design worked to the rest of the world. However that was always done at the expense of existing project team members productivity. Half the time in a 40-min session would be spent summarizing the history of the topic to newcomers. Lively discussions would be interrupted by people in the back asking that participants use the mike. We tried to separate fishbowls and workrooms at the Design Summit, to separate discussion/feedback sessions from team-members work sessions. That worked for a time, but people started working around it, making some work rooms look like overcrowded fishbowl rooms. In the end that makes up for a miserable experience for everyone involved and created a lot of community tension. In the new format, the “Forum” sessions will still allow people to witness open design at work, and since those are specifically set up as listening sessions (rather than “get things done” sessions), we’ll take time to engage and listen. We’ll free up time for specific on-boarding and education activities. Fewer scheduling conflicts during the week means we won’t be always running to our next sessions and will likely be more available to reach out to others in the hallway track.
Q: What about the Ops midcycle meetup?
A: The Ops meetups are still happening, and for the next year or two probably won’t change much at all. In May, the “Ops Meetups Team” was started to answer the questions about the future of the meetups, and also actively organize the upcoming ones. Part of that team’s definition: “Keeping the spirit of the ops meetup alive” – the meetups are run by ops, for ops and will continue to be. If you have interest, join the team and talk about the number and regional location of the meetups, as well as their content.
Q: What about ATC passes for the Summit?
A: The OpenStack Foundation gave discounted passes to a subset of upstream contributors (not all ATCs) who contributed in the last six months, so that they could more easily attend the Summit. We’ll likely change the model since we would be funding a second event, but will focus on minimizing costs for people who have to travel to both the Summit and the Project Teams Gathering. The initial proposal is to charge a minimal fee for the Project Teams Gathering (to better gauge attendance and help keep sponsorship presence to a minimum), and then anyone who was physically present at the Project Teams Gathering would receive a discount code to attend the next Summit. Something similar is also being looked into for contributors represented by the User Committee (eg. ops). At the same time, we’ll likely beef up the Travel Support Program so that we can get all the needed people at the right events.
