 I'm Pete Travis, the Dora Documentation Lead. I've been doing that for years. Forever. They won't let me quit. It's a great team of people to work with, so I'm Brian Exelbeard. I'm associated with the Documentation Project as well. I also happen to work for Red Hat. I've put here that I'm an engineer and a writer, because I was actually hired by Red Hat as a technical writer and have moved into a software engineering role, so I'm kind of coming at this from a lot of different angles, including a long time ago having used Fedora in production. There's a lot of opportunity here that we want to know what you think. So we've had a lot of conversations, especially over the last year, year and a half, about enabling people to contribute to docs. So we've talked to folks in the community and we sort of thought about what you would want to be able to contribute and kind of taken the feedback from that and our own experiences, and we put together this talk about problems that we know about and things we'd like to do about it. So we'll talk about a new life cycle for documentation, what would be the ideal experience for you. Thank you. And sort of what it would be like to contribute when we get a new model of and running for everybody. And we'll touch a little bit on tools that we're working on to enable that. So one of the first things we want to talk about is the new contributor experience. And this is the experience whether you or someone who literally just rolled up on Fedora and you're like, hey, I was working through this and I want to help make these docs better for the person who comes after me. Or if you've been an active project contributor elsewhere and you want to, as the term goes, shed some light on the things that you've been working on by improving the quality of the documentation around it. And when you first approach the documentation project and you're going, hey, I want to help, we have a fantastic to-do list that you can use. And this is not a bad slide. This is actually the problem that we identified first is that when you walk up to the Fedora Docs project, there is no easy, how do I get started? There's just a blank list. And so that kind of turns a few people off because there's no kind of engagement there from the beginning. Some people stick around, though, and they get on our RSE channel and they start with, okay, so what do I do really? And it opens up a series of questions that they want to ask. And we want to explore these questions because some of what we're doing is working really, really well. And some of what we're doing is that to-do list that was on the previous slide. So we need to figure this out together to help make this a better experience for everybody. So people come in and say, I want to write. I want to be a Fedora Docs writer. What do I write about? Where do I start? What work do you have going? And it's kind of overwhelming because you can write about everything. There's 20,000 packages and there's hundreds and millions of interactions between those packages that we could document, that we could put in production that use on their own machines. We could cover all of that. And if I just say, pick one. It's not a great show for you. And what happens is that person loses their enthusiasm because now they've got to figure it out. All these things to choose from and they don't want to pick the wrong thing. They don't want to pick something good. They don't want to pick something that's going to be engaging for them. They just kind of stop there. And some people just never make it past that. And when they do come up with ideas, obviously they're just not always great ideas. It's something that maybe is too ambitious for them. And that's great. But you don't necessarily want to pick something that's overly ambitious when you're just getting started with writing. Or maybe it's just way too simple to even be worth your time. You don't need to teach someone how to open Firefox. You could write a document about it and it might be good practice, but you're going to have to open Firefox to find the documentation. Or a lot of people, there are tons of problems that Fedora users have that we just can't do. We can't tell you how to install and video drive. So we can't tell you how to do code. All of the rules for software that is not permissible in Fedora also apply to Fedora docs. So not only can we not provide you with things that are not redistributable, we can't tell you how to do it for yourself. So all of that stuff is out. And there's a lot of people, you write a blog, you write an article, you take notes while you're hacking on something. You've got this content, it's kind of halfway there. And you say, this would be good for docs. Other people wouldn't even like this. Where do you put it? We've got guides, but there's nowhere to just dump it in. So that's writing topics. And so along those lines, the where do you fit problem is really a problem. I mean, as we've said, the established guides have well-defined scope, and it's hard to take something that has had any kind of feature green or just total change and figure out how you fit it back in. A good example that came up recently was somebody wanted to talk a little bit about the use of Docker containers. And there's not a great place to put that today. There's not a short form place. It doesn't fit in the virtualization guides. It doesn't go in the installation guide. It's not a system administration topic. It's really hard for a new writer, especially to even understand these are all the boxes that I have to play in. Now, how do I get all of this working in? And this writer in particular said, okay, well, I'll just start a brand new guide. Well, there's some issues around that. And one of them is that, frankly, it's just not easy. Some of that's tooling, which we'll talk about. And some of that is just, if you're going to start a new guide, there's some expectations that it becomes feature complete, which could mean that you're writing for a really long time before anybody gets to see any of this, that you've got enough material that it makes sense. You can't just start somebody in the middle of a process, for example. And we're going to hit on tooling quite a bit because all the discussion is holding up, it'll be complete discussions, it seems. But at the end of the day, publishing is a very delayed action right now. It's something that is kind of onerous to accomplish. And so we see some people become discouraged because it takes a while before their writing is ever seen in the world. Whereas if you've got your own blog, you just toss it up there and the next day you've got comments. So that's a challenge. Of course, whether you are a seasoned packager or you're totally new to open source projects when you get started, you're probably going to need some help. It's just a different domain language. It's a different set of tools. And we're actually really, really good at this. And we've done a lot of stuff to be better at it just to make sure that we're available. So we've got a great team of technical writers. A lot of them are professionals. They do it all day. They're really, really good at communicating ideas. There's people like me that play along. And at least answer questions. I've seen all kinds of questions thrown out of our mailing list and you get a variety of really good answers back from people that you just don't see unless that question piques their interest. So it's a good venue. And the IRC channel is pretty active. It's a laid-back sort of environment that's easy to drop into and just asks stupid questions is what I do. But it's not unlikely at all to just come in there and later on, or maybe right away, you get an answer from Major Brian, from Jennifer, from anybody, and then we'll talk you through whatever it is you're working on. And we've set up workshops in IRC because it is a little bit asynchronous and if you're not used to IRC etiquette and workflow and all of that, you might expect an answer within five minutes and you might actually win. It's the appropriate time zone for us to be sitting in front of our computer. So we laid out some slots. I think the one I usually do is Wednesday to Thursdays. Thursdays at 2 p.m. Eastern. That's right. And there's another one for the MIA folks. Time slot. The person who does this change times out very briefly in the next couple of weeks. But we're really good at helping, whether it's with the tools or with the writing or just because you want to move it and pulling through whatever. It's a relatively active core team. So we're really helpful and we have to be because the tools are really complex. Frankly, there's a lot of things that are involved. There's Publican, which is actually used to take what you're writing and convert it into HTML so that it can be published. There's DocBook, which is the actual XML language that you have to write all of the documentation in. It's HTML++++ kind of level of XML in my merit times. And it's, there's editors of choice and we all know the editor awards that can be had. So as a consequence, we don't really give any direct guidance on that. But sometimes you have new contributors who don't have an editor of choice. They just need some help in getting over these hurdles. There's XML Lent. There's Git. There's lots of stuff. So even for experienced project contributors, there's one or two of these tools that they've never had to use. And these tools present very interesting challenges. So like Git is Git. If you've contributed on the development side of the project, you know Git. If you've never done development work, you have to overcome this hurdle. DocBook, as I said, it's a fairly complex XML markup. And the nice thing about DocUp is there's a tag for just about every situation you could ever dream of running into in documentation. The problem is there's a tag for just about every situation that you could ever dream of running into in documentation. We have some standards, which we'll talk about, that say, all right, we don't use this tag, but we do use these tags. We have this situation we mark it up this way. That's a challenge. Publican, it's a great program. It does exactly what it's supposed to do. It's just not updated very frequently. It is highly likely that if you've just installed Fedora and it was just released, publican will not run for you. Like the Fedora release announcement should just about say, by the way, publican won't work for a month. Because it's very fragile. It has so many dependencies. And so these are all challenges that we have to figure out how to get around and to help somebody over. And so we need to work on this as one of our issues. This area really is the biggest space that when I talk to other Fedora contributors that they don't want to deal with. They don't want to run properly. And how do I write well? What is good technical writing? That's a conversation that teams are going to be really good at having and really get there. But most new contributors, when they join the project, we talk about tooling, we talk about where they're going to go, what they're going to write about. They finally get something in there. They find a slot. They write a new guide. They start working on a patch. And we'll have a conversation that goes back and forth. And we talk about their markup. We validate their doc book over and over. We fix their doc book syntax and L tag matching. And the conversation really quickly turns into a negative feedback. You can say, well, here's what you did wrong here. Here's what you did wrong here. And here's what you did wrong over here. And it's burdensome for everyone involved. It's not that we don't like helping. It's just that you don't want to be told that you did it wrong over and over and over. So, of course, a lot of folks, once it gets to that point where you have something that pretty much covers all of the topics that you need to, and it kind of tells you how to do it, and it builds. I don't want to tell you that it needs improvement anymore. I want you to see the results of your work with this publication. And this is where the conversation of new protrusion starts. It should start with good writing technique. But it's a conversation you don't have enough. So we've talked a lot about challenges that we have today, that over the years the processes have become more onerous, more negative feedback to use that language cycle. So we've kind of defined an ideal solution where we want to move to. And there's a lot of opportunity for help here. So in an ideal world, we want to create something that more resembles things that can improve until work in other parts of the project. For example, we want docs to move through a defined, predictable, staged life cycle. We want this to be something that is obvious, something that is very accessible, something that can be cleanly defined, and something that you can join the various pieces of. We want this to be something that we can write code around, that we can expect to have happen regardless of the document, regardless of what it's about. There are fantastic reasons to use Docbook. It's never going to go away completely because it's really, really good at what it does. But we need to allow other forms of markup to be used. Because A, that may be all we get. If somebody has written their blog, and their blog happens to be a markdown based blog somewhere, we need to be able to take that valuable content, generalize it out, accept it in. And maybe over time it gets migrated through different formats, to be able to work with these popular formats that are useful. We want to make sure we have more opportunities for this peer review. We really want the contribution story to start with, alright, you've got this, let's make it better. You've got this, let's make it build. Very different conversations. And then the last thing is, we want to get the people in the project who are doing this work out of the publication business. As we mentioned under tooling, the tooling has some issues. It tends to lag behind inversions. At one point there was one person in the, as I understand it, this is a little before my time, but at one point there was one person who could publish because they happened to have this really old version of Fedora hanging around. There you go. And there's one person here and one person in Europe. That's it. Because they happened to keep Fedora really old, you know, running and it works. And that's really not acceptable. And we shouldn't have to do anything when the text is good. It should just go out. And then the tooling to make that happen kind of goes hand in hand and really the manual part of the process that I'd like to see go away is translations. Our translation team is excellent. They do a really good job. We don't do such a good job with giving them our strings. We don't do such a good job of publishing them. The ideal situation right now is that we push the strings out and whoever is the team lead for that language handles the publishing. We don't want them to have to be publishing anymore if we want our writers to be publishing. So what I'd really like is for the publishing thing, just like other trans, the publishing in the original source language should happen automatically. Zenata's got an API. Facts have an API. You should just use that. But when you start looking at the content, if you're straying away from the large book comprehensive documentation model, then you can really start to get the community involved. And when I'm thinking about SIGS, the example that really comes to mind for me is a couple of releases ago and it started going down the list of all the different SIGS that people really don't even think about unless they're involved with those. And I popped into the Fedora GIS IRC channel, which is geographic information systems. Client and server map app. And you can do some really, really cool stuff with this. So I just popped into this new one that you guys have been working on and ended up having a really interesting conversation for about a half an hour with a guy there and I wish I could remember his name. So I give him credit. So it was super helpful and they've been putting in a lot of work with the new software there. It's stuff that people wouldn't necessarily know about unless they were already doing and looking for that stuff or I put in a release. And I'd like to see them supported so that end users can deploy that stuff with predictable instructions. So I'd like to be able to support those things. The robotic steps are the whole lot that people do with 3D printers and they put robots and whatever. And it doesn't have to be one big guide. It can be a whole bunch of atomic articles that we can put all these pieces together and individual contributors in that space can just pick something up. And they don't have to be technical workers. They can be subject matter experts in that area. They can be really good at GIS and not good writers. They can just help us and say, here are the things that you need to write about to make a good GIS server deployment. Here are the things that you need to write about to help people make microcontroller support. And if you tell us, get it in the pipeline and we have people that are asking, what do I do? Where do I start? So we want to be able to support that kind of stuff. And on the same page, Falsing the Wiki, Thora Wiki, could you find a page on Thora Wiki if I gave you a topic? I have to go and do it. But if you have process documentation for your internal team or getting started documentation or just things that that Fedora group does, we can give you a place to publish it that doesn't feel like the Wiki. And the last bit, I think it's just a really cool nice to have kind of thing. If we can generate documentation on the fly, not write it, but build it from packages. So API documentation, Python module comments, there were better examples of that. One of them was something as simple as would you like to know what packages are included in the various variants? What do I get when I install Workstation? What do I get when I run the Docker container? What's in the box? That's the kind of stuff you can just report out and no one has to maintain it. So we can write something, they will format that and publish it and it just happens because the release happened and not because we went through an even round script about it. So if it sounds interesting, you've got a note at the bottom here. We're working on tooling to make all of this happen. Please come to our Hackfest and help. The new model. Do you want to briefly touch on this? Yeah. So for workflow, what we'd like to see your experience be as a contributor is this predictable stage document lifecycle and the idea is you can tap in here anywhere you want or as much as you want. I like to use the term pipeline or concept of a funnel so that we have those things. So maybe you just have an idea. You say, I would really like to see some Docker documentation. Can you help me out? I would really like to have an inkscape tutorial. Do you have someone that can do that? We'll just queue them up and somebody will pick that up. They'll be looking for something to do and they'll say, I can write about Docker and they'll start writing it. And we'll have somebody else look it over and we'll have that peer review conversation. That's where this is a continuous process because we do like really appreciate the part before it sends feedbacks from users and it's a really valid way to participate in a Docker project. And then it gets published along the way and it gets translated to the public. So you can do as much or one piece however you want to plug into that. So the two user stories that we're trying to enable with all of these changes are this drive-by contribution concept and that kind of takes on two meanings. The first meaning is the one we just talked about. The idea that you have an idea, maybe somebody else writes it, you help serve as a reviewer or you just want to review documents or you just want to write drafts or whatever. The idea that you have a low commitment opportunity to participate however you choose to engage with the project. The other one that we're trying to enable is one where you want to own a particular piece of content through the entire life cycle but maybe it's a small piece of content. You figure out how to do something totally awesome within that needs to be documented and therefore you own that little thing flowing through all of the boxes. You don't have to think about the larger scale of what's going on outside of that. Drive-by contribution we think is going to be critical to the growth of the project because street credibility is measured in blog posts and these blog posts need to ultimately get formalized and made into a document that's going to survive longer than the validity of that blog post. And yes, we want to give you credit for sharing your blog posts and I just need to commit blogs to put it up on the site. The other model is somebody that really wants to get engaged really wants to get into debt. We've got a guy that introduced himself two months ago, maybe and said I am really interested in Libvert's Python APIs and I want to write a book about the Libvert Python API. How can we help you do it? Let him up with the repository already knew Doc look and everything and he's owning that topic 100%. So he's going to go through the whole process and we're going to have lots of peer review conversations with him and he's going to be doing really comprehensive stuff and it's well beyond something where you just pick up the individual pieces. We definitely want to help that guy. Not at the expense of anyone else but it's you can really get into detail and cover a range of topics or you can cover different aspects of the same topic and you really need to cover both. So we'll have a couple more slides but we would like to engage in some discussion so we have summary of what we said and basically contributor experience is not working for us it's not working for anybody the tooling is insufficient it's insufficient to publish today as we were talking about and it's not going to allow us to create new contributor experiences and these contributors especially these drive by load contributors are going to be critical to the growth and continued success of the documentation set and so we kind of have a couple of asks from you all and one of those asks is how many of you have contributed? I'm just curious. All of you okay no for those of you watching at home that was a total lie it was two hands but the idea is we want you to contribute we want you to think about what it is that you want to do to make docs better so that's both the drive by model and the partition model and by encouraging a new round of contribution we can really road test these ideas and we want you to contribute in a way that is not burdensome for you we want you to contribute and be able to take advantage of things that you're already doing things you're already working on you take notes you write blog posts you work on something you kind of figure out and you can just have a conversation about things you already know and derive something from that without you having to own a big part of the process I think that's one thing that I'm certainly saying that in my long time in Boston there's people who start out as the drive by contributor and then they become the prodigy and then they become the drive by prodigy contribute and so there is that flexibility you don't have to feel like hey I'm getting into this and I'm going to be tied to this for the next umpteen years and I'm contributing hours and hours a week and it's about contribution absolutely our second big ask is to come help us build the future we really do want to build a toolchain Friday at five is when we're getting started and I'll go ahead and just flip ahead to this slide we have specific things we want to accomplish we've been looking at some specific technology around the get repository structures that we want to use we need people to help test it make sure it's going to work for what we want that we can build the ACLs etc if it's missing features the development team behind it's been very responsive we want to get them requests while we're on the get talk is there a Frenchman in the room that can help us pronounce this word yeah I don't know it could be Peugeot Peugeot okay Peugeot it is thank you we've been struggling with that yes my pronunciation problem so I was quietly not telling you the name of the technology um we also need to work with we've been using build bot because that's what's preferred we need to work with some trigger based um testing and building initially that's going to probably literally just be get commits to trigger a build that's happening using what we've got code we need to take the code to the next level or at least get it implemented and make sure it's going to work correctly get the timeouts right etc we also need to work on the visual design um we need to work on creating I'll say the meta site that rolls over the top of all of this so we've got all these repos and all these documents if you can't find them that's a problem so there's data that needs to come out of this that needs to be rolled up into a menu system or something logical so that the whole site can be republished and with these pieces and a piece that's similar to this which I did not list um related to translation so that we can push into Zenata automatically when documentation is accepted this is going to get us to the point that we can support those user cases so that's our second ask for me and the third ask is what did we miss you know what have we said you didn't agree with or what have we said did you were like wait a minute what about this because we're soaking in it so occasionally we can't see the edges I think that's questions we put our email addresses up here and Jared's email address because he's running the Hacker hackfest thing on the out front and then our mail address full of super fruity people so I have two questions the first one is where are the candidates because I'm sitting there and the second one is you said that you want to enable very very contribution but at the same time usually the problem is you want rather guidelines that can be complicated or burdensome how do you decide if suddenly a guideline is no longer needed or if you lose a job yourself or if you say yeah this blockbusters is nice we are not using package we are using this word and this kind of stuff would it be seen as burdensome and do you plan to let's say leave the guidelines or do you plan to continue or take number one and I'll take number two you offered him the candy oh for those of you on video I have just given the microphone oh thank you okay so the second more formal question I thought there was I was listening more to the second question the first question I was hoping you can't do the talking I'll take a shot at it the answer that we're looking at is that you as a contributor if you're say a drive-by contributor or even a person your text will undergo some form of editing that may be an editing that you want to be involved in it may be an editing you don't want to be involved in but we're also hoping to find other contributors who maybe what they want to do is edit there are actually people in the world who that is their thing and so we're going to enable both of you to be part of a process to allow that to happen the end result is that not anyone can contribute to the publishing document branch so we will have a gatekeeping group of people at the end who can go this really isn't ready it really needs a lot of help one of the things we may also learn over time is that we are willing to relax some of the style guidelines that we've had today we think they're all good we think they're not too onerous we don't think it's a problem but if we discover that we have a hundred new contributors and they're all writing in a very clear, understandable easy to translate way that happens to be in violation of one of our style guides well let's fix the style guide instead of trying to fix the people most of the overreaching style things are very general it's not you must construct a sentence using these words or you must refer to packages in a specific way don't use a whole bunch of extra transitionary phrases you do not need to say now that you have completed the first step you are ready to proceed to the second step that adds zero information cut it out don't be offended if we tell you to cut it out and it will be use a positive active voice and that's more of a linguistic term that I'm, Jared would probably do a much better job of describing that something was written about using that thank you you might want to install the package next or instead you would say install the package there's an implied view there that we just put in but otherwise it shouldn't be too difficult to get past that part of it we're not going to go back and forth about your writing style it's your writing write the way you speak as long as it's clear and you can understand it and you're not editorializing it we're not scared I hate to change the answer but we're not scared to look at these things you know there are occasional things that people would go oh you have to change this it makes translation too hard if you don't use this quasi stilted form of the language and then suddenly you find out two years later from a translator that they're like would you please stop using this quasi stilted form of the language you're making translation hard because it turns out translation was never made difficult by the original phrasing so some of it's going to be feeling that the other thing that I would say is that I think this sets up an opportunity for people who especially these drive-by people who have blogs and are posting already this is a chance for you to get feedback on your writing not necessarily on your content so this may turn into something that's actually I really want to participate in this because I become a battle writer as a result of this process there is no more what about my internals I do not I think that for the guide someone has to be the owner of the guide so that person will be the great people who are speaking of I've really been trying to get people to stop using that word owner owner I would say a guide maintainer a guide coordinator you don't own it we're a team as far as workflow goes we have a couple of different fast groups there's a docs group there's a docs writers group there's a docs publisher group it will probably end up that the branches of these give-rebos that we publish will only be able to we'll have commit rights for the docs writers the docs publishers group which at the end of the day there will be a polar request workflow and if you do two or three of them and everything's fine we'll probably just put the the barrier to entry to getting into that group is not difficult yeah it's you didn't break anything you write reasonably well we're going to put you in that group and we hope that you become the guide that's working on those polar requests on the other side a secondary thing is that you mentioned the maintenance specifically you know something changed between Fedora 21 and 23 the guide is still talking about 21 style methodology if we can bring new this new user contributor methodology online if we can lighten this process we can hopefully engage with the working groups within the project in a way that causes them to be more able to report changes that have documentation impact today it's a very heavy process but if we can get to a point where they can go yeah we changed this you know it's more than just replacing the word young with DNF there's like an entire thing that you need to think about and this is no longer valid and this is the new way and if we can get that conversation rolling again because things are now easier to do that's going to hold some of the maintenance better for everyone it will also open up a lot of opportunity for brand new participants in the core project to go I followed your guide step 5 doesn't exist anymore step 6 all the arguments changed and I figured this out and since it's so lightweight and easy to engage with you I am as my first activity ever in contributing to the community going to fix the installation guide for the next person we love that even if you just say it's wrong here's what I did to fix it if you send me an email with that it makes my day because I know it's wrong I know where to fix it I know where that maintenance activity needs to happen because it's really hard to read through all of the documentation all of the time to make sure everything's up to date so that's sort of what we expect from the music community in general so how does time work all the best? so I will look at automated testing like for Python with the stream there is some package that just takes the documentation and with a specific format try to run that and if there is any error that means that the documentation is wrong and if we brought around an error that could be the error by the code but some of it's written so quick that's good there I don't think there's anything that runs commands I think they're working under the Mender module there is a testing framework for documentation called a Mender I believe only does all of it's done without mail but it can be extended but there's potential to do that with probably most markup languages I've been nose down in restructured text for a while for example and it wouldn't be too hard to write a directive that could be interpreted and you write a restructured text directly and it would take that command and maybe it would dump the output of the command into your document or maybe it would just make sure that it returns zero there's potential for that and the way the build system I envision sort of segmented out into a bunch of different jobs and there's validation steps in there and this I don't want to dive down the markup rabbit hole but this is also one of those cases just so everybody knows where DocBook is like really also because one of the Mender tests that they do have working right now is if you markup package names it will tell you if the package is still available so you don't refer to packages that no longer exist in the distribution and that's something that other markup languages like say markdown they don't provide you anything around the content to tell you hey this is a package name but DocBook can if we choose to use it that way so that's where we get to think about alright for this documentation set that's in this markup that has a much smaller test suite but over time as it grows in importance we even migrate it from one markup to another no more? I can in one question but no other questions or comments you all have been a pretty quiet crowd Kyle what do you think? do we cover everything you possibly want to know about Dorgon? I have a question go ahead I guess my comment is if this sounds good to you if this sounds the least bit interesting if you come to our hack test on Friday and help us make this a reality it's not just talk and even if you don't want to work on tools I want to show up and say hey I'd like to write an article about installing a patchy I need help with DocBook or anything I need help setting up my editor we're all there to help the other thing is even if you're not a programmer come because we can use your input to help the developers understand the kind of a solution we need because those of us with development experience approach the world in a very particular way and obviously everyone can do all of these command line functions and in reality that's not the user base of Fedora 100% and therefore if you're one of those people which they're very people show up and help us by giving us your eyes that's really critical kind of you identified with the the explanation because I mean that Fedora presentation team about writing something and then I was kind of this is too much and you to really get into it and then get into third foot which I had been hearing Jared explaining DocBook it's not that bad the the pack the steam mail pack that gives a kind of it's not you see all the steps it's not just doesn't just take a while to learn if you're writing things out in DocBook and you know DocBook and you know the subject it still takes you a while to write it just to write it out and if you're you just write it out without any markup and then you go back over it it still takes you a long time to get all that done it doesn't kind of you know it doesn't have to be the same person one person can write it that's another person come back come back and mark it out so don't let that be your hang out if you're saying I want to write Docs but I don't have to do all this Mark don't let that be your hang out to keep you from contributing Thank you Needed to be said We are basically out of time but I did want to say thank you and I'd be interested after the presentation for those of you who chose not to speak more than those of you who do I'd be interested to know why you came to the presentation I'll turn off the video so that you don't have to be recorded on that so all of you people thousands of you watching from home you're going to miss the best part you notice he says that as he's been totally out of frame last 15 years there's a reason for that unfortunately they did not install the effect that allows me to look 10 years younger and 30 months later but that being said and all seriousness I'd actually like to know why you came because that's a driver for thinking about what it is that people want to engage and I've been put on the video so I'm going to click the magic button so everybody watching here's my face really really large apparently the button doesn't work