At the upcoming Sydney Summit, Stackers will put their heads together for what’s next at the Forum. That means we’ll gather feedback on the current release, Pike, and start drawing up requirements for the next one, Rocky.
Quick recap: “Forum” is the code name for the part of the Design Summit (operators+developers) that takes place at Summit event. It focuses on strategic discussions, user-dev brainstorming and marks the start of the next release cycle’s planning phase. By breaking out the implementation and more detailed discussions into the PTG, we will reduce parallelization in the Forum and facilitate more strategic discussion with the right people in the room. We decided not to call it the Design Summit, because that has historically been a dev-centric event and we want dev, ops and all active contributors to come together as equals. The Forum allows us all to start on the same footing.
The next Forum will be at the Sydney Summit to host sessions that take best advantage of having all of our community (devs, ops, end users…) in one place. These include:
- Strategic, whole-of-community discussions, to think about the big picture, including beyond just one release cycle and new technologies
- Cross-project sessions, in a similar vein to what has happened at past design summits, but with increased emphasis on issues that are of relevant to all areas of the community
- Project-specific sessions, where developers can ask users specific questions about their experience, users can provide feedback from the last release and cross-community collaboration on the priorities and ‘blue sky’ ideas for the next release.
How the Forum is organized
The Forum is for the entire community to come together, to create a neutral space rather than having separate “ops” and “dev” days. Like in past Summits, we will use Etherpads to brainstorm topics, starting a couple of months before the summit. Each team (or group of teams working together) should list topics, communicate with other teams and choose their most compelling ideas for formal submission. Afterward, a team of representatives from the User Committee, the Technical Committee and Foundation staff will take the list of sessions proposed by the community and fill out the schedule.
In general, there won’t be any sessions specific to “ops” or “dev” on the schedule, so ideally all session proposals would have multiple groups backing the proposal. We recommend groups start reaching out to each other as soon as possible to build relationships that will facilitate great session proposals.
Practically, the Forum is looking to be three parallel rooms laid out in fishbowl format, running for the majority of the summit.
There’s more detail on the wiki.
What are the time frames for Sydney?
- September 18, 2017: Formal topic submission tool opens.
- September 29: Deadline for proposing Forum topics. Scheduling committee meeting to make draft agenda.
- October 9, 2017: Draft Forum schedule published. Crowdsourced session conflict detection. Forum promotion begins.
- October 23, 2017: Scheduling committee final meeting.
- October 30, 2017: Draft Forum schedule published.
- November 6-8, 2017: Forum at OpenStack Summit in Sydney.
How do discount codes work?
- Upstream developers will receive a discount code to the Summit if they physically attend either the Atlanta or Denver PTG
- AUCs and ATCs for the Pike cycle are also eligible for discounts and will receive a notification if they are eligible.
What makes a great Forum session?
- Involves both developers and users
- Multiple projects/teams/working groups collaborating
- Has a concrete outcome/a conclusion to work toward
Can my Working Group or Project still meet at the Summit?
There will be some space available for working group meetings, likely during the first two days of the event, but this will be separate to the Forum. We also want to provide some working room-style space for dev team meetings at the end of the week. Additionally, we’re looking at having a room dedicated for on-boarding new contributors that teams and working groups can schedule into.
Explain the entire release cycle layout to me.
We recommend this diagram.
I’m a developer, should I come?
We would love as many developers as possible to come, but realize that some of you may have to prioritize attending the PTG over the summit. In order to achieve the objectives of the Forum as the release cycle planning kick-off and big user interaction point, we need to have some significant representation from each project (PTLs, strategically-focused team members…). In order to keep travel costs under control for those attending both events, people physically attending the PTG will receive a discount code to attend the Summit.
I’m a cloud operator, should I come?
Yes, this event will allow you to actively participate in the Open Design process. If possible, be sure to bring specific feedback from the latest release including bug links and your ideas for the next release.
I’m an application developer, should I come?
Yes, you are the reason we build the software and run the clouds. We need to know what you are trying to do and how your experience has been.
I’m a product manager, should I come?
Yes, we need your expertise to help shepherd discussions into tangible outcomes. Do note though, that OpenStack is not traditionally product-managed – we recommend you contact the Product Working Group before diving in deep!
Why are we doing this again?
- To create the best possible software we can
- To facilitate direct engagement between users and contributors
- To help us be more strategic and thoughtful with planning (even beyond just one cycle!)
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 seven-month old previous release. It’s 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.