 Hi everybody. My name is Dan Delamarsky. I'm from Microsoft. I'm not the official spokesperson, but Linux is awesome. My team uses a lot of it. So I'm personally part of the docs.microsoft.com team. We've done a lot of work to migrate our closed-in, closed-source solution to an open one. So this is a short talk about how we did it. And some lessons learned. So Doc's part of the product. So key principles that we kind of established for ourselves as we grew. And as we were thinking about moving from MSDN to this new solution. Number one, we wanted to go where the community is. If we would open-source our documentation, this means we want to go where people are. And it so happened that people are on GitHub. But we'll get to that. The other one was relying on standards and tooling that is actually used in the industry. We did not want to reinvent the wheel. We did not want to create stuff that is used just within Microsoft. We wanted to listen and respond to feedback. We wanted to automate things. And above all, we wanted to be the ones that also consume that system. So it's not just something that we just push out to the world and let it just be out there. So going where the community is, we like to think of our team as we were using GitHub before we acquired GitHub. It's the one place where open-source software happens. Community is there. A lot of people that use GitHub, they know how to use it, they know how to fork repos, they know how to issue PRs. That was the perfect place to grow the documentation system on top of. So content management at scale, so when it comes to us documenting many, many, many open-source products that we have, and even products that are not open-source, it's very easy. All you need to do is just create a new repository and it's right there. Contributions are also easy. It's very hard to point somebody in this room and find somebody that doesn't know how to use GitHub. So like I said, fork a repo, edit, submit PR, we'll review the change, and we'll merge it. Relying on standard formats and tooling, that was key to us. We did not want to reinvent the wheel, we did not want to create another flavor of XML or JSON or anything specific to us. We wanted to use something that the community uses. So markdown, again, going back to the history of GitHub, you know how to markdown was used very widely. So that was our foundation as well. So we used a common mark compliant flavor of markdown. Any extensions, anything that we built on top of it, clearly documented, anybody can reuse it. Tools to auto-generate documentation, we wanted to make sure that any API that we documented is not documented by hand. So in the days of MSDN, everything was handwritten, tens of thousands of docs were created manually. So writers would, you know, toil day and night and create them. It was very cumbersome, it was very cumbersome to edit, modify, remove and sunset and so on. So we decided to automate that process. And also I'll get to it in a second. We wanted to also listen and respond to feedback. So one of the key failings of a lot of resources is when customers submit feedback, they don't know where it goes. If I report a typo or report an issue, I want to know that the team acts on it. So GitHub was the appropriate place for that as well. We moved all our feedback to GitHub. Any comments on articles are now GitHub. We want to make it easy to submit feedback. So just log in on any article and you get the feedback right there as any comment section. Follow up. We make sure that for any issue that you open, in the open, on that GitHub issue, we comment whether we're going to do it, we're not going to do it, we're going to research it. Anything like that. It's very easy and the community loves it because we're being transparent. We're explicitly telling you what we're doing, how we're doing and when we're doing it. We want to recognize contributors. So now it's easier than ever for us to look who contributes to docs. We no longer guess who submitted a typo report, who submitted a new article. We know exactly because we look at our Git commit history and that makes it insanely easier for us. Automation is your friend. Really it is. We focus on delivering the experience and automating the rest. So things like PR validation, testing sample code, things like SEO validation, structure validation, code generation, making sure that all your articles in a table of contents, all of that is automated. So if things happen such as broken links or broken references, it's not us humans that catch it. It's essentially automation systems. So we have all those in place, a huge step from our stand. So as we move it over, we get those benefits. And at scale, everything that is not automated is slowing you down. So one thing that we learned for us is as we build our system, we want to automate everything to the max where humans just focus on the experience and the content. And eat your own dog food. We use our own systems. So we build everything and we write our own documentation internally with our systems as well. That's all I have. Thank you.