 Hi there, folks. I'm Heidi Joy with the OpenStack Foundation. And with me, my colleagues, Pete Chadwick, Shamile to hear. And we're really excited to talk about the community-generated roadmap today. Pete, maybe would you start, introduce yourself, and maybe tell us a little bit about the product work group? Sure. Pete Chadwick, I work for SUSE, where I'm director of product management with responsibility for cloud and systems management. I've actually been participating in the product working group since pretty much its inception, I don't know, four years ago, three years ago. And our goal is really to provide the interlock between the community of operators and users and try to feedback information back to the PTLs on kind of direction and cross-project activities. And then similarly, explain to the community where we're trying to take the overall project. Awesome. And Shamile to hear. Maybe could you tell us a little bit about the background of the roadmap itself? Absolutely. Hi, everyone. My name is Shamile Tahir. I'm the director of product management at Athena Health. And so as Pete said, we've kind of formed the product working group as a way to kind of build a feedback loop, if you will, an actionable feedback loop, actually. And so a big part of that is getting user needs into the community, but then it's also as we have 60-plus projects at this point, there's weekly IRC meetings and a lot going on. So we were trying to think, OK, is there a way that we could kind of take key developments that are user-facing, like top-through user features, let's say, from each of the individual project teams, and build an easy-to-consume way to see all of that in a single presentation outlook. And so that was really the genesis of the roadmap. And so what we do there is we talk to the project teams. We ask them standard questions. And you'll see some of the responses and types of questions that we ask through the presentation. And once we get that data, we then aggregate that and kind of boil that down into what does a release look like from a focus area perspective, as well as, for each project, we highlight some of the key user needs that they're trying to meet in the next release, or maybe the release after that even, just so you can get a sense as a consumer of OpenStack or as a decision-maker about the feature readiness of any given project based on your own individual needs. And at the OpenStack Foundation, I've been leading the user survey, and I've also been working really closely with the product workgroup on the community-generated roadmap. And I have to say that one of the most valuable things that the product workgroup does for the foundation is help us not only gather so many inputs from all these different PTLs and projects as well as the themes, but also help us prioritize them. So in our presentation today, you'll get a sense of what some of the most exciting features and enhancements coming in pike are from our perspective. Another thing I do with the foundation is I help with the branding. And so I worked with different project teams, more than 60 of them, to help them determine their mascot and eventually deliver a logo to represent them. And so in this case, you're seeing the projects, their mascots. And these are the ones that chose to participate in the community-generated roadmap in this cycle. Something that you can do to kind of get a sense of how do these break down is if you look at the top row, all of these are projects with 50% or greater adoption. We were able to get input from all of those. In the center row, these are the smaller size projects that have lesser adoption but are still significant players in our community. They have anywhere from 23% adoption according to the latest user survey, in the case of Ironic, down to just 4% adoption, in the case of Zakhar, but climbing. And then finally, when you look at the bottom row of projects that we're representing, these folks are not currently tracked in terms of adoption, but they did give us significant input for the roadmap. So what does the roadmap show us? I wondered if you could talk a little bit about this, Pete. Sure, so one of the things we wanted to do is really provide some feedback to the community on what are the key features that are coming in each of the releases or each of the projects in the Pike release. We're also trying to get a glimpse of what's coming in later releases, but as you can imagine, that's a little less clear. But the idea is to say, what are the key user features that are coming that'll directly affect how either operators can deploy and manage OpenStack or how end users can use OpenStack in their day-to-day activities? So I'll talk a little bit about the themes, but first I really wanna dig into those features and enhancements that we can look forward to in Pike. And the experts on these are really my colleagues here, not me, so which of you is handling this first one? I'll start with this one. I'll start. Go, man. So one of the things in Cinder that we heard from users was that there's a requirement when you've got a long-running job that sometimes starts to be low on disk capacity, you wanna be able to add more capacity to an existing Cinder volume without shutting down the virtual machine that's actually taking advantage of that. So that's one of the key features that Cinder's providing. We think that's a huge usability improvement. Another key one is from the documentation team, they've actually made an effort to start archiving old documentation on docs.opensack.org. So if you've read the most recent user survey, and actually it was even a trend in the last user survey, I think it says that users check documentation up to twice a week regularly. And so it's a pretty critical aspect of learning, troubleshooting, managing your opensack deployment. Also in the user survey, if you take a look, majority of the adoption for, which release is your opensack cloud on, is actually probably n-minus two release. And documentation today is updated to reflect only the most current version of the opensack release. And so what this means is if you're an opensack kilo user and you go on docs.opensack.org, you can't find any information relevant to your deployment. And so that is gonna change moving forward. And the docs team will make sure that as new releases come out, they'll keep the older versions online because the community is still consuming those versions of opensack. Yeah. And one of the things, the themes you'll probably hear the most in our presentation today is that so much of the community-generated roadmap dovetails perfectly with the feedback that we get from the user survey. There were also verbatim comments about how people wanted to see some changes in documentation. And so it's really exciting to see how responsive the development community is to the user needs. Yes. This one is, I think is critical for driving ironic deployment for two reasons. One is it just enables a bare metal server to plug into the existing neutron networking framework so you can have a consistent, system approach to networking between neutron and virtual machines. More importantly, it actually is the only way you can get true multi-tenant capabilities of an ironic. Previously, ironic was deployed in such a way that all your bare metal servers existed on a single network, which means obviously that every customer that you were giving or every end user that you were giving a bare metal server to was on the same network as everyone else. This allows you to get multi-tenancy. It allows you to get the flexibility of integrating virtual machines with bare metal servers. And I think this is a key reason that people have been holding back on deploying ironics. We would expect that to be much more accepted in the future user surveys. Absolutely. In the past, I've personally been involved in cloud deployments where there was the OpenStack cloud running virtual machines and the bare metal cloud was its own cloud because it wasn't multi-tenant. So we had to almost create a separate cloud. And so this will hopefully bridge that gap, as you said. Yeah. So let's talk Keystone. So this is an interesting one because it sets a future direction and foundation for better quota management, quota experience overall in OpenStack. So that's been one of the things that we've consistently heard from the user community on the mailing list and in ops, meetups, and mid-cycles is that when you're at a large scale and you're consuming OpenStack services, quota management becomes pretty difficult because each project implements its own view of what the quota data is, as well as model of how do you enforce quotas? And so things like hierarchical quotas, nested quotas, et cetera, are all top of mind topics on how our quota is consumed by our users. And I think we're gonna drill down and tap further. But as a foundational step, what's happening is the Keystone team built a unified limit support which basically is saying that the tracking data that used to reside in each individual service database like Nova had its own resource usage, Cinder had its own, that limit data will now be stored within Keystone. So even though the enforcement and the implementation of how that data is used is still at the service level, we now at least have a common schema and model for storing that in one place which makes querying that data so much easier. Yeah. So this is another one that's a mix between Neutron and Nova. And the idea is that I may have machines that are spread across different networks from a backend perspective. And if I wanna do live migration, historically you had to be on the same network with the same backend Neutron driver. This enables you to design a much more flexible system if you have different networking infrastructures on the backend, but still maintain the capability of doing live migration, VM resuscitation if you're in the event of an outage. It just greatly simplifies operations in these heterogeneous environments which more and more customers are starting to deploy when they deploy OpenStack. And Nova. And so this is another big one as well. So in the Ocata release, there's a notion in Nova called cells. If you weren't familiar with it, basically it was a mechanism built to help Nova scale further. So basically you could have separate databases and API endpoints. That way you're most scalable in your deployment. Think of it as almost like a distributed deployment of the service. And so cells was the vision that delivered on that. Prior to Ocata, there were cells V1 which worked but they were very opinionated and very rigid in how it could be implemented and it's use case applicability. Starting with Ocata, the Nova team released cells V2 which is a much more refined version, much more multi-purpose model for delivering that scalability. But in Ocata, there's two interesting things here. In Ocata, consuming Nova via cells became mandatory. So all Nova deployments have to be built in a cell. And what that means is so when you deploy Nova, you're in a single cell deployment to start with. In Ocata though, there was no way to get to multi-cell. So cells V2 in Ocata only supported one cell. And so now in the Pyke release, they're actually gonna scale that model to where they built the right framework and in Pyke they're gonna now allow multiple cells V2 cells to allow you to actually take advantage of the scalability even further. Excellent. And last but not least, let's talk a little bit about Swift which in the user survey we saw that some of the consumption of Swift has grown 400%. So this has become a very, very popular project. And this one is pretty straightforward. As you get to, as you put Swift into production, you will start putting more and more things into containers, into objects within Swift. And at some point the actual container that's holding the object gets too big. And this is the ability to say, I wanna take some of the stuff that's in this container and split it across multiple containers. So it simplifies that process and addresses a real problem when you've got a successful Swift deployment and it's growing, which of course is what most people want to do when they deploy OpenStack is to grow as fast as they can without limit and running into scalability issues. So one of the things that is, oh wait, I almost skipped. All again. Please go ahead. So last but not least is an emerging project from an adoption perspective called Courier. And so Courier is a networking API layer that basically acts as a mapping layer for container networking APIs to neutrons API model. And so basically what it allows you to do is allows you to consume containers, can consume basically neutron networking through this mapping layer that Courier delivers. And so in Pyke, they delivered two container compatible models or mappings that they've delivered on, which is A, you can now use Courier Kubernetes to map Kubernetes networking to neutron, as well as Courier to live network to map Docker networking to neutron. And I think this is important because when Mark was talking, Mark Collier was talking in the keynote today, was talking about trying to figure out how do we make sure that we don't reinvent a bunch of things in a containerized environment that we've already invented in OpenStack. So this is again, one of those steps to try and enable reusing components, whether it's Cinder or Neutron, that have established good API layers that abstract the software defined infrastructure upwards towards the workloads and reuse that effort wherever we can. Yeah. And so in addition to providing us a lot of raw material from each of the PTLs, who provided about three features as well as some of the specs and blueprints, times 24 projects, you can imagine that here we are sitting with 75 or more different features and enhancements that we're looking forward to in Pyke. And so one of the huge pieces of value that the product work group brings to the foundation is that kind of prioritization in knowing which of these to highlight. So I think these are some really exciting things that we're looking forward to in Pyke. And we often find that the kind of pre-release announcement for Pyke is really exciting. Well, you're in on the ground floor. You're seeing the pre-release of Pyke right now. So we like to connect the dots between development themes and by creating these development themes, you can kind of see how different projects are working on the same kind of stuff. And so before I talk about what the projects told us their themes were, Shamile, I'd love it if you would please introduce what do we mean when we say these seven different themes? Absolutely. So the notion of themes came about from when we're brainstorming and how can we make this data consumable, we would get lists from project teams because there's a ton of velocity in OpenStack projects. That was 20 different features and specs that they're delivering on. And so we said, okay, from a user perspective, how can I digest this data? And so what we came up with was a notion of themes which allow you to figure out which feature is increasing or enhancing which attribute of the service itself. And so themes that we have for now and we iterate these over time, they've evolved from five to seven at this point, are scalability. So these are our features or changes within a project that allow it to scale further so I can support more volumes or I can support more instances or even page nation, I can support more objects in Horizon. That would all be scalability related things. Resiliency are feature deliveries that increase the reliability and availability of a service. So this is going, being able to do like active, active volumes in Cinder, that'll be a resiliency thing. Having, you know, convergence engine which can do auto healing, that's a resiliency thing. Manageability is features that we believe enhance the operating experience. So these are not end user facing features and enhancements. These are changes that you, if you're managing OpenStack and you're an operator, these changes make it much more manageable and either simplified manageability or more efficient manageability of the services. Modularity is a theme that's basically more focused internally on the project itself. So as the projects have evolved over time, they found that, okay, I can take this one thing that I was doing here in five different projects and I can move it to an Oslo library for example and I can consume that common library instead of having that code in each individual service as well as I can take components of my service like Nova Scheduler for example and break them out from the base, the foundational code base to basically build a modular and composable service in a sense. And so that's what modularity is really showing. Interoperability in this sense from a theme perspective is obviously interoperability as in common experience in APIs where possible but in this sense it's actually implying that I'm implementing things in a way where they can be used by other services. So basically when one service consumes another service deliverer like we talked about Keystone introducing limits and if Nova consumes those limits in our world that would be called interoperability because it's one project relying on another project to deliver a capability. Yeah and in the user survey we heard from the users that they wanted to see more interoperability among projects that having those projects work well together. Well and I think in general all of these themes didn't arise out of a vacuum it was based upon feedback. We got back really I think starting in the Havana release or even before that of what were the things that were frustrating to operators, frustrating to users or what were inhibiting the deployment of OpenStack in a broader sense. So we really tried to break it down to what are the inhibitors, what are the issues and provide guidance to the technical teams and here's what you need to go focus on. Right these are definitely not all the potential themes that could be addressed. The last two on here are security and user experience. So to wrap this up security in this context from a theme is really delivering security related functionality or features so this would be things like implementing role-based access control or making traceability or auditability easier. So these are security related features not necessarily vulnerability patches and maintaining good code hygiene from a vulnerability and threat assessment perspective. This is much more tuned to are you delivering with capability that allows multi-tenancy, allows auditability and things of that nature. And then the last one is user experience where manageability was the operator experience of making service easier to consume and deploy and operate. User experience is actual features and APIs that the people that are consuming OpenStack and deploying instances on top of OpenStack and using the cloud. These are features that enhance their experience i.e. give them new capabilities like snapshots or extending volumes and things of that nature. So this is a much more meagre. Yeah. Before we go on I wanted to see a show of hands. How many folks in this room have read the community-generated roadmap in the past? Oh, some, some, not everybody yet. One thing we've done in this cycle is we've completely revamped the way that we play show and tell with the data. And so using the themes here, we're gonna show you several different views of looking at the themes that Shamile just described. First of all, we do it by theme. And so I'm going to show you a series of slides. Each will have the same projects, right? All of the contributing projects. You remember the top line is projects that have adopted or that are adopted by more than 50% of clouds according to the last user survey. Then the middle line is lesser adopted projects than bottom line. We don't have data on those projects adoption. But these folks are focused on user experience which was again and again the number one theme that the projects indicated. These projects indicated they are focused on manageability. So for example, if heat is near and dear to your heart, by the way, you can just kind of focus on the same area of the screen as we click through and then you'll see where heat, for example, shows up. And then where they might have indicated it was a minor area of focus or not an area of focus in which case they're grayed out. These folks were indicated that resiliency will be a major focus for them in pike. These folks focusing on scalability. Here's interoperability among projects as we were describing. And here's modularity. And before this all gives you whiplash, I can assure you that we've added everything to openstack.org forward slash software forward slash roadmap. And so you can download this community generated roadmap as well as quite a few other assets that support your roadmap or your view. And then here's security. And at first blush, you're thinking, wow, folks aren't really paying attention to security but how might we add color commentary to that? Well, that goes back to the definition of the theme that I gave. Again, these are features related to security. So these are not, you know, OpenStack. OpenStack has a security team that constantly looks at, you know, a set of et cetera and figures out what are the vulnerabilities that are being published that impact the code base of OpenStack. And then they'll, you know, tell the project teams that hey, we have to figure out a way to patch this and they'll work on that. So that OpenStack security teams guidelines and security patching requirements are not what's being shown on this slide. What's being shown here is again, feature delivered related to security. Yeah. I see that we have a question over here but I need you to speak into the mic or else I need to repeat after you. And as you're walking, I'll also add that this is the first time we've ever asked projects whether it was a major focus, a minor focus or not a focus in the past it had just been binary. Do you do this or not? Sure. So I definitely like the title approach that you have for outlining different areas. One suggestion I make is you're just highlighting the majors on the previous slides. If you mute the icons with the minor focuses, I think that will give more holistic picture. Ooh, well, I have more for you. So thank you. That's a great suggestion. We actually want to show you another view of it because in this case, we're showing you major and minor areas of focus. And this specifically is, oh, sorry, here, this slide. This is the Pike cycle release. And so the dark blue is the major areas of focus and the number of projects that indicated each of the themes. The light blue is the minor areas of focus. In the orange, these projects specifically said this is not an area focus for us, whereas the gray, they just didn't have information or it was not applicable to their project. And so that's how we distinguish between those. Going forward, we can also look at the Pike cycle. Here is the Queens cycle themes. You can see how they're shifting and changing. And then what I did on the right-hand side of the slide is I'm showing you their ranking. So first, second, third, you can see user experience again is number one in Queens cycle and then resiliency pops up to number two in the Queens cycle in terms of the number of projects that indicated they're focused on that. And then for Rocky, you can see we have a much less detailed outlook because about 30% of the projects indicated that they weren't quite ready to forecast as far forward as Rocky, which is in plus two for the releases. But you still kind of get a sense of where these projects are focused. Actually, I think it's n plus three from today. It's late too. It's n plus two from what's being worked on. Second half, 2018. Yeah. That's a long time away. So the key takeaway is from what we just showed you where the idea that user experience will continue to be a top area of focus followed by manageability, resiliency, and scalability. And we had 83% forecasting for Queens, which is pretty darn good giving us n plus two and then 70% for n plus three to Rocky. We also wanted to, we added this analysis and then we took those themes that we just showed you and we pushed them together so that you could get an overall look at development for the next three cycles. First of all, let's just look at the major areas of focus and that's what this looks like. So that's compounding the next three cycles worth of development all together. Then if we take major and minor together, you can see that this chart gets a bit more moderate, but you can also see the minor areas of focus. So, did you wanna add any last thoughts before we take some questions? Well, I guess one thing we're always, as the product working group, we're always looking for feedback, both as this is a good way to present the roadmap, but more importantly, are we looking at the same things that this roadmap is for the right things that the roadmap's trying to represent? In other words, are we focused on the right areas? Are the projects working on the correct features? What are the inhibitors that are preventing you from deploying some of these other projects? So we'd encourage you to always try and provide feedback to the product working group, subscribe to the mailing list, see what's going on. We really wanna hear from you to direct this better. And then in addition to what we have just shown you, we also have individual level product views. And Shamile, I'm hoping that you would talk a little bit about what it looks like for an individual level because we have 24 of these bad boys behind the scenes when you go to download. So what you just saw was the abbreviated version, trying to condense it into 40 minutes, as well as give good directional insights in a very high level manner. But in the published roadmap that's on opensack.org, we actually for each project, we have a slide like this that shows the exact feedback that we got from the project team. So it shows the three or four things they're working on. It has a paraphrased description of what that means, trying to keep it non-technical as possible. And then if you're interested in the technical details, we also have a link to the spec or the code review associated with that feature. So you can see it in all those aspects. On the top right, we also have stats about the project. So you can kind of see, how many people are contributing to it? What's the adoption look like in the latest survey to kind of give you a good guidance on, okay, what's the velocity like in this project or what's the growth trend here? And then likewise on the bottom right, we show if we have details from the team on what things they told us specifically about Queens. So when we do this, by the way, so for Pike we wanted features and themes from the teams. When we get to Queens and Rocky, we ask them, if you have features, please let us know. But if you don't, we're perfectly fine with just theme data, if that's all you can give us. And that's why not all projects, as you see, have information in Queens. But this is all accessible online. And the way I use this is, I use this more as a reference. So if I have my cloud deployment and my OpenStack cloud has nine services deployed, I usually go look at this view for each of those services just so I can get a more intimate view to my deployment of what's coming down the road. Exactly. So we save time for questions because we'd like to have this dialogue with you. We also wanna note that we talked about evolving the community-generated roadmap in the forum yesterday. So you can go to the etherpad and learn a bit more about what folks are recommending because we are definitely open to considering a more bi-directional view of the roadmap. So do we have questions? And I wanna encourage you to come up to the microphone to ask them, even though I know it's scary, but otherwise I have to repeat your question. So I know what he's asking questions. Oh, yes, please. So you have described quite well the process and how you display the information for existing projects based on information from those teams. Is there a similar process for determining what actual projects exist or not or may want a significant enhancement of one kind or another rather than solicited features? So I think we do. So part one of that question, as far as being able to figure out which projects exist and don't exist from a service coverage perspective, there's another resource on opensac.org called Project Navigator. And if you go to a Project Navigator, that actually shows all of the different opensac projects, along with what we're calling eight maturity indicators. So it'll show you how many packaging types does this service have, as far as RPM, Debian, et cetera. It'll show you does this have an install guide? What's the adoption rate? How many SDKs are supporting this service? And so that is a good view of getting a feel for, does the service I'm looking for exist in opensac or not? The second part of your question, which was how, instead of just getting the feature list, how can we talk about the areas of needed focus, if you will, or enhancements? And that's where the bidirectional comment comes into play. The conversation we've been having now is we have a very good working model now with this survey and how we collect this data. And so our thought was, if we can get the user survey, gleam some insights and requirements that our user needs from that. And then as we talked to project teams, also asked them, hey, in the user survey, complexity was a big thing. Can you please give us some directional guidance on what is your team gonna do to kind of address that user requirement? And so we're hoping that's a start of a bidirectional bridge, but that topic just literally started yesterday. So it's a work in progress. We have a question. So in relative to the release itself, like you're already looking at Queens and then Rocky, like what is your timeline and how much pre-release do you actually reach out to the PCLs? And I know you said like for Rocky, so some of them aren't that forward-thinking quite yet because it's still N plus three, but when do you start those conversations? And what do you see is like the peak timing, I guess where you do get the most responses and you consider that the threshold for that community roadmap? I can speak to that. Okay, I'll start anyway. In this case, we reached out to the project team leaders about two to three weeks before this event where we knew that during the project teams gathering, in this case in Atlanta in February, teams were really just meeting to figure out what they were going to do for the pike release. The Ocata release landed at the same time in late February when they had the project teams gathering. So we've passed the first development milestone just before we reached out to the project team leaders to ask them for their input. And then we were asking them for input on pike as well as development themes for pike, queens and rocky. I think this is a really excellent time to be able to deliver the community-generated roadmap because in the course of the forum events, people can really debate the strategy and the key choices. Do you wanna? Yeah, and I think just to amplify on things, I think all three of us have said already is we're trying to make this more bidirectional. And so obviously the best time to get feedback that we then take to the project teams is before the next PTG. So as they really sit down to map out what's going on with queens, they have a reasonably good list of, hey, this is what people think are the pain points that need to be addressed in OpenStack. So again, we're trying to drum up support for give us some information as opposed to just stand up here and say, well, this is what happened, you know, like it or leave it, you know? So I have a perspective here as well from maybe in this instance, and we're first time talking about this topic, but maybe there is a cadence change that would be beneficial. So from audience perspective, how many people, I don't wanna rehash the topic for people to know it, how many people are aware of the recent changes that have happened to OpenStack software in terms of release cadence, forum, PTG, and how these things relate? Do people feel comfortable with what's happened as far as forum, PTG? Okay, so I'll do a brief summary then because it seems like it aligns directly to the question that was asked, which is in the past, when we had an OpenStack conference, we would have a thing called the Design Summit, which is where the project teams got together and planned what specs and blueprints they would work on in the next release cycle. But the challenge was the release came out when the summit was happening, and so there were no users on that current release of the project because it just freshly came out. And so what happened, the first thing that we did was we shifted the release cycle to where the conference is still happening every six months, the release is still happening every six months, but the release now happens approximately three months before this event that just happened in Boston. And so what this means is we created a new event called the PTG, which is what used to happen in Design Summit as far as figuring out what the plans are for work in a given release, happens at the PTG, and then at the forum, which is this event, we're actually talking about what should we do in Queens? So basically it decouples where the requirements are gathered for what the priorities look like from the planning of the actual sprint, if you will. And so that's very powerful. And then also because the release cycle shifted three months, we have more users at the summit that are actually on the latest release than we've historically had. Now coming back to the cadence of what we do, we've historically aligned with the summit, like we just collected data two, three weeks. It might be interesting for us to align with the PTG and say, okay, when the PTG is concluded, we'll build the roadmap because that'll still give us the same data that we got right now, but it would allow us to come into the forum and have insights ready to share with the team as they're planning. I agree with that. We have time for one more question, I think. Yes, hello, yeah. I'm currently a PTI internationalization team, and how can I say, now I am offering some programs in our team because translation ratio is getting lower and lower and lower. Previously, in Horizon, let's take an example in Horizon. In Horizon, currently more than 10 languages are supported, but the problem is after new religious and new religious and new religious and translation ratio is getting lower and lower. But so, in my opinion then, some participation from translators would be possible with the support of not only just from developers, but in my opinion, some users can contribute to translations. But the problem is that in the morning, there was some discussion in forum, which part of translation of the tech project, for example, Horizon, Newton, and Nova, is important, have more importance or less importance. For translation team, we defined our priority just based on the feedback of translators. This is the current status, but in my opinion then, defining our priority based on some feedback from user survey or based on community roadmap would be a good idea to receive more feedback from general users because I have no state statistics. How many people are currently using translated Horizon for Chinese, Korean, Japanese, and so on? So what would be the best way for translators to better translate and more encourage users to participate in translation? So this is my question. Thank you. I'd be happy to take that, but okay. So I think one fantastic way to do that is to contribute to the roadmap. So we'll make sure to include you in these future, or include the translations and internationalization team in future requests for the roadmap. Just like we explained with the documentation, stuff which really impacts people across the board, we have the opportunity to discuss what direction the translations team wants to go and also create that bi-directional feedback coming out of the user survey for where the pain points are for the users. And furthermore, I would say a good next step here would be to contact the user committee, which I'm a member of the user committee as well, but we might be able to help you gather some data around what's the prioritized list of areas because we have mechanisms through the local user group meetups as well as within the community to help collect that type of data. So I think that would be a good step as well is to contact the user committee and ask your question and ask them for help in getting an answer for it. So we're all out of time. Were you just gonna say that? No, I was just coughing. So we're all out of time, but we wanna thank you for your time and attention in joining us to talk about the Community Generated Roadmap, and we'd love to talk to you after when you're done. So thank you. Thanks.