 Thank you for joining us on SuperUserTV. I'm wondering if you can tell us about the big question on everyone's minds, which is how the design summit might be changing. Can you tell us a little bit about some of the concerns or limitations going on in the current format for the design summit? Sure. So the main benefit of the summit event is that we have everyone around and we have people from all over the place. We have people coming from the ops community, people coming from user community, people new commerce to our community that are around and developers as well. And the big benefit of this event is to have everyone in the same place at the same time together. And at the same time, we organize a design summit, which is four days, where project teams need team time to do things and they're basically in their corner in a room and not exposed to the rest of the conference. And that's not necessarily the best use of their time. There's a lot of things going on as well and having so much contention during the summit week means the developers are not really available for presenting or for attending presentations or to listen to people asking for new requirements, new features. So the change is about freeing up developers' time so that they can actually be there for everyone else and engage with new contributors and learn new things, share new things without having so much work to do on the other side. Because this tension between the two sides of the event means there's always something on your mind, you should be doing something else so you're not really available for all that. So what could a split design summit look like? So we have the design summit here and we use it for two different things. One is to gather feedback from the larger community and some of it is to get work done as a team. And since I said earlier, something has to give. There's just too much things during the week to do everything. And what we think should give is the project team gathering, the project team work where you try to get things done with your team and you should benefit from having everyone around and be out there having discussions. So the way we envision it to look like is to still have developers, operators, everyone at the summit event and use that time to have community discussions around specific topics. So feedback from users, engage with new contributors, onboarding upstream university, having devs available to do project updates, conference talks, etc. And have a separate event where the teams are just the team together to get work done. And that actually makes a lot of sense when you think about it like this but it's trying to have everything at the same moment. We kind of worked around the problem by organizing separate events on the side and that kind of hurt all the cross-project work as a result and we hope that the change will really help in fostering new cross-project work at this developer-oriented event and have the devs available for the rest of the community at the main summit. Now Mataka was the 13th release of open-stack software and I'm wondering if you can tell me what you were most proud of that came out in the Mataka release? That would be very partial. I'm very proud of the work the release management team did under the leadership of Doug Ellman to automate most of the release work because with the big tent and all those projects being recognized as official open-stack projects we had a surge in requests for different release models, different release requests and without automation the job would just be impossible for a team of two or three people and Doug really worked to insert a lot of automation in the process so now it's almost painless to do a release and that really helped in passing that. So it's more of a process thing than a feature but that's the thing I'm most proud of. That's fantastic. And so I understand you've only been able to go to a few of the Newton design planning things so far but I wonder if you could talk a little bit about what are some of the big areas of discussion even if we're not yet to the end of the week with some final answers. So what are people talking about here? So we've seen a lot of discussions on stable branch and the time it will take. I mean how much time do we keep releases around due to looking at the user survey results on adoption and so we've been discussing what it would take technically to increase that stable maintenance period. So work on backward compatibility, work on automation again so that the quantity of work that is required to maintain those stable branches go down so that in the future we could better align the stable maintenance period with the expectations of our users and that's where I try to spend most of my summit time this week so that would be my early Newton peak there. Is there anything else that you want to add? Any takeaways from Austin that have been particularly important to you? So I think to come back to the original discussion on the split thing I think another consequence of the change will be to put the summit further away from the release date because we've realized that just two weeks after release we don't really have great feedback or products built on top of the release nobody has had time to actually experiment with it or deploy it or build products on top of it especially with the summit just around people just prepare for the summit and so the quality of the feedback we've been getting as a result is not as optimal as it could be so moving further away the summit event from the release gives time for people to experiment with it for products to be built on top of it and as a result the feedback that we would get at that event where we want the devs to be able to listen to people would improve so most of the feedback we got this week was liberty feedback and what we kind of want is Mitaka feedback as developers so moving that summit event further away from the release should get us that kind of feedback that we are looking for and that's another outcome of redesigning how we think about events in OpenStack Thank you so much for joining us Thank you