 Thank you. Wow. So good morning. Actually, no, it is technically five minutes after noon. Who's so excited about missing lunch? Now, I'm actually really excited. Yeah, I know. I'm really excited that people actually were like, I'm going to miss lunch because this sounds interesting. So I'm really glad to see all you here. My name is Colin McNamara. I am a co-founder of OpenStack Training, a project inside of OpenStack to my left here. Sean Roberts, board director, co-founder of Training along with Colin. Yeah. Today, we're going to talk about a project that's really important to us and we hope will be really important to you. This project is called OpenStack Training. So to understand why OpenStack Training is useful to you and how you can grow through it and how maybe you can help your communities grow, your companies grow, and yourself grow, it's important to kind of introduce the people behind it. And there's a lot of people behind OpenStack Training, but we can't have them all up on stage. So Sean here mentioned, he's an OpenStack Foundation board member, I think for the past three years. No, not quite, almost two. Two years. Most importantly for me, he's the leader of San Francisco OpenStack. He invests his nights and weekends in helping the community become greater. Lots of late nights, works I think an hour and a half from home every other Thursday. Helping other people learn about OpenStack, connect together. A lot of the good success stories that you've heard today. Who's heard PayPal talk? Has anyone heard PayPal talk about OpenStack and SDN? You know, Vinay Benay. He came in, we both actually came in at the same time, got our first patch submitted at the same time and it's because of Sean dedicating his time to making this community better. It's Core and OpenStack manuals, co-founder of OpenStack Training, former Stanford slack guy, kind of smart. And was the chief instructor architect Yahoo? And now is making Yahoo more competitive by helping their software development methodologies and test-driven development become more mature for OpenStack. My name's Colin McNamara. I am a weird guy. I see a lot of faces that aren't classic, or stackers, right? T-shirts, beards, hippies, tattoos. I see sports codes. So I think he might be just like me. I am a CCIE, I'm a VCP. I am an OpenStack contributor, as well as a minor contributor to Open Daylight. I, three years ago, came in this community and felt at home and kind of re-engaged my open source self. I also am Core on docs and core co-founder of OpenStack manuals. I'm a Linux user, heavy Linux user since the late 90s. VMware users since 99. I hate it when people say OpenStack versus VMware. But most importantly, I'm the founder of an amazing beard and a more amazing family. So it's important when we understand and I'd like Sean to also chip in on this, like why we did this. So we spent probably 1,000 hours each over the past couple years on this? Yeah, easily. Easily. A lot of nights and weekends, a lot of times we pitching in at work, holding sprints at our offices, or holding hackathons. We're trying to solve a fundamental problem both in the community but before our businesses. And I'll ask a simple question. Who here wants or needs OpenStack skills in their business? Who here has been able to find an easy way of giving those skills to you or your employees? One person. Okay, I wanna talk to you. So when I first came to the community, I came in 2011, I had a major customer. They had seven major data centers, giant enterprise customer, and they stopped buying data centers. They said, hey, we're moving Amazon but looking at OpenStack. I ended up moving some of our own product direction to OpenStack and figured that for a company with half of engineers, that we have to do cross-training. You can't just buy people off the street. They're expensive. We tried and there's no one to hire. Our hiring pool is empty. And so business-wise, I had to go and solve that problem to run a business. Personal-wise, I couldn't figure out for myself. I mean, we were kind of coming together to try to learn this stuff just through relationships. And I felt that, and myself, that it was not everyone's so lucky to live in Silicon Valley. Not everyone's so lucky to have guys like Sean or guys like you and Miller or other mentors to help you. What was your reasons business and personal for doing this? So early on, as Yahoo got involved with OpenStack, we realized that a lot of our skills were compatible but there's only so many Python engineers in our company. So as we started getting more involved with OpenStack, we needed to go out to the community and found that a lot of them were already taken. So there's only so much poaching you can do from your friends and other companies before they say stop. So what we really needed to do is we needed to go look at our interns, our internship programs. And there's only so much we can do there. That's a very long tail pipeline. So the logical approach was to go to user groups. So one of my friends, even Miller, was running the San Francisco user group. And as we got involved, we realized that this is the excellent way for us to start pipelining new engineers. The side benefit is to evangelize OpenStack but the real money making part of it is that we need more engineers, qualified engineers and we need to continually train them, the ones that we have. And I think that just highlights a great thing that I hope a lot of you will come to as we go through some of the stuff is that there is an opportunity to identify this area where there's a business need for your corporation either to consume it but maybe possibly to contribute back. But then there's also a great way to be very good to the community. This is a great place where they overlap. So OpenStack Training itself, the goals of the training itself, there is an upcoming certification program that's been worked on. It's being developed. Being developed, yeah. We don't have a deadline yet or a date. No deadline. You can pay us as, no, you can't pay us, we're community. Pay us with beer and coffee and it might happen, right? But there's certification programs in the work from the foundation, from the Linux foundation. Even manufacturers like Cisco are expanding their CCIE to encompass OpenStack. So we wanna align to the different certification programs that things that engineers use to kind of benchmark their skill, to be able to see, to create a learning map so they can be better. We wanted to increase the pool of hiring engineers. And a very important thing to me, I actually grew up as a poor kid in a farm town. Single mom worked at a rug factory and got a job as a secretary. I was intellectually gifted but economically disadvantaged and someone gave me a chance. They gave me a job putting PCs together in the middle of the night and it taught me. We can do something with education that changes it fundamentally. We can challenge that establishment and we can give it away and give other people chances. And I think one of the great success stories is Pride Pranav where he's doing really awesome. He actually taught seven professors in India this course a couple of months ago. Yep. The metric I'd really like is to, I don't know exactly how we would do this other than just people like ourselves supplying the metric but I know of eight people that we've helped get new jobs through our user group. It didn't seem like a lot but that's- That was huge. That'd be great to expand that and be able to find people new jobs, help do skill transition. I mean that's pretty exciting result. Oh, apparently the draw lunch was too much. I'm sorry, I would have bought you food. It's okay, I'm not hurt. I'm holding myself. Actually now I'm hurt. So no, that's actually a really good thing. So in person, and I've done whatever I can to support Sean and support the user group in Silicon Valley. It's helped me. It's helped my career a lot. It's helped me help others. But outside of where we can touch people in person, we need to help other people help people. So the other things is we know lower the barriers of entry. When we joined, you're probably, you're ahead of me, you're at the inception of OpenStack. Yes. I was at Essex when I started working with it, which for those who aren't too familiar with it, kind of late 2011, the barriers to entry and OpenStack are really, really high. Especially if you're like an invert guy or a network engineer, it's just like, you're like, what is going on? Who's felt that when you tried to figure what it is, figure how to install it? You're like, holy shit, you damn DevOps hippies. Right? And sorry if you are fitted by Cussing, sorry. But it's gonna happen. But we wanted to do that lower that barrier. It was hard. It was really, really hard. And it's also to increase the survivability and usability of docs. One of the challenges of having a project which is shooting forward so fast in features, there's thousands of new features that get added every six months is that to be able to, if you're new to it, being able to say what the heck is going on, right? How do you actually create training documentation, man pages that work, right? And have that survival so that we, so that what's called the adoption of OpenStack is not what holds it back from its growth. So we did decide to fix this herself. Yep. Right there, by the way, is one of the successes. That's Vanabe and I. I would suggest every single one of you to go and sit in his talks this week. He's does him and Ashwin. Do you all love the SDN for PayPal? Yep. They are agnostic and I love that. And he's a really, really smart guy. We actually got our first patch in together. And that's Sean. So let's go over a little bit over the course structure. So most important things, has anyone found OpenStack training yet? Okay, did anyone think that you had to pay for it? Good. Okay, two people did, you don't. So if you go to docs.openstack.org, this is a very important URL. All the information in the world, well, no, not all of it. The stuff that people will decide to write down is up here, right? So docs.openstack.org is very, very diverse and there's technical docs, there's developer docs. And I'm telling you, if you start somewhere deep, you might get lost in the weeds. Yeah, yeah, it happened to me. But more importantly, there's a little thing here that says get training. That goes to our project. And our project is our project. It's your project too. So I'd just like to throw in there. One of the things that we found early on is for the converted, like myself, we learned by being involved with the projects early on. So we were already initiated. We were already convinced. So as others were coming in, we're found that there was a lot of people that are coming in that had a completely different background, didn't have any experience with agile development or even what we're kind of calling agile computing. So that's, we've already going 90 miles an hour for some of these people. We start them off at the wrong place in a lot of cases to allow them to start to learn what agile development is about and how the training is organized is actually to help with that skill transition. Absolutely. So fundamentally, and this is especially if you're come from the VMware world or the Cisco world or the EMC world or the Microsoft world, we take a lot of assumptions about how we create services, how we create service catalogs, how you manage infrastructure. What is a virtual machine? Why do you use it? How do you consume it? And coming into the OpenStack world and learning about OpenStack is fundamentally learning about modern software development. Learning about a platform that accelerates that. And if you look at the overall, and as we go over the core structure, the program structure itself is very simple. It's for taking someone with basic Linux administration skills and helping them progress through a structured methodology of learning how to install OpenStack, how to consume OpenStack, should I say, how to just use it, how to install it, how to develop applications for it. And then our core goal in something we all wanna do in any of these projects is to actually have people contributing back to it, especially every single one of you as an operator. Every operator, everyone who's a user, is the most important person in OpenStack. And if you guys are empowered to go ahead and know Python, know the infrastructure, know how OpenStack works, and like, who's ever faced a bug? Like, you get a bug in VMware or your Cisco router. Who's ever faced that? And called the assistant center and they basically gave you the blow off. They're like, yeah, we'll fix it. Or maybe you had a feature that you wanted in it, something used for work. Anyone? Every day I get that. The goal is to provide people the power and the option of doing that themselves, of actually contributing it back, fixing a bug. It's not hard. So the focus right now, and a couple of major focuses. The most significant focus I would say is seeing our baby grow up. Yeah, right? So as we have gone through developing the training material, we realized that we needed to slow down quite a bit. Initially, some of the material we produced that came out to being hundreds and hundreds of pages and that's obviously way too much for anybody to digest. But one of the really important things that we've found is as the training is, we're developing the training that we really need consistency. And we needed to follow the rest of the release cycle which means a lot more hands, a lot more eyes. Yeah. So like in one of the things that are focused right now is actually why am I taking on time on stage? Why are you taking time on stage? The developer summit is going on right now. There are important meetings for us to be in. But it's important for the community to consume this stuff, to find what works, to find the flaws, to report the bugs, to help improve it. Use cases, when someone telling you, hey, this IP address was wrong, it's huge because you know what? There's a hundred people who face that bug and stopped, right? This is if you go, if anyone has a laptop, please go to docsupstack.org. It's available self-paced, by the way. It's basically a book, you can run it in your user communities. We actually have support for user groups through the, we're both ambassadors also. Yes, we are. Ambassadors, active technical contributors, core reviewers and co-founders project. Yep. And we need a shorter name for that. But the goal is to help lower these barriers. So you can do this yourself. You can take it to your work. This is Apache 2.0. If you want to take this and then sell this, you want to make your living selling open stack training? Fine. Just please. And I caught one major company that's on the floor today doing this. Obey the license. Don't cut it off. I've, some of you guys may have heard about me flipping on someone. But yeah, we need to protect the community. People do nights and weekends on this. We need to respect them. So the second thing that we're doing, so we want to have people using the associates course. This is how to consume open stack. A lot of people go right to how to install it, but have no idea how you actually use it. The current challenge that we're facing right now, this is actually really exciting. We're teaching people to consume open stack, not as an operator, like an associates, like how do I go ahead and work with Verizon? How do I go ahead and manage it? Like, you know, for a new guy coming in. But if you look at, so I'll say something, which is really weird to say an open stack summit. I and my development teams use Amazon so much, it's crazy, right? We also use other platforms. We use VMware. We use open stack. We're plugging in, the company just got bought two weeks ago. So I think that's a vCloud, the dimension data cloud. And I'm plugging into Vitchie if you'll ever please expose a pricing API. But the one thing that Amazon does really, really well is they take a developer who's learning to create kind of these web structured applications, these new applications, and they take them in training and they basically coach them through writing the first set of applications that consume Amazon. And so right now, we have the associates guide, which is consumable, which has been taught. It's been taught in India. Really looking forward to, and I think I might be able to do this with the new life is just travel myself to Saigon in Kenya and give it. There's actually, it sounds like our company has a school in Africa, a weekend school. So the developer training guide itself is go ahead and teach your developer. So who's an operator? Who's like an IT guy? Okay, who's a developer? Who writes applications for a living? Okay, and who's a unicorn? Yes, okay. I'm a unicorn. So I'd like to throw something in there. One of the things that we found early on is like I said earlier, we kind of started this already going 90 miles an hour, not realizing that we were. And as we started trying to teach more people through the user groups that weren't initiated or indoctrinated open stack, they realized that we had to take a huge step back. So we actually changed the training so that we didn't even really talk that much about Python code until the developer training. So as we go through what we're actually trying to teach is basic understanding of open stack architecture and the associates guide. And then when we get to the operator guide, we're teaching them how to install it and understanding some of the basics of the APIs. But when we get into the developers, when we really get into start talking about Python code and how to use the continuous integration that really is the heart of open stack. And so for the, who's a Python? Who knows Python? Wow. Okay, it's Django. Okay, it's like imagine if Python, HTML and XML had an orgy and came up with, that was a really bad word, sorry, it had a baby and it was like this hybrid Python, HTML thingy. It's what Horizon's written in and the really interesting thing is that by learning to build web applications in Django, what it allows you to do is start consuming the application, the APIs inside of open stack, which is what creates open stack, but also starts teaching you to go ahead and look at a reference. So Horizon is a reference. Horizon is the web interface to open stack and a lot of people like to complain about it. But it also, if you actually pull through the source code, it consumes and configures every single service inside of open stack. Every single, or most of them should I say, and it also allows kind of normal users to go and interact with it and visualize it. It's one of the methods that we're doing right now. I'm building in the developer course. Now if anyone has Python experience, Django experience, UI and design experience, really love to talk to you because this is really fulfilling and I think we could really do some good stuff to help with something new for the community. We're in the process on this. Yeah, we'd love to get you involved. One thing I wanted, I don't think I said exactly right, but we plan on having four bucks. We're working on the third one right now and as you would expect, it's escalating skills and knowledge as you go on. But I don't think it's really necessary for a lot of people that are involved with open stack to go any farther than the operator training. There's gonna be quite a few number of people and that's fine. You don't have to become an open stack developer. There will be a subset of people that want to do open stack development. But it's okay to be an open stack operator. That's a very important skill set. Yeah, and so, but also for those of you that are new to this, for those of you that are new to kind of cloud platforms, being an infrastructure, being an operator and being an infrastructure guy of a cloud platform does mean you may not be the best programmer out there, but you understand the APIs, you understand how it's consumed. You can fix code. You can probably find a flaw in the code and you're at least comfortable with it and so it's available to you. Hopefully we can all work together to help create this next step. I wanna talk about the methods that we have here. So what's really been interesting, I am a giant nerd. I am not an educator. By trying to educate, I found the flaws in myself and the flaws in the fact that I have a certain learning style that I am visual, but that I tend to, I build like a file cabinet of something that I start sticking concepts into. Other people, they learn by doing. What they do is they actually wanna do labs. Now I get to the labs, but if I can't visualize it, I can't succeed in labs. Now there's others like Scott here. Scott learns by teaching. He learns by writing down his thoughts and by, at least I've observed you doing it over the years, by going ahead and blogging about it and having that kinda like, oh, well I'll figure out enough that I know it. So what we've done is gone ahead and broken into three different consumption models. And there's a couple different user what are called archetypes. We have our self-paced book and that's where people all over the world can just go ahead and read through and go in those self-paced labs. This is the core thing that's out on docsopenstack.org. Now what I found and I was really pleased to see Red Hat offering some of the same content in their OpenStack training, which was really neat. Because this is what Open Source is about. I want, we want corporations to be able to make money off this. There's also community instructor led. And so this is about the user communities. I'm hoping one person out of here, two people out of here, if they do it's a success, will raise their hand and say, you know what? I wanna take the challenge of maybe over a couple weeks or in my own corporation, delivering this internally, right? So the methods for ourselves is the primary challenge we talk about is avoiding the content going stale. And you have to create survivable code. And what's interesting, the documentation project is actually we use software development methodologies. We use continuous integration. We use, in some cases, test driven development. I think we need to increase our test coverage of catching a failed inclusion. We have a heavy use on code reuse. These are things, by the way, that I've pulled from our learnings in the training and actually used in my own business. Our scrum, the reports that come out of our scrums are actually generated in ASCII doc in a pipeline. It's our PRDs. It's weird. We've actually, without intending to, we've come up with agile training, or agile training development. So didn't really expect to do that. I mean, we weren't trying to do something so audacious to try to come up with a new way of delivering training, but that's essentially what we've come up with. Yeah. And so what's interesting in this is that some of the lessons learned were able to share this with the Open Daylight Foundation. Who's heard of Open Daylight? Reference SDN controller, right? For OpenStack. So it's kind of cool, but we've also been able to take the lessons learned and move it over here. And the goal, by the way, is to start combining Open Daylight into this, at least my goal, in some of the higher end developer courses, so that we teach people how to properly configure SDN controllers, or not configure, but consume. And the whole idea here is that we want to be flexible, we want to be agile. We don't want to be old, right? We want to go ahead and do training a new way. We want to open-source it. And we are open-sourcing, it is open-sourced. It is free for you to consume and contribute and own. We do run it like it's source code. So if anyone writes Python, and who has done continuous integration, knows Git, Garrett, Jenkins. Okay, we've got a good number of people in the room. If you don't, this is a really consuming, you don't have to use modern software. But if you contribute back, it provides a safe way that you can start to build those skills of learning those tool chains. Which are important, those, by the way, those Git, Garrett, Jenkins tool chains, you will be using them if you use OpenStack in your work, most likely somewhere. In the developer course, I've had my teams at my own job, open-source project, Denica, which is a canned CI tool chain, Git, Garrett, Jenkins, along with an OpenStack installer. A lot of the pieces are upstream, we're still refactoring to get it so you can have a one-click framework. Just something that I saw that I could help my company, actually we got acquired, it was not my company, it's domestic data, but contribute back. It's something each of us can do. It's also a good opportunity for contributing back to start learning agile project management. Do you use ScrumBond internally? Internally in the project? Yes. It is, probably need to have a little bit more rigor. It helps. Well, it's even for something like creating a training project, when you have dispersed contributors, it's really important to keep track because Pranav works when we're usually sleeping, so it's really helpful to know him to be able to tell us what he worked on and what he accomplished via ScrumBond rather than having to send us an email, which he still does, but. Yeah. One of the important things to touch on is the lab of the second book, the Operator's Training Guide, is actually how to contribute documentation bugs and how to fix documentation bugs using the same CI pipeline that we use to deliver code for the rest of the OpenStack projects. So it's really without having to worry about your Python code passing the tasks and getting rejected. You can, this is a much easier way to learn how to use the OpenStack CI pipeline. It's hot, I'm gonna take my coat off. But yeah, I know, and it's kind of interesting. You will find a bug, they're out there, we all create them, and learning how to fix them is one of the, one things you can do by consuming this training. Now, so the current status for supporters, the primary supporters of the project is a community. Without the community, this would fail. Secondary, we have Yahoo Apptera and Nexus IS, a dimension data company. If there's anyone who wants to consume this, there's no, you don't have to buy in, but we'd love to acknowledge if your company supports you working on this to go ahead and add you to the page, if you do end up, or if you end up contributing code, time, focus, whatever. The challenges, it's worth, one of the things that we see a lot inside of the OpenStack summits, this is my fourth one in your sixth. Something like that, yeah. Is that everyone goes on stage and talks about how awesome they are. Everyone talks about how they, like, we rock, we did this amazing thing. No one talks about the faults, no one talks about what went wrong. It's, no one shares their lessons, and let's be really honest here, a lot of stuff has gone wrong, and we've had a lot of lessons learned and a lot of challenges. We've been able to grow through them, but I think it's worth talking about. The biggest challenge that we've had is OpenStack can kind of be an echo chamber. Well, it's the risk of any project that's going really fast, and you have a tendency to listen to yourself and your peers a little bit more than others, and that's dangerous. Yeah, and it's actually going and engaging the end users, and Sean and I first saw this risk a couple of years ago. I decided to go fly all across America and call all my friends into starting user groups. User groups in Denver and Minneapolis and RTP, and it said, hey, we need to get more engaged. But one of the challenges we've had in this project is that people are used to going to a training company, people are used to going to a technology company to learn. They're used to this construct. They're not even aware that we can invest in ourselves, that we can invest back in our companies. We can hold our own trainings internally in the community or not. Engaging the end users has been the largest challenge. And the second thing is challenging the establishment. There were early on, a lot of, I perceived them as challenges of companies that were making their money through building training. They were building their pipeline through the only people that had training. Getting out there and saying, yeah, we're gonna do it was actually really, really hard. You know, there's a lot of establishment where they don't want to break, they don't want to have you have control. Same thing with the manufacturers. I love the manufacturers. They contribute a lot of code. They make great stuff. It's 92% of code for OpenStack is corporate contributed. That being said, when the users control the training, they lose control of you. And so there's a little bit of pushback on that. There's another detail in there. I mentioned agile training. We've made a lot of success or a lot of progress, I should say, with changing the way that hardware and software is being delivered over the last four to five or even 10 years going back to Lenox. But one of the things that hasn't changed a lot is the way that people are taught. So by and large, the people who develop training have been doing it the same way for a very long time. Not unlike how professors produce content. So we're challenging that by saying, well, let's iterate faster. Let's do it daily, which is a big change, just like it would be to go with agile development. And one of the successes we had with this training, Carnegie Mellon, I think, is worth highlighting. I know I learned a lot from there. Yes, I did as well. So we got 10 minutes, we're right on time. And so Carnegie Mellon, their cloud computing program, is, you know, Carnegie Mellon's one of the best universities in the world. And in my opinion, oh no, I never went to college. But what's happening is that they're trying to teach OpenStack to their end users and we're trying to help them consume it and give it. And so Carnegie Mellon couldn't consume our training, right, and what it did is allowed us to improve, create the lesson plans, program structures, things that were consumable and repeatable, make sure that we were putting automation code that made it so a non-technical instructor, which is a professor, by the way. I hate to say it. I mean, some of them are really, really smart, but they're usually like academic smart, can go ahead and succeed. It's been really interesting. Challenging your assumption, challenging the establishment is good, but it was hard. Other lessons learned is absolutely infrastructure is important. Again, I asked if you use continuous integration, but it took a lot of work for us to go ahead and actually learn the CI systems. It's been great for me, by the way, and I mean, you're running like CI for Yahoo OpenStack now and that's a huge position. I guess it's been good for you. But learning how all the other infrastructure that surrounds training a project, and by the way, this is some of the infrastructure that is necessary to run a course. But it's been really, it's been a lot of challenges learning that, like the guys like Monty. If you see Monty Taylor from HP, if you see James, you see Clark, just tell them thank you, because those three guys do more to make OpenStack run in the gate stay up and us be able to make code than anyone else. Yep, they run the CI system and they're the heart and blood of OpenStack. Yeah. Wouldn't be able to perform releases without them. So other lesson is that the corporate support is essential. It's been a lot of community. We've had our corporation support, but we also have day jobs. I have a development team and a business process consulting team. They need to be managed. I don't need to be managed, they need to manage me, but they take focus, right? And so having, getting people, if you have a tech writer, if you have a trainer, if you're an educator in a school, oh my God, I wanna talk to you. That getting the support and nine to five support is really essential. It is really, really hard to spend all your nights and weekends. Like we need to be balanced, right? So what's next? I think it's really important to talk about. We need more contributors, right? Small work, small consistent work matters. We use Kanban or Scrum, we use Scrumban. It's a hybrid Kanban. Two cards a week, it's fixing a bug. You're giving feedback saying hey, I went through this course and here's what I thought. I went through it with my friends. Oh my God, so that creates bugs, that creates features. You're like oh, if you could do this, if we could do this. So we absolutely need more proctors. The community does. We need more students, we need more people using it. And I think I'm hoping that you need it too. Quality bugs and feedback, saying this is broken is great saying this is the fault that I found that broke my learning process on this is better. And it's all right, you can click, if you find something wrong, there's a little, it looks like a little red bug. Boop, you can improve the course. Like we've all been in those courses where it's all broken all the time and they say oh, in the next revision we're gonna fix it, but you never get to get that. Well now you do. Even better, it's great to submit a bug. I'd love it even more if you wanted to learn and we'd be happy to teach you or part of the team, anybody in the team happy to teach you of how to actually fix that bug and that's even more valuable. Yep, so most importantly, go to docs.openstock.org. We got a few more minutes so I think it's probably good either we can do a walkthrough or let's open it up to some questions and answers. So let's have an open discussion. Let's, anyone have any questions? Please walk up to the mic. I can talk all day. Or statements, statements are good too. Statements are good too. If you think this is crap, fine. I think it's awesome. I love hearing how awesome stuff is. I have a question concerning the certification program that's upcoming. So what type of, what structure do you have in mind and what type of exams do you have in mind? Is it more like performance based exams like Red Hat exams or maybe like Linux Professional Institute? So the foundation actually has a responsibility. I happen to be a board member. So, but the work I'm doing here is not with my board member hat. It's with my community hat on. So you may have heard of Def Core and the work we're doing with Revstack which is essentially putting testing behind certification of what is OpenStack and what can carry the OpenStack brand. So the very next step, it's not quite parallel but the very next step is to start working on training certification. So it really somewhat has to follow that. So it's been put off until that work gets done. So I can speak for, the part of the community is also the manufacturers. I do a lot of work with manufacturers like VMware and Cisco. Cisco is on the process of putting OpenStack in their CCIE program. And so the manufacturers certified too. I'm hoping more will do this by the way. And that is forthcoming and there's a couple other manufacturers. Cool, yes. Please. Next question. Okay, my name is Sheila and I work for Comcast. Oh cool, hi Sheila. Hi, and this is more of a statement. But sometimes I find, I do contribute to the OpenStack manuals and the documentation. And sometimes I find that I'll find an outdated doc or some content that is referring to Essex. And I'll make the change and I'll submit the patch and I'll get a couple of plus ones and then I'll get a minus one for please re-code this whole thing and then the change gets abandoned and then it just seems like it's hindering forward progress. So I agree with you, we're both core viewers on doc. So one favor. So Sean and Anthony at Comcast are really great guys. And I have a personal thing of being an Almasman for the operator. I'm trying to bring things over to AsciiDoc myself. It's a battle I'm facing so you kind of don't have to deal with XML inclusions with Docbooks. Can you add me and Sean as reviewers? Yeah. That helps. But one of the other ways of doing it is to get on IRC and again, this typically wouldn't be OpenStack Dev, it'd be OpenStack-Doc. And join the weekly meetings. And put your hand up and say, I have a bug that hasn't gotten reviewed. Can somebody please help me with this? That's perfectly acceptable. That's what IRC is there for. Yep. Okay. Who is first? Okay. Rogan Bowie. No, he was, he was. All right, so first of all, thanks guys for all the hard work. You're welcome. Thank you. Speaking as somebody who is not familiar with the process. You know, one of the things you said is that you really feel like you need more contributors and that's a fair statement. I would say the number one challenge to getting new contributors is the complexity of the contribution process. Yes, Rhee. Right. So my suggestion to you guys is I think there are probably lots of people out here who would like to contribute. Also have nine to five jobs, right? Yep. We need to lower the bar to entry. Agree. So horribly. To get the contributors in there so that we can all, and this is true. I know there's a session later in the week that Anne's running on lowering the bar to entry to docs so that people can get more involved in docs, which is another one I'm looking at. It's the same project. Both these cases. Yeah, both these cases. We need to make this easier for people to get it in there but also maintain kind of the quality that you guys are pursuing with the CI process. And this has been a challenge as Opensack's grown so fast. By the way, take a look at the Open Daylight documents right now, where it's going. Probably gonna model what I'd like to see here. But also if anyone writes for O'Reilly, the ASCII Doc plus Wiki interface, it's all consistent in the back, is one of the places I'd like to get to. And Red Hat's also doing something like that too. And that's part of the discussion for these multiple projects. I absolutely agree with you. And it's been my focus since I've gotten here. And you saw the title of slide, Lowering the Bar to Entry. I appreciate and value and agree with that feedback. Thanks. So thanks guys. First and foremost, I really appreciate you having this particular session. It's an area that's near and dear to my heart. One thing I wanted to add, well, two things I wanted to ask is, one, I noticed on the slides you mentioned a reference to more proctors being involved in the community. So kind of piggybacking what he was saying with there being a complexity to the barriers of entry and so forth. What are the things that we can do to help establish community educators to help grow that? And then the next part of the question is, how do we establish a culture of training within user groups, specifically new user groups, because I started the Columbus, Ohio user group. I give you applause for that. That's hard. So the first one was, how do you basically make it simpler to be a proctor and also reach out to the educators? Honestly, I've learned so much from professional educators. It is an art, it is a skill. I've grown, I've been able to be a better leader in my own business and better person in helping others learn. And it's those are skills that I had to learn and I would like to see more educators joining the community and adding that perspective as we add a technical perspective to them about user personas, about lessons plans, about stuff like that. The biggest thing I could ask as a user group leader, reach out to the, go walk to a community college, go find a steam science, technology, engineering, art, mathematics. Like at least 3D printing for at HacketsCon and find someone interested in that, who is an educator, and then ask them to help you. They love teaching and there's something to learn. It's, that's probably the biggest, biggest thing. And then once you've, you figure that out, share it aggressively and openly. We'll help you put it into repositories, we'll help you make that part of what we can do for everyone, put a course around teaching. We don't have a course around teaching. I'm not a great educator. I just have a mission. And your second question, as I answered in the first one, I answered the second question too. Culture of training. Culture of training. So this is, it's culture of sharing, it's a culture of comfort. It's a culture of helping others become greater, is as great as you becoming greater. There's bloggers that do this every day. I think we need to, culture is a collection of habits. Habits are created of doing something for a couple weeks and having positive reinforcement. I think that the culture of training comes with breaking that cycle that happened at the dot com in 2005 of everyone getting laid off and only you surviving and you being afraid. That's how I felt by the way, of being afraid of like, I was someone gonna take my job. I think we need to do the right thing. I think we need to demonstrate the value in that and allow others to be comfortable in that and acknowledge people who are doing that. And that's what I would love about the user's community. Those are people who are realizing helping others be greater is better for everyone. So I would add in you running the user group in Columbus and hopefully you get some help. Some of the people in the community there ask what they can do to help you. That's always awesome. It doesn't have to be just you. But go through and exercise using the training materials are out there. Use the install guides as well that they're very strongly use the same content from. And give us direct feedback to the training project. We hold weekly IRC meets, join. And just do a search on open stack IRC training and you'll find when we hold our meetings and just join up. You don't have to directly contribute by code or filing a bug. You can give us feedback directly and to say I use the operator's guide training last week and these are the problems I found. It's very much encouraged. Appreciate it. Yeah, the question going on Colin. The question that I had is where can you get the books? You guys referenced a series of books or ongoing development for. Yeah, it's on docs.openstack.org and we are wrapping up. I got a kid ducks.openstack.org. They're HTML, they're EPUB, they're PDF. It is free. You can print it yourself. It's Apache 2.0. The only requirement is you maintain the license. Yep, creative comments license. It's along with it. Thank you guys. Thank you everyone.