 The documentation program, you know, I've been working on it as the documentation program technically for about over four years now. And so, you know, I feel like we're hitting our stride, but it just, the growth of the project has really made us question-resourcing, ask how we can do this in more innovative ways. And so what I'm going to do today is talk through, you know, what is the Doctene, how are we going to shift as the scale of all the projects keeps growing and growing, and talk about our accomplishments last release, as well as our goals for QO. So let's go ahead and hit the next slide for the composition of the team. So the OpenSec.team, you know, we have about 20 core reviewers. And I'll talk a little bit more about some of the contribution stats in another slide. But these are the kinds of things we can offer to teams. We are information architects. We're figuring out where the information best fits. We're very good at audience analysis. And we figure out, okay, when does a cloud administrator need to know this? Is this somebody who actually wants high availability? Or is this an audience that's concerned more with running applications on top of OpenSec? And so we're writing community docs, but also providing that overall view, the 10,000-foot view of what needs to go on docs.OpenSec.org. We also have tool builders in our community, and these are people who have really done a great job of making sure that docs do continuous integration. Docs are reviewed just like code. We have talks tests against documentation. And I feel like, man, we're really leading the field as far as technical documentation and automation. We have ways to scrape code to get the latest and greatest. And I'm constantly impressed with some of the ways that we are just really making this technical, technical documentation. We also have reviewers. And I have to brag a little bit. On OpenSec-Annuals repo, we have the quickest turnaround of any OpenSec project. So we review very quickly. Now, we might review a lot, and will definitely be sort of the consistency police. And make sure that quality and accuracy are the highest priorities when getting a doc through our review queue. And then lastly, and I kind of have this last on purpose, we provide writers. And there are people working at different companies to maintain upstream documentation in addition to documentation for OpenSec products. So this is where we're working on building out the team, and also trying to find ways to coach the individual project teams to bring writers to the OpenSec upstream work. So let's go ahead into the next slide, it's the Juno accomplishments. I love looking at the stats. It's pretty telling that we had 238 individual doc contributors. And I think this speaks to the long tail of the knowledge that you need for OpenSec itself. There's a lot of very detailed oriented things, especially when you get into driver documentation, and a lot of the plug-in architecture that we have. And so even though we may only have probably less than 20 core reviewers, we need all the doc contributors that we can get, especially as we've gone from two projects to 17 that need documentation. We have a lot of bugs in our backlog, and probably honestly should have even more considering the use of something like a doc impact flag where a developer can mark in a commit message, yes, this change will affect end-user docs, will affect configuration, will affect the employer who wants to put this into production. And so that's actually one of the things I'll talk about that we want to do for Kilo. I tell you what though, over 2,200 commits and 8,400 reviews, that's pretty awesome. And the docs.opensec.org site itself is really a place for people to come to get the information that's being shown through our page views, through our unique page views. And the IceHouse documentation led the way with the most page views. So we know that people want release documentation that is in sync with the code that is keeping up with the huge scale that OpenSec has become. So what were the major things we got done? I think it's great that the documentation program has a section in the release notes for what we got done in any given release. And one of the big ones was this architecture design guide. And so that's aimed at people who want to figure out what to do with OpenSec, and it provides lots of use cases from just compute to just storage, all the way up to hybrid clouds, massive scale clouds. And so that was done in the five-day book spring, funded by the Foundation. Thank you guys very much. These are a great way for us to get experts in the community together and their willingness to give their knowledge back to communities is what is going to sustain the docs over time. We also did a lot of standardization across for OpenSec institution guides. And so I don't know if everyone knows this, but we write for Ubuntu, Devian, Suse, and Red Hat Fedora sent us. So there are little variations. And so what we did was we sat down and said, what can we make exactly the same across all these distributions? And that makes maintenance easier. And the testing on that is also a huge undertaking. So that's a huge bit of work that we did last release. We also started splitting out documents that are very special. It's like a high availability guide. You probably have to know a lot about Pacemaker, a lot about MySQL, and not necessarily OpenSec. So what we've done is found teams that can specifically do reviews on that kind of content. And the same thing for the security guide. They had to push this past release where they did reviews, blog doc bugs, fixed doc bugs, and kind of trying to gel the team around this specialty knowledge. We've also been moving the long-form API of reference documents into the project specs repositories. And I'm about halfway done. The larger projects we still need to get in there, but that also speaks to the complexity of something like Nova and Neutron and their APIs. And so honestly, one of the interesting stats I didn't put on the slide, but that I've found is I kept digging is we document almost 750 API calls with GitPost plus URI. And then if you get into counting the headers and stuff, the numbers are really big. So it's important that we finally streamline the maintenance on API reference information and still give people the information they need for what should I be doing around OS? What should I be doing for rate limiting? What should I be doing for these kind of calls? And so I see myself working a lot with the API working group and the application ecosystem groups as we continue to work on useful API documentation for those people running apps on top of OpenStack and for our employers supporting their own users. And then, honestly, for just things we do for the documentation, we've added more information to the user guide about Trove, the database service, both for end users and for admin users running that, and also updated the command line reference. That's another guide that we automate using the strings out of the help file. Lots of updates to the cloud administrator guide and then another automated guide to the configuration reference. And it's that automation that lets us keep up with the code. It's the way that we can work within the community and apply a lot of the community and collaborative techniques to docs. Let's go ahead and do the next slide where I'll talk about the QO goals. So this is basically our mission. And I try to really think about our users, really think about our employers, think about the audience. And at the same time try to provide quality, accurate documentation keeping up with the code. One of the things we're going to do is minimize the driver documentation. So with Kyle's book, he had this long, bulleted list and each of those documentation, but what we're thinking is that we don't actually need that directly and upstream, the real step-by-step stuff can be maintained on the vendor's own site. And so we're going to focus on upstream docs, documenting the open source ones on docs.opensector.org. And then vendor plugins will certainly be documented to the point where this is what you have to do on the open sec side, but then for the real step-by-step configuration, they can go and maintain it on their own docs domain. And I think that lists a lot of the burden for drivers documentation people as well. And then something really exciting coming up, and I'll show a couple screenshots in the last couple slides, is a new web design. So the foundation gave us some of their awesome web designers. Shout out to Wes and Todd for giving us a new web design with a lot of the requirements around we want to look more at page-based design instead of always having to have a book. And so that's really exciting, and we'll have a blueprint up about that this week that I want to share, as always we'll optimize so that we have automatic build so that we scrape the code as much as possible, especially for reference information. And then some of the other things that we just do as a doc team is support project teams, keep the API reference up to date, review things as they come in and bring conventions across all of OpenStack. One thing that the infrastructure team has been doing recently is a doc sprint around their new self-service guide for infrastructure inside of OpenStack. And so we were able to write conventions. Andres Jagger is an amazing contributor and can look at these things across projects to enable other teams to get the docs done that they need. So let's look at the roadmap in the next slide. And I, you know, look at some categories, quality, tools, experience. We always have to maintain high quality documentation. And that is part of the initiative that we do is we just maintain what's there. Sometimes we trim it out, sometimes we scope it a little differently, but we're always doing this monthly, daily. We can get 50 passes in in a day, some days. And so that's kind of my call to action to everyone is just to understand that this is ongoing work that always has to be done. And we absolutely need people to bring, you know, writers, communicators, people who can bridge that gap to deployers, to end users, and work on our bug backlog. We actually held a successful bug squash day last week. And we did a little bit of a change of the whole idea of a bug squash where we did a bug triage day. So instead of fixing the bugs we actually went in and wrote down these are the exact steps that you can take to fix this dog bug. And I think that will help people who just kind of want to do that walk-up contribution. You know, there's sitting home, a little belly-up or Thanksgiving dinner and just want something kind of mindless to work on. So that's the goal of this kind of thing. And I think that will help with our backlog. Our bug backlog is large because of the growth of the projects. And the projects are going to have to bring the resources that keep up with their documentation impact as they add features. We are working very hard to get these many, many of the source docs to RST format instead of DocBook. And I can hear the cheering already in the background. But the idea is that we want to make it fast and easy for people to contribute and, you know, no specialized knowledge, no white coat kind of understanding of documentation. Make it as accessible as possible. Make it easy to submit DocBooks. And that's part of this new redesign as well. We've always had a DocBook on every page but we want to make it very easy to get to. And then, you know, under experience I feel like our site has shown its age and it's about a three-year-old design. So it really is time to bring it into a more page-based layout. And what we're going to do is a phase approach to migrate certain documentation to RST using a new SYNC template. And so that leaves us into, you know, I hope to have much of that migration done by the QL release but it's a ton of work. So let's look at the new landing page on the next slide. And this is only about half a screenshot but the idea is to make sure that we match the www.opensected.org header and then offer these documents that you can use as certain release targets. We have different language documentation. And so offer this listing so that people can find out, oh, this is the Doc for me. This is relevant to what I'm trying to get done here. And do a better job of seeing relationships between pages. Make sure that the output helps as much as you can read on your iPad, on your mobile device, on your tablet, on your Nexus 6 that we're all getting for Christmas, right? Just make sure that all of the entire Docs at www.opensected.org site is very accessible. And so on the next slide I show the actual page redesign with a lot of the features that we already had but also this idea that here's all the things you can get to once you're on a landing page. And also the things you can do, make sure people know this page wasn't updated in the last month. It was updated in the last six months. That's pretty telling for how up-to-date a page is. Make sure that people know every bit of Docs at www.opensected.org can be edited using the review system that we have in place. And then I'm trying to get towards an every pages page one. Get away from the idea of being a very linear thing and let people land anywhere because I totally believe that everyone's front page is google.com and that is the entry to the site. We're keeping a lot of the features we had before, RSS feed-on updates, reporter.bug, and a lot of the syntax highlighting that we had previously. So just trying to get this really accessible, keep it into source format that people are really excited to just walk up and do minor edits, do quick typo fixes, and also work on content that's relevant to the audience's work trying to reach. So next slide. I want to just end with, you know what, let's do this. Contact me. If you want to get involved with documentation, we need people from just Doc Reviewers who are subject matter experts who know some certain part of OpenStack. Let me know if you're interested in Doc Tooling. Let me know if you're interested in Fink's templates. Let me know if you're interested in doing big reviews and quality checking. All of these things have a place in the OpenStack documentation. And I'm totally available in IRC. I'm happy to set up phone calls with people as well. And even over the break last week we had a person trying to get through the installation and was wanting to work on the guide if it needed work. And so we worked with him on Twitter of all things. So feel free to reach out to me and just hear my call to the community that we need documentation and there's lots of ways to contribute.