 Good morning everybody. Can you hear me okay? Great. Thank you. So thanks for coming to the session today to talk about the state of OpenStack product management. The content that we're going to talk about today is put together by a work group that formed fairly recently called the Product Working Group. And myself, or Kati and Sean are just the spokespeople here today for that group. We'll have information about how you can get more information on the group and join and start to work with us on driving a process and helping to develop product management inside of OpenStack. My name is Carol Barrett and I'm from Intel. Our Kati is from Dell and Sean is from Aconda. We're representing just the team and the team itself has a very broad participation of members. A good swath through the community, bringing different viewpoints on products and services around OpenStack and looking at the global marketplace. So we're trying to go ahead and really embrace the broad set of people and companies that make up the community here. Some of you might have heard of conversations around hidden influencers. This started out of Atlanta, the Atlanta Summit. And then in Paris, there was actually a bird of a feather session where there were a lot of folks who came together to talk about it. And it's founded on a couple of principles that are just sort of the reality of our community, which is that to a very large extent, OpenStack developers is a corporate sponsored activity. Companies like Mine, Dell, probably many of yours, go ahead and actually pay our salaries to contribute and help develop OpenStack and to bring this capabilities to a reality that people can then go ahead and offer out to customers. And that as developers, we operate within the context of our companies. And so making sure that what we're committing to do and what we're doing is aligned with what our management expects us to do is important. Because with their support, we can be successful. But if we make commitments and our management thinks we're doing something else, then that's going to go ahead and cause problems. And so that management in that support system is what was referred to as the hidden influencers. The people who would go ahead and help to set our priorities and be the ones that would provide us direction in what we were supposed to be developing. And so lack of the project management again was a reoccurring theme. And so this work group and these sessions here in Vancouver are all about trying to reach out to these hidden influencers and the product managers inside of all of the companies so that we can come together and talk about requirements and needs and how do we go ahead and put together a roadmap for OpenStack that can be a focus and something that we can all work to that covers multiple releases. So the mission of the product work group is to go ahead and I've heard it referred to a couple of different ways over the last, I guess it's really only been two days. So is the collector and the aggregation point or somebody referred to it as a triage point for where you go ahead and bring together lots of different parts of the community from the technology developers to customers to operators to ecosystem partners to understand what the requirements or the needs are inside of OpenStack and be able to translate those into use cases, epics, themes that can then go ahead and be actionable by the development community. So the things that we are looking to deliver in support of that mission is one is socialization. So sharing information and reaching out to the community to get more people involved so we have a broad set of use cases and requirements that are the basis for creating a roadmap. Then the next part is actually creating a roadmap in a collaborative and open way and then from there making sure that everybody has visibility of it, and that we can go ahead and drive alignment around it and then the last piece is really providing a infrastructure for being able to execute to it so that we can predict what we will produce as a community and then actually deliver to it as well. So we have sort of a three phase attack to that mission. So phase one sort of brings us here today. We've gone ahead and looked at a lot of the available information from the projects in OpenStack and then had conversations with various PTLs to create a roadmap of what we know to be the plans for as we stand today around Liberty and M and Kilo. Kilo is the easy part obviously. The next step is to go ahead and create a process, a repeatable process that allow us to aggregate the feedback, create the use cases and be able to go ahead and translate those into actionable blueprints, specs and other materials that drive the development side of the house and then the last one is to actually implement that. We have a goal that I think actually was provided to us by the board in the conversation from a couple of months ago of trying to publish a multi-release roadmap for OpenStack for Tokyo. And so the conversations that are happening here at the summit are to go ahead and help us to get further down that path. And with that, I'm going to turn it over to Sean. Thank you. So slight correction, it's not a big deal, but this is actually the foundation staff. So the marketing and the release team manager are the ones that are really interested, but they're employed by the board, so that's pretty close. But anyway, yes. So where we're going with this, that first part where we started gathering lots of data, part of that was that we wanted to introduce the concept to the projects and to the technical community. It's very important that everyone understands that this is not meant to be an additional burden on anybody. It's actually meant to help. It's meant to be a conduit for information. So it's important as a first step to actually go out and make sure that all the information that would go into a roadmap, if it is published, we gather it, or if it's not, we collect it and we repeat it back. And that was really our first step was to do that for this summit, was to start to repeat back what we saw as an early version of the roadmap. So this isn't meant to be a roadmap per se, but this is a good, where's the clicker? I get it there. Yeah. This is not meant to be a roadmap per se, but this, just by collecting the data and the necessity of displaying it for y'all, then it's starting to look like something like what the roadmap could start to look like in the future. So you start to see that certain things that we were calling themes are represented by where they intersect with the different projects and the state of those things within the projects. So, and this is based, this is an example, but this is based on data that's been collected over this last release. So dig down a little bit closer into a few of the things and call out a few of the projects so you start to see how the data we've collected, obviously there's some gaps because not everyone has been able to provide all the information for what's planned for the next release because it's a new process, new way of planning. But you start to see that some of the teams have actually provided information and so as we go forward we'll collect more and more of that, more of the teams get into the synced of working with the people that are, the development managers and the product people that are actually developing products based on the OpenSec project. So this information will be more and more complete as we go forward with the intention over this release that we'll actually have enough information to project over multiple releases at the Tokyo Summit and we'll present it. So this is again just diving down a little bit tighter into one of the projects and providing a little bit more detail. So this might be a good segue, I forget what's the next slide after this. Okay, so there's a good segue that things are moving really fast, which is a great thing. We had a couple of really great sessions yesterday. There was actually a lot of good discussion about tagging, which is something that the technical community has been talking about as a replacement for the integrated release. And that happened between the TC, the technical committee and the board on Sunday. And as one of the things I just wanted to call out as we've gone through the last couple of days it became obvious to me that we're at the right junction point where the work, the good work that Rob and the team has done on Defcore is really coalesced and has a good workflow. The technical community understands it pretty well. It's starting to spin up. You start to see the results of it actually being published. That's really talking about the very stable, the very interoperable pieces of OpenStack. And those things are always going to be somewhat in the past or the things that we're relying upon to be their rock solid. That's a better way of putting it. So as we're starting to do the project and looking forward into features that we want in the future we're actually talking about what's going to be in the bleeding edge. OpenStack is a very open garden incubator bleeding edge development effort. And this is really looking forward to what's going to be really on the bleeding edge of what we're doing. So this begins to show how Horizon is going to be on the bleeding edge of features in what's hopefully other products that are going to be based on Horizon can start looking at that and saying, oh, that meets my needs or oh, it doesn't. I need to go talk to the Horizon PTL and see if I can get that on their schedule. So what point do I hand off to you? Is it next one or this one? Okay. Sorry. So what are we doing here? We're partially part of the reason why we're here is we wanted to communicate as much as possible so everyone knows what's going on and we can get new ideas, but also we want to get more people involved. So this was very much an effort when Rob, Allison, a few of others of us got together back in Oskan like about, I guess, a year and a half ago now to talk about hidden influencers and how we saw this gap. It was really spun out of the gap that was identified for the operators, which was about a year before that. We started running the operators groups to fill that gap to start getting information and Carol and the Win the Enterprise team spun up to actually start to use that information that was gathered from the operators and to feed it into blueprints. This, what we're doing now is starting to close the gap on all those things. So what we really need is more participation, more so we can communicate better back up through the people that are maybe loosely affiliated with OpenStack but also the ones that are really heads down working within the projects that maybe don't have the time to really see what's going on in other projects that have some dependencies on them. So that's basically it for that part. What's the next slide here? Okay. So, Katie, we'll take over from here. Welcome everybody. So the kind of the goal of our group started is basically collecting information from all of the different projects and trying to have a kind of cohesive view of that which is more targeted toward the end user community, the application developers, the operators, the end users. They're all asking kind of the same question, you know, here is my use case. When will the OpenStack be ready for me? Tell me what other things need to be done to make it ready for me. So as a part of that we start first of all kind of the most obvious thing is okay, let's make sure we have a single way of correlating all the information we collect from all of the different projects and there is already effort being on the way for the board, you know, the community to pass it back. But it was passing back as here is the new features which we are releasing in this release. Well, you know, how do you correlate the features with, you know, the end user story which they're interested in and how do they know where it's in a pipeline across multiple projects. So we start collecting the information, we start kind of correlating the information, putting them all in a unified way and then, you know, the next step is okay, all of the project working on something, you know, how do they prioritize what they're working on and how did it have some kind of correlated way of looking at that. So we talked to all the PTLs, not only to collect information but also kind of understand better how they're trying to make the decision and the big feedback we got back was, you know what guys, we have no desire to make, you know, those kind of high level decision what is the right priority across various use cases. You know, obviously, we have, we must have people working on that but across all of the different things people would like to work on, we don't want to be in the position to make this judgment call because somebody will be happy and somebody will be unhappy. So we would like to have a much more formalized process which consistent with our openness and consistent the way we run OpenStack. And thus they said, okay, let's start correlate the style which will go not just from one release but kind of a cross release so we have a longer term roadmap and help us, you guys go and figure out what are the key things which, you know, are required for the, you know, larger community and you come up with a proper process such that you can help us to prioritize what work to be done. We'll figure out as, you know, as a PTL as we have a cross functional meeting where we coordinate between ourselves, you know, we'll deal with the specific technical work need to be done, you know, as a technical depth before we can maybe address some of those stuff, we will take care of that but kind of directional what kind of high level features need to be done across multiple projects, we would like your help for that. So we started, you know, the obvious thing for us is how do we go and collect the information about the requirements what people want to. Well, luckily for us, where most of us came from from different kind of user community. There is a user community, there's Enterprise, there is Telco and all of those, you know, different groups which are collecting their requirements and bringing them to the development community. So the obvious thing is, okay, let's start correlating them and let's try to see if there is something, some kind of use cases across different workload if you want to call them or different verticals which are resonating again and again because everybody that means that everybody needs them and those are the ones you would like to push forward first because you cannot address a thing without addressing them but addressing specific one which goes across multiple different different segments allow us to have much more buy-in by the community. So we kind of created the process which we are put in place for that and now I'll try to kind of go walk you through that process. Again, all of, you know, we are open source projects so everything is, I wouldn't say subject to change but we'll augment the processes, you know, to make sure they fulfill the requirements and making sure that we can deliver them. So the first one which we actually delivered for the end of the kilo is we collected the data from the community on the different, call them themes and the use cases and bringing them together. The next step which will require some of some additional work on us to set up the place where we can start creating the use cases and go through the formal process of accepting the input from the community, formal review, making sure that we have enough details which we can start generating the blueprint out of that as the next stage is delivering to the project. That's kind of the work which will have to be done and we are targeting that for the next summit delivery for Tokyo. Then, of course, a formalized process of doing the reviews and votes and everything else. We are, you know, another project is in the community so we are following all of the rules. And based upon that, you know, we have the process established so we can do the votes and then bring forward, you know, the one switch bubble to the top. The second one is, you know, we go through the, you know, communicating what the decision has been made. Bring that to the summit so the much wider community can see it across the board. And then from there we start doing the development work with the engineering community directly so we start creating the blueprints for individual projects which are part of required work to do the, to be able to satisfy the use cases. And we are linking them back to the use cases. If you go to some of the design summit, you will find out that several of the project already without having the formal concept of the use case, they kind of saying, okay, if you submit the blueprint, do write down something, why is it interesting? What kind of use case you're trying to cover without formally defining what the use case and without formally trying to go across the projects. So, again, this is where we are coming and trying to help the community to get all of this stuff done. Finally, of course, we, you know, create a blueprint and, you know, we create the specs for that and driving them through the different projects. And most important part, the influence, using our influence within the companies to dedicate resources to actually do the implementation because one thing this community will not accept as giving them requirements without the designated people and the resources to make it happen. It will be, it will be a complete disaster. So, once, you know, the things are in place, then we work with the PTL, so the first and the last bullets are not actually delivered by us as a group, but delivered by much larger community. So, we work on individual project with PTLs to make sure that work is lining up to the milestone of the releases, making sure the work is being done, and we are continuously tracking that work and bringing it back to the community where the state of the work is. And then when the work is being completed, we can update the roadmaps and bring it back that now we have a functionality which is available or what are the missing pieces and when we'll be able to cover it. Any questions on the process? Again, that's open. I mean, that's another project as a community, so everybody operates, you know, it's an open project. Everybody can submit use cases and the themes and so on. Yes. So, the answer is both. For this third stage, it is monitoring and bringing back. The first two stages is defining the use cases and disseminating them into the actionable item as a blueprint and the specs for individual project to work on. And working, there is a cross-functional working group where all of the PTAs get together and kind of talk about what they're doing, and this helps them to make this cross-project interaction. So, it's definitely not going to replace them. So, the best way of thinking about it, that the blueprints, they can be in isolation, you know, we need to pay technical debt on various things. So, let me repeat the question. So, how does the blueprint, the current model blueprint and the specs correlate with what we are proposing with the use cases and themes? For the future, anybody wants to speak up if you can use that microphone so it will be properly recorded. I'd appreciate that. So, the blueprints and the specs, what the themes and use cases provide, it provides us ability to correlate multiple blueprints which have to be working together to provide the, you know, the value to the end user. So, they're not replacing it, but, you know, talking to, again, this is work in progress, talking to several of the PTAs and various project, they're looking actually to ensure that when you're submitting the blueprint, if the blueprint is part of some of the use cases, then you have a pointer back to the use case because the use case is, you know, another part of the community delivered thing. So, not only we can track things better, but we can correlate the things that are part of one unified use case. So, I wanted to add something, just the intent of, well, when we started out this idea, we all had slightly different objectives that aligned. Mine was that I wanted to get the guys that are building products based on the OpenStack projects to start sitting in on the design sessions and actually understanding what the devs, in a lot of cases, are employing to build the OpenStack R&D projects that are going to go and be consumed by their products, actually understand that at a very conceptual level and actually be able to say, well, I need this feature in, you know, two years or six months or whatever, rather than doing it in arrears, which happens a little bit too often. So, that's part of what we're looking to do here is to actually get that kind of continuous feedback loop for the side of the house that's making things that employ the developers that are working on the R&D projects to get more involved at the very early stage. So, I hope that adds a little bit more color. Hey, guys. So, the part that I wasn't very clear on was who is actually collecting the requirements? Are there people like us who are collecting requirements and feeding them into you guys or how does that process work? I can take that. So, this first go-around, it was us. So, when we had our mid-cycle in January, as we wanted to get started, one of our... we've created some sub-teams that focus on different things. One of the sub-teams focused on just gathering information. So, this go-around, it was us. But what we intend this process to be is that they'll actually be part of the release cycle and through working through the cross-project team, which is essentially most of the technical leadership of the projects. It would actually be a cycle where they would, with product management that would be involved with this effort, all be dumping in use cases into the hopper and essentially prioritizing and filtering out the ones that would go into the roadmap. Does that make sense? It does. So, are you then looking for project-specific requirements? So, to give you an example, I come from a storage background, right? So, there's a lot of space here and Swift and things like that, right? And I feel that I can add most value in those areas. So, are we looking for people that have certain expertise around the projects so that they can bring meaningful feedback? Certainly. So, there are going to be... there are going to be certain use cases that are going to fulfill your needs, right? And so, in what those use cases generally are, there are various discussions with some people. We can call them multiple things, but they could be a use case, it could be called a really large blueprint or an EPIC. So, what the use cases are meant to describe are a list of features. And we're talking about calling those things themes that go through many projects and many different use cases so we can help highlight them through some kind of eventual UI that would help to describe the roadmap and so people would be able to filter down and really drill down into what the roadmap means to them. So, getting back to if you have specific storage-focused use cases, you getting them in and submitting them just like anybody else, that's our intention to be able to allow anybody in the community to be able to submit use cases. Ultimately, the project technical leadership for each group, they're the ones that are really responsible for delivering the next release. So, their job is not going to change. All they're going to get is more information from somebody like you that perhaps in the past they wouldn't have, it would have been harder for them to filter that into their priority list. So, now we're going to give them the opportunity to hear your voice. So, starting with the Liberty, excuse me, the Tokyo Summit, which will be for the M release, which hasn't been named yet. So, it'll be starting with that. So, the intention is we haven't worked out exactly the details. I'm with some of the discussions we've had over the last couple of days, I'm optimistic that we can actually use the concept of tagging and work that through the TC and the projects and DEF core and make them all very similar in the way that we're talking about interoperability and brand awareness as well as what we're looking to in the future. So, we haven't quite worked out those details, but definitely that is when we're planning on presenting the work of this summer, which will be to work out those details. Thank you. Community, so I can, you know, share my perspective. You seem to have a very top-heavy approach, kind of giving directives and I see, well, talking to the PTLs and so on, I see a gap between that and the reality, you know, what's currently happening and to an extent open-source traditional development and, you know, let's just assume that I'm supportive and I see value in what you do, but how do we bridge that gap? How do we work together? So, this is not meant to be anything but a communication tool. Right now, it's actually from the PTLs to a broader, to the product people that haven't been really engaged as a group as much as we would hope, which is the real general reason why we started this up. So, going forward, it will be more of a community effort of the product people and the project leadership as well as the technical community, deciding as a group what are the priorities for, that would go into the release roadmap. It certainly wouldn't change the way that Teri and everyone, the product, the project technical leadership, do their job today for the next release. None of that would change and we're not proposing any of that change. It's just to look for beyond into the future to give more information to those that are building products on top of OpenStack. So, they can either just consume the information or they could be a part of the delivery mechanism to get their voice and their priorities into the technical leadership. Now, whether or not they accept it, that's up to them. So, is that... So, we're trying to define the process and we could really use your help to understand what that gap is and how do we go ahead and integrate these things together so it's continuous and whole. That's the intention. And so, ways that you can go ahead and help us to understand your viewpoint and what we need to change in order to make these things work more harmoniously is to join us on the mail list, join our discussions where you can find the information from the wiki, grab any of us here at the summit during the course of the week so that we can go ahead and continue to evolve the process. This is what you saw today is just a current draft. We've had a series of sessions yesterday and then this today and there'll be more throughout the week where we're trying to gather that type of feedback to figure out what do we need to do to change and improve, simplify it and better integrate it into the flow of OpenStack as it lives today. Okay. Did I answer your questions? It's complicated. By the way, so you got a couple of minutes so you might want to... Alright, let's keep looking. Yeah, so the call to action to all of you is this is an effort across the community to help us to figure out what are the most important requirements for the markets that OpenStack is looking to serve and how do we describe those requirements and communicate those across the community so that we can actually make progress in delivering those to the users in the market, whether it's an operator, whether it's an application on top of the OpenStack, whether it's a user of the application, so that we can continue to drive the proliferation of OpenStack deployments in the marketplaces. That's really our goal. So please join the mailing list and join the conversation. We have... Every other week we get together. We held IRC meetings. You can find the information in the ether pads from that at our Wiki page. We've taken a draft at a template for use cases. Please look at that. Provide us feedback. Start to use it for capturing your use cases that represent your users and your markets and send them to us. We're in the process of bringing up a repo in the cross-project repository where we'll go ahead and store all those so that everybody can see them and be able to comment on them and help to go ahead and improve them and bring the details to them that make them real and make them actionable. So that is our call to action to all of you and how we'd like to go ahead and get your involvement in helping us to go ahead and make this real. So thank you very much for coming today.