 application that can have a really big impact. I'd love to chat with you guys. One of the great things about Android, of course, is that you can install applications from a lot of different sources. So if it well in with our e-hosts being free of a software community, you can install it from Google. You can install it from asteroid. Anyone here who's familiar with asteroid here? So asteroid is a great resource. I kind of like to think about it as the Debian repositories of Android, basically a bunch of really installable and it is very explicit about what those applications are going to do in terms of permissions. And Google has, I think, gotten a little better about that recently. But asteroid, I think somebody has led the way on that, telling you what kind of permissions, whether it's using non-free resources. So for example, you can install, say, Telegram, a build a telegram from asteroid, but it's going to tell you it's going to use some non-free network. Basically, it's a great resource. Anyhow, you can also get like an APK, or you can build it yourself. It was challenging. We obviously had to slim down the core code. It was really tricky to get people testing builds and so forth. Apple literally holds all the keys. Another challenge that we faced along the road towards WebRoss Online was that every build had been platform specific. If we didn't have a specific, motivated user base or a backup for a lot of money, you weren't going to get leave office on that platform. So for example, operating systems that was being supported with us being a fun product. We now really don't have people interested in Solaris, it being a shuttered project with new versions coming out. But who's going to set up and maintain a build bot for that? That's one of the key ways you can get platform supported. An Android, we made an Android port, but it's difficult. There's a new UI. I don't know if you guys have tried to do Android testing between different operating system revisions and so forth. It's a headache. It's absolutely horrible. And say Chrome OS, I use a Chromebook and a Chrome box with CrewBunt2. It's like a Bunt2, so if I load onto it for demoing and so forth. But at times I would love to be able to show people something on their Chromebook, on their resource, and LibreOffice just doesn't run on OS. So the great thing is most sane consumer devices right now have a browser. They have access to anything that can be written in HTML, CSS, and JavaScript. So there's a new Google box that you can use to get something that can manage your office documents. But a lot of you still want to maintain control over your data and be able to have control over what people are seeing and who's accessing those resources. So the easy answer right now is code. So this is the easiest way for you guys to access LibreOffice, what is LibreOffice online, essentially. So I can sort of break this down a little bit. Collabra is a consultancy in the U.K. and they do a lot of LibreOffice development. And they have an office suite that they're working on sort of additions and improvements and so forth. Right now this is just targeted at developers, technical folks, probably most of the people in the room. And you can just grab a VM, again it's like a CD size, some very light to go to Collabra's website there. So people keep on asking me what's the plan if we browse this online. Right now Collabra, they're doing a lot of heavy lifting and they're looking at a commercial solution. They have an exact date. I've heard things about the middle of the year, but I have great things about what Collabra is doing is they're pushing their changes, their improvements into the upstream projects. And I don't work for Collabra to give them a bit of a shout out specifically because they have done so much hard work and are providing that and it's great VM for people. They've got the primary contributor LibreOffice Online. They've done amazing improvements to LibreOffice. They're a heavy developer on LibreOffice for Android and are pushing those changes very openly. They have this sort of open first guideline which I think is a great because if you're looking at something that's on LibreOffice Online where historically we had desktop and mobile versions if you guys are familiar with copy left licenses one of the things is that when we're moving towards an online one of the things that Collabra has done and other contributors have done is been to share their changes with everybody in the community. So I think that's something that we're going to need to consider going forward with LibreOffice Online making sure that we are building a vibrant community where everybody is participating. So current features in development, the juicy stuff keeping things in the cloud. So if you have a system of a company of 1,000 employees and you have 500 people who just need very simple office suite requirements they can likely just use LibreOffice Online in the browser. They can just access those documents. Those developers I was talking about that rare as an office suite could potentially just have LibreOffice and push their documents up to it. Of course they're geek. They're probably going to have LibreOffice already on their desktop and anyone else in the company who needs something a little heavier who wants some more of the features currently implemented on the desktop could usually drop us there as well. And because of the consistent code base you're going to see a lot more higher fidelity of rendering between the online version and the desktop version. Fortunately I ran into a couple of issues trying to get the VM working for you guys trying to do some updates on the wireless network here. But I do have some quick screen talks to show you documents. So this is just a DocX file with an image and some layout heading and so forth. And the rendering based on the LibreOffice engine is quite good. For example an Impress presentation I was hoping to give my presentation in LibreOffice Online made it next time. You can see it renders the content very well and is very high fidelity. Here's an example and presentation charts for example and so forth. I think that there is a great opportunity for people who are interested in development to take some of the LibreOffice Online tools and extend them far beyond what someone was asking me you know how is LibreOffice Online going to distinguish itself. And I thought about a lot of different ways in which we could including providing better thinking of data better ways of using the interface. At least for me I prefer working with my hands on a keyboard and just mousing around a lot. So I thought that especially for people who felt that that was a much more way to be more productive and get less focused to use these online applications. So I'll jump ahead here. So building the code. So the code is really easy. The amusing thing when I was talking to a couple of developers recently and they said building the code you should just grab the VM and I thought that was kind of a silly thing at first but it was when I was starting to work on computers and tweaking things and I was talking to a lot of people recently one of the best ways to get people engaged is to lower the barrier to changing code or making improvements to zero. And it's true if you have a live VM and you can go in and tweak the JavaScript directly if you can go in and tweak any aspect of the application without having to download and install and build all these pieces then that's going to be essentially almost a sin line barrier to getting started making improvements. So again, if you feel super lazy just grab the VM and test it out. Otherwise you can grab the Libra Online Code from our Git repo up on free desktop.org and the own cloud pieces are on GitHub. And if you are interested in making contributions you can send your contributions probably the easiest way to Libra Office is to hop on the development list for some help but if you're familiar with Garrett you can start using Garrett directly pushing patches up and pushing patches to own cloud via GitHub. So testing QA is near and dear to my heart being a QA engineer for a while and so testing in this environment is a little bit interesting and tricky. You know, obviously high quality feedback is really greatly appreciated and I'm really interested in hearing how you guys are interested in using Libra Online and what kind of environments, what kind of devices you're going to be testing it out on. I felt slightly compelled to mention that if people, again, I really would like to hear from you being technical audience because I hear from a lot of people who often have a lot of very robust amount of content to say and not much actual content because they whine a lot. So this is sort of like an appeal to you to have your feedback concise to the point because we get a lot of feedback that is Black Substance and I think that you would be a great audience and everyone at scale would be a great audience to give us precise feedback about the code. If you're interested in doing QA we have a bugzola for all the Libra Office Libra Online and Libra Office Android bugs. Please take a look at all the open bugs. I think it's a very short list right now but it's 50 or so. So please take a quick look and please give us some feedback. Filing new bugs is very much appreciated to help promote and move the developer Libra Office online. So what needs testing? I really would like to hear from people who are having a number of things like templates or their consistent documents, time sheets and so forth across your institution. I'd love to work with you to help you again have your company try out Libra Office online. I think it's going to be a low barrier for companies to try out Libra Office who otherwise wouldn't use the desktop version of Libra Office. And if you see any differences between rendering Libra Office online and the desktop again fonts and things might be a slight issue but if you see some major issues I'd love to hear about that. And for speakers and other speakers here who's speaking at scale? Anybody? Yes. So I'd love for you guys to try it out with your presentations and give feedback to see if it's working for you or for any features because I would love to see perhaps in the next scale have people presenting directly from Libra Office online as a little dog-fooding exercise. So I'd love to get back to you right from you. So in terms of getting your company or your organization to try out Libra Office online there are a number of critical environments in which tools that you completely control are important. So if we're talking about other situations that are required to treat patient data under HIPAA rules, confidentiality rules, or if you operate a law firm or otherwise work with legal data you're going to have to have some strict compliance to data security rules or face huge fines. I was actually just talking to someone who works with healthcare data and Libra Office online I think in terms of deployment you have a lot of choices. They could obviously be deployed in a cloud hosted by the third party or you could host it locally on a server that's even air-gapped if necessary. And because of the license and because of your flexibility and how you source your technical support from whom you can have someone audit the code if necessary and so forth to make sure that you have a tool that is perfect for business productivity documents but again can be as secure as it needs to be for you. So I think that's the end of my talk. I'd love to hear from you guys if you have any questions or if you have any suggestions about how we can improve Libra Office online or getting started with it. In the end, yeah. Sure. Security and so forth. So right now you break it. You got to keep both pieces down. Access of control and so forth are all through some plugins and so forth for dedication. You can use it with it. I suggest especially in the hospital you probably would keep stuff behind a VPN or behind a firewall of a VPN if you feel the access from outside and so forth. Again, yeah. Oh, okay. Yeah, I mean that's a good point. Libra Office on the desktop partially because of the nature of its history and so forth aside from the ability to encrypt individual files doesn't have any security baked into it and so as far as I know right now Libra Office online doesn't have any extra security added onto it. It stays online. Yeah, right now it does. Yeah, so that's the integration that the music should play me off. For those who don't know, OnCloud is a file-based document storage and editing. Okay, we're good. I'm breaking my microphone. So right, it's for clients. So with that coupled with Libra Office online everything can live in the cloud as much as you'd like. I mean, of course, for security, security data, like Kepa data, cash and so forth that you need to address but at least in terms of security of data I can imagine that if you say disability, ability to save locally within a couple of pieces about clearing cash I feel like you could create a pretty secure setup I'd say like bulletproof but pretty secure setup so that people could generally speaking accidentally leak data. Right here is what you're asking about, yeah. So as far as I know, and that's something that we do definitely want to add I guess is that product will be released around the time of, and I think that for people currently using something like Etherpad, so for those who don't know, Etherpad is basically like a text editor online, a clumber of text editor online. So it's a very simplified version of this and Libra Office uses Etherpad extensively for our meetings so, and you know, so you're probably dog food, you're almost online for that use in the future. Sort of create a self-contained presentation you could view online, is that, yeah, kind of thing is what you're asking. Yeah, I mean I think that's a great question. So that's basically exactly the kind of, because I'm continuously looking to the future for Libra Office, so as I mentioned earlier Libra Office has this decades-long history, and that can be good, and that can be challenging, and so for example Libra Office, it's just a historic panel, we have a German non-profit, improving pieces, and I think that for Libra Office to not only exist, I guess, but to really things like implementing new features, again, like self-contained presentation that someone can view. Now the thing from my perspective is that I'd love for people who view a presentation, as you said, it's an embedded presentation online, it'd be great for people to then be able to take that content and edit it, and manipulate it and work on it in the future. I think that one of the things about a lot of applications online, a lot of tools online, as much as I promote this software of people to take data that's in a Libra Office online environment, in the own kind of Libra Office online, and work that and use it elsewhere, I really want to make sure they're not locked into this office. I think that it's great for people to stay there because we're good, not because they can't do something else. So with the presentations, I think it would be great, and again they can right now, if they're viewing a presentation online, for them to be able to then again export that to HTML. I think there might still be a Flash Explorer and so forth, so they can take that content that's embedded in a blog, as you said, and we're not just linking them to something static, we're linking them to something that they have more ability to manipulate. Yep, great. So the question is, is there any of the challenges, again, sort of going back to having people be able to take their data out of the system and use other pieces, is that it would be more complicated, obviously, to have additional components for email and for calendaring and so forth. You know, you have Thunderbird and Lightning, there were some issues getting all these pieces to work together. I think different groups, you know, focusing on one, can be better. I mean, we already have several components within LibreOffice, you know, from, so I think it would be great to have integration with that, and, but even if, you know, we were to implement something ourselves, again be hopeful that we made it extremely easy for people to plug in other tools as well, because, you know, sort of community manifesto and so forth, one of our critical pieces is making sure that people can access their data and edit it and manipulate it and share it in their own language. So that's partially why we put so much emphasis on translations and so forth, but also on making sure that data is accessible. Here and in the back. So you're asking how easy is it to connect base with a PostgreSQL? I know it's possible. I don't know how complicated it is right now. If I'm not correctly, there is, I don't personally use the databases, you know, if there's a specific concern you have of question, then I can talk to you in person afterwards, so. Okay, yeah, yeah. So one of the actually interesting things is that if anyone here speaks German, or any other language I want to talk to you, but especially German, and in Germany, and in fact our documentation is in German. So in contrast to most of our documentation starting in English and then being translated to other languages, the base documentation starts in German and gets translated to English. So if anyone here would like to volunteer and help us speed up that translation, that would be great, and that might help you, again, correct Postgres to base more quickly. So, is that your question in the back there? Create like a bill of, say like I said earlier, and then in Calc, and then you wanted to, so you wanted to link those into the document, or I'm sorry, I'm not. Yeah, so I believe that, I mean you can embed a number of different types of documents within an open document format file, and I mean would your hope be that they would be embedded in the document physically, or just in like a directory, is what I'm saying, or? Yeah, I mean so you could probably link to that within that particular directory as long as you're managing things on a directory on a directory basis. Otherwise, documents like ODS for spreadsheet, for Calc, you could perhaps embed that PDF in there, if necessary, as a file. So you can actually go in and tweak them, change the content on XML file, and so forth by hand, which is fun and exciting, but don't do it the day before your presentation. No, this one's okay. But in fact, OXML file, so Microsoft competitor to open up a format with the same way as the zip file, with XML inside it. So that's one way, again you can take a little bit of what's in there in terms of thumbnails and so forth, but yeah, I mean it's, you could have relative paths or not. But yeah, here. Yeah, so what we have right now, in terms of the office, is we have a viewer, so you can view content and I believe, I mean I could look back at the bug reports, I believe that right now you should be able to open up presentations. Yes, so you can read all the content if it doesn't die here. You can then make minor edits to those. Test it myself is, if you have, say, like, changes of text, save it on Android, is that still a correct form of the file? I would believe so. Again, the same guts are being used in that LibreOffice for Android code as we're using in LibreOffice desktop version. I mean, there are differences, so we haven't implemented everything that the desktop version of LibreOffice does. We haven't implemented all the feature sets. Like, if you try to do, again, there's a button to do it, but if you try to call out, the copri isn't even there to say do a mail or a domain drive, although I would challenge you to try. And it's kind of interesting, I guess, to let your contacts. But the thing is that, again, my guess is that if you were editing, again, like a presentation, so if I took my presentation, so if I took my presentation to put it on my phone, and then went in and changed some text in it, I believe that it would then have those saved edits like I take it back to my desktop, and that would be a fully correct and valid ODP file. So, I mean, does that answer your question? Is that... Yeah. Yeah, I mean, again, my personal property is tiny, and the interface is horrible. I miss my phone with physical buttons because I could text and make changes in the dark without really looking... I mean, I'm such a typist, right? So I really appreciate that interface, and I feel like I make so many more with a non-tapped ulcer feedback device. But for those people who do feel like they want to use a... I think that there probably is a market for that, and I would love to see the Libra office for Android viewer, and again, with some little beta editing. But I think that we're really going to have to think about how to correctly create a useful interface because unless our devices get larger than this, or our fingers shrink, we're going to be in trouble. Question in the back. Merge OpenDarkFile. That's a great question. Hey, there's three. Yeah. Jog is a text-merging tool, and so this would, of course, imply that you'd unzip the files. I mean, in terms of version content, I've actually used FlatODT for that previously. So if you guys use OpenDocument files and you have a version control system for storing different versions of files, changes to them, you can save in one of the flat, the corresponding flat versions of OpenDocument. So like .FODT is flat, OpenDocumentText.FODS is flat, OpenDocument Spreadsheet. And then you can save it and diff it to a certain extent in that fashion. So I have heard some changes using that. It's tricky. And again, for things like binaries, I mean, it's complicated. But I guess to a certain extent, I have to know what kinds of changes you're merging and so forth. You know, there are things, again, in a sort of competing sphere to version controls, using like track changes and so forth. So there's a diff stack in the file. I was talking with Bradley Kuhn probably a year or two ago, and he asked if you could get, if there was a tool to convert OpenDocument change tracking, so a list of changes with information to a stack of commits, like big commits. And I thought that would be really cool, but I haven't had time to implement that yet. So if any of you guys would like a little project and you want to make Bradley happy, I mean, who doesn't want to make Bradley Kuhn happy? He's an awesome guy and works on a whole bunch of really important projects at the Software Freedom Conservancy among other places. And then, again, please chat with me because I think, again, this is another, I think, aspect that more that we can make it easy to hack on OpenDocument files than the more expressive people can be and the better control people have over the data for merging and so forth. So, yes, there is some work there and perhaps we're going to see some improvements to merging when that lands, because the goal is for that to land, not just in the online version, but in the desktop as well, because same code base, yes. Any other questions? People, I think we're nearing the end of the time. Thank all of you. You've been a great audience. If you have any other questions, if you'd like to volunteer specifically if you are deploying Libra Office in the United States right now, I'd love to hear about your success stories. If you're an educator, I'd love to put you in contact with other educators who are using Libra Office in the classroom or are thinking about participating in maybe working on documentation or QAO of the projects together as part of your curriculum. If I'm here, I'll be back at the Libra Office booth for the next couple of hours. So, go out there and do awesome things with Libra. I apologize for this speaker cutting out, so hopefully that wasn't too annoying. So I guess this is the first time I'll be presenting a conference, so I haven't learned to carry all my adapters around with me in time. Okay, thank you. I guess while we're waiting, does anybody have their own favorite bug stories that they've come up with? Good call. I'm guessing you've all run into different types of bugs, and that's why you're here. So the types of bugs that I'm going to be looking at in my talk fall into two main categories. Bugs that have sort of developed over a period of years. Some of those will come to be the case because you have a bunch of different people working on something, and one hand isn't talking to the other. The other types of bugs will arise because people keep coming in and throwing out everything before them. They haven't talked to anyone who's worked on it before, and so they end up just sort of ignoring everything that's come before them. But it persists in the bottom layers. So if the people have moved on, you can't talk to them. So you go back and add logging. The way that you can sort of go back and figure out what happened is by adding logging into particular points. So if you can find those points where, say, one coder's code joins up with the next one, you can sort of add a logging point in there. You'll start to pick up the pieces that have been lost when everything got thrown out. So I'm Katrina Hayes. I currently work for a company called Mandova Network Services. We help support ISPs. So we provide the backend services for ISPs that otherwise don't have the same sort of resources as Time Warner and AT&T and those companies. So why logging? It gives your code a temporal dimension, which as the internet's coming of age, we've got like 10 years worth of stuff that's built up. And as you're sort of going through these processes, much like baking, I don't know if you can tell. That's a picture of a pie. And it's a pie that's built up by layers. So the idea is that you sort of have this like crumbled nut layer on the bottom. But then we go ahead and add the next layer on top of it. You can't see the nuts anymore. So you're going to get people that are walking through. And the pie is originally like, it could be strawberry, rhubarb, it could be remembering, or it could be turtle. You're going to end up, if the label is just there and it just says pie, nobody's going to know that there's nuts in it until somebody has an allergic reaction. That's why you start adding logging, because if your original system wasn't documented very well, you aren't going to know that there's nuts in there until somebody goes up and crashes. So by logging, if you weren't standing there next to the pie and watched somebody fall over, you weren't going to know that until afterwards. So some general things to this talk. Like I said, as I was looking at it, I was looking at these two particular case studies of bugs. And as I was going through it, I realized that both of these types of bugs are particularly in studios because they build up over years. You don't really know that they're initially there. They aren't initially there, right? You want to sort of build that out of this process. You start with a very simple system 10 years ago. And over the years, you're sort of adding all these different things. And somebody comes in and is like, oh, I'd like to be able to send things by email instead of mail. So you have to go in and add this extra system. And as you add all these extra things, you get different inputs and stuff. And nobody actually knows how the entire system works anymore. And the other type of bug that I was encountering while we were doing this cooking, each person comes in as like, I'm going to build my own type of pie. And so you just end up throwing all these recipes out and forgetting where everything was. The first type of bug was exemplified by, this was on a site where you could navigate. You just had some sort of static content and you navigate it from page to page. Of course, the years of different people came in with different requirements. Here's where I like it. Okay, this particular course needs to navigate in this order and this different person needs to go through these slides in a different order. And so you end up instead of just saying like, okay, if the person clicks the next button, you go to the next page, you have all these different roles that end up getting layered in. So what we ended up having to do with this one is that every time someone clicked on this button, we had to go in and add a logging step. We had somebody describe it as the age of massive digitalization, right? So each person that's going through the site now has like their own unique place that they're supposed to be going to. What do you end up with? And then there's a giant pile of data like this, right? Okay, so you sort of add things to your logs as you can. And then you can track people like, and this doesn't just help with the one bug that we were initially looking at. So here we can see, oh, this isn't actually a data set, but if you track different things, you can see like, okay, here's how the person is going through the site. We get the different timestamps and we have the different user that it is. And so if you're going through all of these different things, you can get, it's when they were initially setting up, they weren't going to want to click. You weren't going to want to log every time someone clicks on it and you're just going to the same page, right? But now that we've got all of this storage space, we can start adding data sets like this. So you can watch this person as they actually go through the site in real-time and you know what page they're at now. And so for this bug, it saved it because we were able to see where the person is supposed to be going. So if they got stuck in a little loop that just kept sending back to the same page or something, we would see that happening to just kick them over to the next page. But what happened was that now that we have this log with all this information in, we also start to save some other bugs that we didn't even realize were bugs in the first time. We have the networking timestamp issues that people call in like, hey, you know, I'm supposed to have, you know, I've been on the site for half an hour. Why doesn't it only say I've been on your site for 10 minutes? And we can look at it and be like, okay, well that's because one time this time seems to be showing up on your computers through JavaScript and the timestamp that's on our servers is saying, you know, Sam, think that way. We also started tracking some stuff. Like if somebody called in and they were still running Internet Explorer 6, we would say like, instead of just trying to hear them describe it this one is going to be addressed a lot more by open source, I think. So this is what happens when each person comes in and says like, I've found the solution. I'm going to throw out everything else that's come before me, except that I don't actually know how to get to the flower anymore. So this is too many cooks in the kitchen, right? Each time somebody comes in and decides like, I'm just, I don't know what's going on so I'm just going to throw everything out. You also still don't know why it was there in the first place. But at the same time, if you aren't too careful about throwing out everything, you end up with these layers like, oh yeah, where's this coming from? So in this particular bubble that was going on was that certain cases were getting thrown out. It turns out that there was a previous layer that was adding a marker to those that nobody knew about anymore. So we had to, the way that we ended up tracing this bubble that we just had to sort of keep adding new logging points at each join that we could find. We could get this data dump and then it would point to another place where something was going on. We'd have to sort of keep adding new logging points at each join that we could find between the different coders. So it just ended up being my first being flag stuck to these cases that was causing them to get thrown out and nobody knew where those, why those flags were being stuck to them in the first place. We just sort of like, so we go in and add another point where we're like, okay, erase that flag. And that's just sort of another layer of crux that's getting added. But this is actually a map of the internet today. It's a lot more complicated than it was ten years ago. Nobody can understand everything anymore. So each time you come into a project, you know, don't just try to throw it away and write it off in scratch, which is kind of where I was going with this. So we have these giant data access stuff that we can sort of toss everything into. As long as you can go back and find it, what you're looking for when you need it, you'll be able to go back. Add in additional logging. You try and keep it all in a standard log format across all your systems or is it sort of ad hoc? Sort of throw in just whatever texturing makes sense. That's human readable. So I guess where a lot of these were coming from was that I was, before I was at Neo Nova, I was an independent contractor, so I was going into a bunch of different small businesses. Sort of, you know, okay, here we're going to throw a coder at it and it'll fix everything and then we're going to not have a coder anymore. Talk to people that came before you. Right. So then do you have like tools? I mean, do you use tools to like, parts of those logs? You know, like when you come across a bug and you're going to log files trying to find it, are you using like Elk stack or anything like that to like index the logs or are you just going in with like wrap? So it depended on the type of access that I had at the system. In some systems I didn't have really low access so I wouldn't be able to actually look at the log files themselves which is why I would try to add some sort of like a big table or something that I could look at in access even if I didn't have really low access. See, I guess I'm using logging in a sort of loose sense here. Gotcha. Okay. Thank you. Any other questions? Questions? Was it you? Oh, yeah. So if you're logging everything, how long would you retain these logs? Eventually you're probably going to have to purge. Yeah. See, probably don't need logs from 10 years ago. I guess it'll depend on the level of resources that you have. So the longer you can keep your log files, the more likely it is that you'll need to go back and look at them. I guess in one particular case we had people that worked from, hadn't realized that they'd been hacked like three and a half months before or something and are likely to have been hacked about three months before. Because it's something I'm from. So I guess as long as you can keep backups you want to. At the same time I know that a lot of small businesses aren't restricted in the level of resources so that they have soup, store what you can, and especially now that we have these giant data centers and stuff. Any other questions? In the beginning? Let me get going. Very nice people. This sounds very loud. Is it too loud? No. Okay. It's beautiful. It's beautiful? It's my dulcet barisone. All right, so a presentation. I know some of you here. I don't know some other people here. My goal here is to talk about how we build really interesting communities in GitHub. And I'm going to delve into how this is going to work in a few different ways. So those of you I don't know, it's been a bit of time with XPRI. It used to be a community manager for Ubuntu. Really passionate about how we build strong and effective communities. So I wrote a book called The Art Community and found it a conference called Community Leadership Summit. Now to be very clear, I've been at GitHub for two months. So I'm new. I've got that new employee smell. And it smells like an Octocat. And so what I'm going to be talking about here is going to be a mixture of some of my perspectives being new at GitHub, but also perspectives from 10 years or so and really thinking about communities and how we can apply them most effectively. So I don't have all of the answers. I'm hoping I have a Q&A section at the end but bear in mind that I'm no maintenance expert if one of my colleagues is a back brand that he's been around for years and I'm sure he'll be hard stuck to him. Now, a little competition later on. You can win Big Octocat, Little Octocat. So later on I'm going to ask for some feedback about the stuff that we could do in GitHub and some of the most popular suggestions would be these two different Octocats. So stay tuned for that. So when I joined a couple of months ago, I joined as director of community and I was thinking about the kind of overall focus of the work that I want to do here. And it's essentially empower all GitHub users to build strong and productive communities. When I take a look at conferences like Scale or other conferences, you just see incredible examples of people getting together with a shared interest and building incredible things. We see this in the Linux world, we see this in the web and elsewhere. And my goal here is, I think GitHub is a very important piece of how we can do that but we can make it way better. And I'm going to talk about that in maybe two areas. I'm going to talk about the present, which is what can we do today, practically today to help build interesting and effective communities. And then later on I want to talk about the future. So thinking around what we might want to do to build an effective GitHub and how that fits into a wide ecosystem of different pieces. So my hope here is that the first part of this presentation is going to be very practical. It's stuff that you can take away right now. You can take some notes and you can apply it right away. But then to kind of delve into what the future could look like as well. So let's first of all talk about, in my view, these are fundamentally experiences. And the example I give here is imagine a restaurant. When you show up to a restaurant, your whole experience is mapped out. When you show up, if you drive to a restaurant, do you valet your car? How is that going to work? When you walk in, how do they get you seated? Do they bring your menu first of all? Do they bring you a glass of water first of all? Do you get water at all? How do you order what you want? What orders do they bring in? How quickly do they bring it? And then you've got all the environmental elements such as the look of the restaurant, the music and all these different pieces. And all this amalgamation of all of these individual bits results in a cohesive experience. And if it's really good, you don't notice the elegance of that experience. And to me, communities are exactly the same thing. When you show up at a new community, wherever they may be, and you've got a success incredibly enjoyable and rewarding for that person to join. If that experience isn't well mapped out, then it can be really complex to do that don't know where to get help and things such as that. Community management through the perspective of how do we build these... So today for the present practical stuff, I want to talk about the experience of a new contributor. And this is invariably why I think a lot of folks you get it quite right, is they don't think about what that experience is and consequently they have all of this new fresh blood blood to join the project and miss certain opportunities to make that really elegant. And I think if we get this right, our communities grow, we get new blood blood to get fresh perspectives and we do interesting things. So I think of it in terms of this thing called the on-ramp, the new contributor on-ramp. And I think there are basically five areas. So imagine the person at the bottom here on the bottom left is brand new. They may have heard of your project, they may have not heard of it. The person at the top, they're from an engaged, they're from a rewarded, they've enjoyed their time. And these five areas of community is how do you learn they can actually get started and get involved? Because sometimes that's not particularly clear. The second piece is how do you develop the knowledge and the skills that you need to succeed? And in my mind that's not just in terms of the programming language and the tools that you're using, but also how do you contribute something? How do you throw it over the wall so they can bring it in? The third thing is identifying tasks. You've joined, you've discovered a community, you've got the skills, now you need something to do. How do you give someone that thing? You know, you want something that's not too hard but rewarding enough that they feel like they've accomplished something. The next thing is going to be getting help. You know, everybody's got questions. So how do you get help? And who are the kinds of people who you want to provide help? Not everybody is a people, not every person is a people person. You want to make sure that people, people help people. That made no sense. And then finally, when that person has made that contribution, you want them to feel a sense of kudos, a sense of respect and thanks, because the most powerful thing in communities is building a sense of belonging and feeling that your path is bigger than you and it's really rewarding. So I'm going to go through each of these and show you some practical ideas and things that you could do today. Let's start with discover. How do we effectively help people to discover projects and that they can participate? Well, one of the first things you can do is add a meaningful readme file. It's a dead simple thing. You just create a markdown file in your repo and just add some basics about what the project is and how they can get started. And what I'd recommend in these is that you explain what the project is. You can either link off or you can provide some steps how you can start using it. If this is something that's a piece of software that you build, explain how to build a thing. And then maybe link off to places where people can ask help such as IRC or email or stack or something such as that. If you want to go a step further, build a GitHub pages site. Now, a lot of people don't know this but you can actually build a website that's actually hosted on GitHub. And there is some tooling that's already there that made this really simple to do. So this can be essentially your portfolio website where you have an interesting project you point them towards, you know, MyProject.github.io. And it explains what the project is and how they get started and maybe some testimonials and some other bits and pieces. Everybody should have a website for their project and just keep it simple. It doesn't have to be a massive CMS with all kinds of content. Start simple and evolve as you can want and GitHub pages is a great way to do that. The next thing is regularly schedule social media. Social media is really powerful. It's a fairly rare and complicated science in how it operates. There's a great tool called Buffer that's free to use and they have like a pro version as well. We can basically say, I want to post content at these intervals like every Monday at 2 p.m. and 6 p.m. eastern time or Mondays, Wednesdays and Fridays or whatever. And then what you do is you basically fill a bucket full of social media messages and then it will post them for you. The way I like this is that every Sunday evening you can basically sit down there and you're like, I don't want to get out of there this week. You fill yourself up and then it takes care of us as moving things out for the week. It's a really useful tool. But also look at some of the best practices around social media. So for example, on Facebook, if you want to post something on Facebook, you want people to see it and make sure you have an image attached to it. Make sure it's 505 pixels wide and it's high contrast, such as white text in the background. It performs way better. Fix that you can do that. Another tip on Facebook, if you want to post a YouTube, if you want to post a video, don't link to a YouTube video. Facebook would only go to YouTube so the thumbnail is tiny. I'll put it to Facebook. It's a much bigger picture and that's what people will click on it. So get your social media in place. So let's now talk about developing knowledge. So at this point, we've pushed out a social media with Grail. We've got pages, websites and running. People who stumble across the repo have got to read me file in place. We're in pretty good shape. We've got a good step in terms of people actually knowing what our project is. Now it's about developing knowledge. And I think one of the first things we need to ask ourselves here is what does getting started look like? How do we get started? When we think of new contributors that come to a project, I think it's important to impact not their expectations of the and what some of the missing pieces are in how they get started in a particular project. And I think of it in these three kind of ways. The first thing you need to help them figure out is tooling. If you want to build software or you want to build books or you want to build legal documents, whatever you want to do in GitHub, you need tools. And you want to help that person get those tools installed as quickly as possible. So understanding where they're coming from and how they get those tools set up is a good thing to do. So for example, in the Ubuntu community in the economical, this is really easy because people who are building who are participating in Ubuntu communities we use in general Ubuntu so we can just paste links for download and offer various tools. But in your community, you may have people using Ubuntu or Fedora or Debian or using a Mac or Windows or whatever. So think about how they get that stuff installed as quickly as possible. The second piece is provided tutorial that gets somebody contributing something as quickly as possible and break it down into a series of steps. People like tutorials because a step-by-step set of instructions is cognitively easier to process than a massive page of text. And I think about that within the context of two areas. How do you create something and then how do you contribute to it? So the contributing piece in GitHub can be relatively straightforward because we have pull requests, we have issues and things like that. They're fairly consistent in terms of how they operate for different projects but they're used in different ways. So you want to make sure that some people who are new to your project may never submit a pull request in GitHub before. So don't assume that. So put together a tutorial that does that and then you're going to want them to link off to wider documentation. All the kind of details about how they can do different things in different contexts. So if you're building a piece of software you might want to have docs around the layout of the code, coding standards, different ways of contributing. So think about what that getting started journey looks like. And the next thing I think you should look at is creating a contributing to MD file. This is relatively common in GitHub projects. It's basically a markdown file and again just a really simple set of steps for how somebody can participate in the project and get started. The other thing at this point is think about the different types of participation. In most open source projects you can do code and documentation and translations and all these different pieces and you can be tempted to try and provide this with everything. And that's the optimal solution. You want these different roles to make it really easy for those different types of contribution for those people to participate. And let's just start with one. Let's say you just want to encourage programmers. Just focus on getting that journey right first. So create a contributing to MD file. The next piece which I think is really important is to create a knowledge base. There's a Wikiball to GitHub. This is a really simple tool for essentially creating material together. There's various projects that have done this very well. But here the screenshot kind of gives a good indication of this list of a sense of resources and translations. Think of it as like a manual when you join a company of a company handbook. Think about what your project handbook might look like and the Wiki is a great place to do that. Now before I move on from the knowledge piece I think there's some tips and tricks I'd like to share that I think are important. The first thing is being concise. Is there a tool for concise? Consistency? Now, consistency is important. Be concise. Concisely. Conciseness. Conciseness. I prefer consistency. I'm living in a world today where so many people are engaged in social media but our attention span is a lot shorter than it used to be. I think 10 years ago we could get away with big reams of text on Wiki pages explaining how to get started. You just can't get away with that now. People don't want to read that. So really try to get down to their brass tacks of how do we do this thing and keep it really short and that's why I like step-by-step. The step-by-step tutorials are important but really clarify how to take about the linear workflow of how that person goes from this point to this point effectively and then provide really practical, runnable steps. You know, if you're showing how to get a piece of software up and running and build, provide command line instructions on how they do that. If you are going to be showing how to submit your first product request include screenshots that show how they do that as well. So think about if you're the new person or you'd want to see what makes you feel comfortable with that. Now I think cross-linking is really helpful but also do it within reason. You don't want to create like a litany of little pages of content because that's irritating. So crossing what makes sense to move between different bits of how your knowledge base works but try to think of how you reduce the amount of bouncing around that you do. All right, so next one is identifying tasks. How do we get the right kind of task to someone, something? And my view traditionally here has been you want to give someone something to do where they can be successful in accomplishing something in less than a couple of hours. So you don't want to give somebody like big chunks of work but this is really hard because you may have a very accomplished developer join a project. You might have someone who's brand new. So there's no silver bullet to any of these things but one useful thing here is to create bite-sized issues. So in GitHub issues you can tag them, create a bite-sized tab and then these are for small things, string fixes, translation fixes, little bits and pieces that you can do. This is something we've done quite a lot in the Ubuntu project. It's worked out pretty good. It's a hey, I'm new, I'd like to get started. You can point them to your knowledge base, you step-by-step instructions and say, why did you get started on this issue? This is a nice, simple way of getting started. And then of course you could use the GitHub API to pull those issues and display them in different parts such as on your website on your GitHub pages website. Another thing that you may want to think about is waffle. Has anyone used waffle? So waffle is basically, has anyone used Trello? Okay, so Trello is like a Kanban type workflow tool that is pretty popular. And waffle is basically that that backends to GitHub issues. So you can create like a project view of how you want to build your project. And Trello is really good at that, but you can do it with waffle, but then the actual cards that you use are actually GitHub issues. And it uses tags to kind of organize them in different ways. It's a really neat tool. I have to confess I've only used it a little bit, and I'm not an expert, but the amount that I've put in it is really kind of neat. So thinking about what your wider set of to-do items is going to be, this is a nice thing that you could do, and then you could tag them as both sides. So getting help is really important, because when you join a new community, it's nerve-wracking. People are coming from a variety of different backgrounds. So you may, this may be your first time in an open source community, you may be socially a little anxious meeting a community with a bunch of people who maybe you look up to. So things like submitting your first pull request is really scary. Just building something yourself can be scary, just knowing how to get started. Posting your first issue can be scary. So having a support network and getting help I think is really important, because you want people to feel comfortable being able to do stuff, but also to feel like they're joining the social grouping that feels approachable. So there's a few things here I think are good to think about. First of all, you could tag issues with question or help needed. I've seen a few projects doing this. So if you've got a question, you just basically follow an issue. And you could have essentially members of your community regularly go through and review those and respond as you see fit. So this is a relatively simple thing that uses existing infrastructure. GitHub doesn't really today provide a lot of communication infrastructure outside of issues, which I think is something we're going to need to think about moving forward because it's really important. So you might want to look at other communication channels. So the classic in the open source world is mailing lists particularly popular with developers. You don't have to go and set up your own mailman saying you can go and just set up Google groups. They're dead simple. But then you may want to have some real-time communication in place as well. Obviously for many years we've been using IRC. I'm a big fan of IRC. I keep using it every day. The new contender that's becoming really popular is Slack. I use that as well. It's pretty cool. It's basically IRC in a nice window. So these are great tools for providing the place where people can pass the help. But one caveat of the place here is if your community is very small and maybe dispersed over a bunch of time zones, maybe wait a little bit until you put the real-time communication like IRC and Slack in place you don't want somebody showing up all excited to ask that question and there's no one around. So mailing lists are better because they're batch communication. You just respond when you can. Another good thing for helping for providing offensive help and support is events, things like sponsorship and mentoring. If you have a project, helping to connect a new person with an established person is a really useful thing to put in place. So someone joins, they pick off a bite-size issue, they're excited to get started, and then you can connect that person to an established contributor in the project, and they can essentially help them through it. And in the Ubuntu project we call the Sponsorship. Daniel Holback has done a tremendous work in this area in helping to craft what that process looks like. Someone basically fixes a bug, essentially attaches that to the Sponsorship queue, and then that's reviewed by people who are established in the project. And what that does is it kind of relieves that tension of your first contribution because you've got a friendly face reviewing it, that's the most thing to put in place. And then of course you might want to think about things like hack days and bug squashing events. These are great to do online because you can have a global audience, or if there's people in the local area that maybe meet up at a coffee shop and that kind of thing. Organizing these kind of events before shows such a scale is a really fun way of doing this as well. So as with everything in community leadership, there's no single silver bullet solution to everything. There's lots of different options. And you just choose what's right for your project. One of the things that I think is really important about defining good support resources is creating a culture where asking questions is okay. And that means you never tolerate somebody humiliating or belittling somebody for asking a question that they consider to be silly. No questions are silly. You reward people for asking questions. You say, you know what, that's a great question to ask. Let's see if we can document it to help other people. And then the final thing here is receiving kudos. So again, you go through this. If you imagine a review and you've got to this point, you've had a bit of an experience of this part. You know, you've gone through a part. You've discovered it. You've learned your skills. You've found something to work on. You've worked on it. You've got some help. And you get that in there, get merged in. That is a watershed moment for that person. It might be just another day for an existing contributor, but that's a big deal. And you want to thank them. And I think we want to thank them in three ways. First of all, thank them for their first contribution. You know, the first time they get something in, they say, really appreciate it. That's brilliant. You know, that could be on a pull request. It could be an issue. It could just be a personal email. The second thing is to thank them for their first insight. When somebody says, you know what, this could be an interesting way of doing it. Or this could be a different way of doing it. That's an insight where they're thinking about the strategy or the direction of doing something. And you want them to feel comfortable in offering insights. Because not everybody is comfortable at doing that by definition. And then the third thing, which I think is really important, is thanking somebody the first time they challenge you. The first time they say, this isn't the right way of doing things. I think we can do it better this way. I disagree with what you're trying to do. Because that builds a culture of challenging the status quo and doing things different. And that's what we want in our communities. When we all think the same, we get crappy software. So I think what we think about doing this for the different people who participate, the amalgamation is a rewarding experience of people. But then we want to showcase great work as well. And I recommend doing this in six ways. Imagine people do interesting stuff. And you want to highlight that person's contributions. First of all, check if they're comfortable about it. Because some people like to have a low profile. But imagine Jane Blogs does something really interesting. Highlighting on Twitter is a great way to do it. Highlighting it in a blog post is a great way to do it. Highlighting it in your communication channels, on your mailing list, in your Slack channel, in your IOC channels. If you have a podcast or you're talking and doing an interview at a podcast, name-checking that person for the great work that they've done is great. YouTube videos. YouTube is a tremendously powerful method of talking about what you're doing and getting the word out. And again, highlighting those contributions and highlighting those people. And then finally, at conferences and events, when you're, oh, giving a presentation. Mentioned people have done great work. They feel great about it. Sitting in an audience, watching a presentation and getting name-checked is a great feeling. So these are, when we start doing this, it really builds that personal connection. It builds that personal sense of relationship. And it builds that sense of belonging that's critical in communities. So that's what I'd recommend as some starting points. And these are not, you don't have to do all of these things. These are just ideas to get you started thinking about some practical ways in which you could build effective communities utilizing GitHub. But now let's talk about the future. And as I mentioned, I'm still quite new. So I'm still figuring out how GitHub works. It's a big-ish company. Lots of remarkably intelligent, passionate people. All who want to do the right thing. It's been a remarkable experience joining. And I'm trying to figure out what the future should look like, not just in terms of how this happens within GitHub, but what I think of this. And I want to share some perspectives on that, and then I want to get into, you know, if we've got some time, some ideas from you folks about what we should be focusing on. My overall philosophy, and some of you have seen me say this, so I apologize, particularly him, is as some of you will know, I'm incredibly passionate about communities. And the reason for that is I believe that we, as a human race, are inefficient in the way that we're collaborating with each other. And I think that because fundamentally we see these remarkable examples. We've seen the birth of open source and the impact that that's had changing how we live our lives and how we run infrastructure and how we think about building software to huge collaborative development around Wikipedia. People essentially documenting human knowledge to local projects that's just sustainable farming for communities to then you make a revolution that's happening, which is democratizing how we build and manufacture things. And then significant political change. We've seen communities form and basically say there's enough is enough. And the basic premise of this is that people are getting together because they have a shared passion and a shared ethos and they feel enabled to do something. My view is that most people don't know how to put communities together very effectively. I'm not suggesting I have all the answers, but what I am suggesting is that this is not about having all of the answers, it's about packaging up the answers that we do have in consumable ways that people can utilize. So my view is that if we can help build some methodology in an infrastructure and a structure around how community management and best practice operates, we can communicate that out widely and the ripple effect on how we as human beings create things will, by definition, increase. We will become more effective, we will become more collaborative, it will be more rewarding than you can imagine and we'll build interesting technology faster. That's one of the reasons why we're ready to go to GitHub because I see GitHub mentioned at the heart of how people are building software and how people are innovating. But I think there's a lot that we can do to make it better. So my view is that we have a challenge. This is the primary challenge that we've got at GitHub today. And I'm going to illustrate this with a scenario. So imagine you've got something called Dave. Dave has an idea. He thinks, you know what? I'm going to make a really cool Slack killer. I don't like Slack. I don't like IRC. I want to make something better than both of these. So Dave has an idea, spend some time with Jane, a friend of his, and they come up with some neat ideas about how that could look like and then basically build a prototype and they stick it into GitHub. Put it into a repo because everybody, that's what you put up when you want to collaborate with other people. Put it into GitHub. I'm going to spread the word about this. So it's a blog post. They tweet about it. They stick it up on hacking news. They get all that stuff posted. And they spread the word. And they hope that they get people interested and they get crickets. It really happens. They stick it up there. They maybe get a couple of people who file a few issues, couple of poll requests, the old Wiki page. But this thing really happens. I have no data to back this up. But I'm guessing that this happens in the majority of cases that people post up on GitHub. On any site, this is not just applied to GitHub. And what these people want is a community. They want to passionately get people getting together, working collaboratively on that code on various other ways, and bring into the service the very best in what human beings offer to make that thing better. The problem is that building a community is really hard. And when I joined GitHub, I sat down and thought, you know, I've been thinking about community for years, but I've never been able to really firmly articulate why it's hard. And this is, as everything, it's in progress. This will change the next time I present at scale. But the way I look at it is that building a community is hard because you're essentially building a workflow. And I think a workflow that looks a little bit like this is that, first of all, you have all these different pieces that fit into an effective community. And this is just an example. This is not the be all and all of what it looks like. But how do you have ideas and how do you articulate those ideas in different ways? How do you communicate with each other? How do you define which ideas are most interesting ideas and communicate with each other to bring those to the surface? And then how do we plan the implementation of those ideas? Some communities plan very explicitly to have work items and burn down charts and things like that and produce a good example of that. Some communities are much more freeform. You show up and you write a patch and you shove it into GitHub and you're off you go. How do you build software? What tools do you use? How do you test that software? Which frameworks are going to use? There's books and books written about just that piece. And then how do you build quality into that? How do you test the contributions that are coming in? How do you maintain code? How do you ship? Shipping has been books written about it. What's your release strategy? How do you segment your releases? How do you support your releases? Do you have a regular release cadence? When you ship something, how do you promote those releases and how do you get the right eyeballs on it? You've got things like participation. How do you get people involved? How do you build an effective participant base? How do you build a effective user base? How do you represent diverse and underrepresented groups in your community so it feels not just a bunch of white dudes? And how do you govern? How do you lead and build effective leadership around your community in a way that feels independent, that doesn't feel forced, that doesn't feel like it's serving somebody's own personal agenda? This is really hard. And I'm positive that most people don't really know how to get started with this. And they get some of these bits in place and they don't get other bits in place. And my view is that if we make this repeatable, it helps a bit more effective communities. But it's not that simple. Because I think when you look at that, the different ways in which you traverse that workflow depend on the types of people that you're thinking of. And I consider these to be different experiences. So you remember my example earlier on about the restaurant? Different experiences traverse that workflow in different ways. So as an example, with new developers, it's essentially the on-ramp that we already walked through earlier on. That's the way I think of it. And the way you construct that on-ramp within that workflow is going to be different than if you did it for a core developer. So you have various considerations like new developers generally lack context. They don't necessarily know the community. They likely need to develop knowledge and skills to participate. They're probably going to be pretty self-conscious about the first contributions. So these are some of the considerations to make. But then also, if you look at another example, such as core contributors, then context is essential. That's really important. Core contributors are going to spend a lot of time thinking about they've got the benefit of hindsight, the benefit of experience, the benefit of knowledge. And you see this all the time in communities where a new person shows up and says, why didn't you do it this way? And the core contributors think, we have talked about this so much. There's no way we're doing it that way. Because they have context, they have experience. And core contributors, you know, they have a repeatable workflow. They're doing the same thing over and over again for the new contributors the first time they've done it. And it's going to make you, when you're having to do something over and over again, you want it to feel sleek. Because if it has any spiky bits posted on the site, it's going to scratch your skin a little bit and it becomes annoying. And core contributors also play important mentoring roles. You know, because they've got the benefit of hindsight, the benefit of experience. And if they're the kind of people who enjoy mentoring, then you can connect them to new people. And importantly, core contributors set an important leadership example. There's a lot of discussion and debate about what's acceptable in those communities in terms of conduct and communication. And my view is that whether you like it or not as a leader, you should set an example. And you should set a good example. It doesn't mean you have to be politically correct about everything. It doesn't mean that you have to treat everybody with a kit of gloves. What it does mean is that you have to instill the culture that you want to grow in your own actions. And that in itself is a hard topic, and it's something that we can provide a lot of guidance around in terms of communities. And also, of course, with core contributors, we have governance. Core community members cannot just be governance members, but they can also influence governance members as well. You know, when we look at a particularly large number of those communities, there's a delicate fabric of politics. And many people at scale who I've met, and I'm sure all of you have, you've all been having conversations about the various political climates of different projects. This person's doing this, this person's doing that, and what are their intentions? And core contributors play a big role in how we define the culture of that. And then importantly, core contributors often build relationships with partners. If you are a big open source project leader now, then you're going to start having companies knocking on your door or other projects, and you have to figure out those details as well. So my overall goal here is I want to help GitHub users be able to create that workflow, build those experiences as efficiently and as effectively as possible. You know, it shouldn't be, I wrote a book called Carve Community. People should not have to read that book to build great communities. People probably shouldn't read that book anyway. But people shouldn't have to do that. The tools for systems that we have in the world today should make that easy for us. A big inspiration for me in this thinking, and I know some of you are not going to like this because it's a non-free product, is Meetup.com. Meetup.com is unbelievable in two private areas. First of all, the experience of creating a new Meetup group is really slick and simple. And it sets you up for success by asking for the most important piece of information, set into high expectations. Like one screen is, I will commit to organizing in-person events, agree. Just that tiny step, like a little reminder in your head that lives there that you should be doing that. But not just that, it's the discoverability of Meetup groups as well. You sign up for Meetup.com, you specify where you live, you say what you're interested in, and it actually gives really interesting suggestions of local groups to go to. So I think we should be thinking about how we infuse that spirit and that methodology into our tooling. And obviously, I'm focusing on this in GitHub, but GitHub is not just GitHub.com or GitHub Enterprise. It's a wide kind of fabric of integrations. We want to make sure that GitHub is working well with Jenkins and various other tools that will work here that you want to set up. So that's basically my broad vision and goal of how we do this. Then there is another piece here, and then I'll shut up and we can start talking together instead, is just what the GitHub community looks like. So I see it as having two buckets of communities, which is a horrible mental image, basically. One bucket is the person who creates a repo and they want to build a community for their project. That person who has the slack little idea and they create the repo and off they go. And those are the people I want to empower to build really strong and powerful communities. But then the other group is the wider GitHub user base. Whether you are a maintainer or whether you're just a user, I want to find an explore way in which we can build a strong GitHub community so we can help each other, we can support each other, we can bring the best of what we've got to the surface. That we can understand the needs of our users as effectively as possible and respond to them as effectively as possible and build a real relationship. And I'm not going to deny that really hard. And it's really hard because, for example, when I was a clinical and I was working in the Ubuntu Community Manager position, by definition, everybody who joined our community was sharing an ethos which was a little passionate about Ubuntu. And even if they were members of Ubuntu and Ubuntu, it didn't matter. They were all part of the same basic group of people. GitHub doesn't like that. We have radically different communities across millions of repos. So building the overall GitHub community is not like everybody has a shared perspective, a shared ethos, which is the typical sticking point that people have and how people are glued together in communities. So this is going to be a very different type of thing and I'm really thrilled about the challenge because I don't think there's any clear answers to this, but I think there's a lot of very clear opportunities to this. So that basically wraps up my main talk and we should give these away. Let me just show you what this looks like in person. I'm boxing. Look at that. Yeah. So earlier on, Brandon, pre-handler Brandon, this is a wonderful human being, I showed him this and I really, like, these are pretty rare. Most people don't get these. So if you come to the GitHub office in San Francisco, we've got this big swag store and we get free t-shirts and stuff like that, but these are pretty rare. So this is a very special, a little special giveaway. So I was thinking in the spirit of just conversation because I'm new to this and I'd like to let you folks think about GitHub. Share your ideas so what you think would be cool to see in GitHub or if you want to ask ideas so things would be cool for the work-on and then for each suggestion I want the audience to applaud whichever is the most excited response the winner will get this and the second person will get this. Make sense? Hold on. Oh, we have a microphone. Recording, so yeah. It went really bad the last time Jono gave me a microphone. See how this goes. Maybe he's great. It does work. So my question is this, there's a lot of components in GitHub and a lot of things that you can use. There's bug tracking, there's a website, there's all these pieces, but when I fire up a new project I kind of have to spin up all of these and it's quite labor intensive to tie them all together. It would be nice if there was a very basic essentially completely unformatted website with at least links to all these basic components every time I set up a new source code repository so that there's at least something there and I don't have to go find the issue tracker but hey, go to this actual GitHub page to submit a poll request. There's at least a basic page up there with all that information as well. So having all that prefabbed out when I say, hey, GitHub, spin up this new tree for me, that would be a huge time savings. So then I see a quick question to just before we ask for the vote. Are you thinking about, for example earlier I suggested we get a page aside. Are you thinking kind of like a pre-built templated website that you make it look like but you want it to be that links to all of your issues and whatever else? Right. That links to all the components that GitHub gives you when you commit a source code tree for the first time that it just fires up a basic webpage to link all those resources together so that you don't have to go hunting or so that a user doesn't have to go hunting in the community. If another developer comes along, where's the issue tracker for this? Where's the repository for this? Where's the support for this? Where's the intervention that would be replaced with the pages but where is that for now until that stuff's flushed out? All right. What do we think? This is another pretty concrete one. I've noticed in many, many projects and organizations across GitHub, especially as people tend to start doing this microservices thing, there's like open stack and a million repositories for all of the different pieces of it and something that I feel like is kind of missing is a deeper bucketing level or tagging level for repositories. If I'm a Ruby person and I could go to the open stack page and see like some random piece of the project is written in Ruby where most aren't, I might be more likely to go towards that one or something like these are grouped together. It's front end tools. These are grouped together. It's back end tools. So when you go look at an organization, it's just on a list of repo. It's just something that's more illustrative how these bits sit together. That would also be useful if you've built two complementary but not the same projects, say a client and a server, which talk to one another, but they're two separate repos. You've got to wedge them both into one repo or you can make them separate ones, but then you have to kind of link to one from the other. It would be nice if there was sort of a, these are both part of this project. Yeah. So what do we think? Put these back guys, I didn't mind. Go Davey. That felt stronger. If you see me type it, I'm not checking my email. I'm actually writing this. The thing we use on Launchpad a lot for elementary is cross-project issues. So if there's a common issue that affects multiple projects, we can file that as affecting more than one of our repositories. That's one thing that's lacking a lot for us on GitHub that we would really like to see. Cross-project issues. What do we think of that? Okay. I'm just making notes to who, where we're looking in terms of popularity. Okay. Bear with me. All right. And then I'll move to this side. I promise I'm not just prior to this and all these. So if you want to refer back to this, it's in your email. But my thing is we have a ton of developers who follow us on Google+, but the same people who follow us on GitHub. And it seems kind of silly that all the time we're putting things on Google+, and then linking back to GitHub when they're already watching our repository on GitHub. It'd be nice if just on the right-hand side of the repo there was just like a little, like I can put notifications in there, put information in there that maybe even shows up in their feed whenever they look at the notifications. It's like a micro-blogging thing, like Twitter, but it's specifically related to this repository, this organization on GitHub. All right. What do we think of that? Okay. I want to move to this side. I'll drop it below. Just increase the visibility into any given project. A lot of projects you go to, unless someone's taking the effort, you kind of have to know them. Know that if you go to whatever slash wiki, you can get to a wiki. You can get to this, that, and the other. When you go to a lot of GitHub pages, unless someone's put the effort to put that there, do you have no idea that's there to begin with? So you're thinking about when you go to github.com slash whatever. Slash whatever. When you go to github.com slash sizzling bacon, you know, that it says, you know, wiki, you know, issue tracker and all that at the top of those. Which sounds like this chap's suggesting about it. Yeah. So it seems some commonality of feedback here, which is good. It's chopping the reds. Oh, yeah. Let's do a vote. Well, it's the same one. I think four already. The same one that I've got another one for, yeah. All right. Wait, do you think it's the same one? Then I'll give you a different one. No. We need to move to other people. I want to get ready. I think I need this. This is about building communities. What he's talking about is being able to use github as we all use it, but have the community portion of it actually be, I hate the word wizard, just be able to pick and choose. Yes, I want to add a public side to this. Yes, I want to add a wiki to this. Yes, I want to add this. He's absolutely right. That's sorely needed to support any sort of project where you have interaction with people. I'm thinking just to reiterate, maybe I wasn't sure if everybody could hear, but the idea was essentially like more of a wizardy type onboarding for community members. Gotcha. What do we think of that one? Right. Let's, why don't we go over to, why don't we go over to my friend over here? You want? I really want to talk to him. I think I should give him the small, kind of building community theme that we're on here. One thing, because usually when you go to github, you know exactly what you're, like you're going to go there, you're going to contribute, you're going to look at the single page. But building community as a new github user, because honestly, I started with github, like maybe a year and a half ago, two years ago maybe. It would be nice to be able to take, have a, now I don't know if it does this yet, but kind of an underlying tagging system for each repo to where the repo, not tagging is in like branch tagging, but say it's using Postgrease, or using the technologies that you're using, and you can tag it, and then as a new github user, once you start watching one github, or one project, github might say, you know, you like this project, and this project's pretty similar, and it's more active, and it could kind of drive new users and old users to new projects that they might not have ever heard of otherwise. So you're thinking this is within the wider github. This is not for a specific repo organization. I'm interested in foo, and it shows you projects that relate to foo. Yeah, and stuff that you're watching, github just says, you're watching foo, for finding projects. Cool. For me at least, I'll frequently do a Google search trying to find an answer to some small problem. I'll see a bunch of github repository come up for programming stuff, but I know I'm going to have a large code base that I'm just shuffling through, or possibly an issue. I'll usually click the Stack Overflow link in a nice, concise code sample I can reference. Github already has the concept of a paste bin, a chest there that you can paste, and I think it'd be nice to try and expose, like, incorporate that into the repository. So for a repository is a really good example of the proper way to do a puppet deployment, or of some really clean Ruby coding, or something like that. Try and expose not the repository per se, but try and expose the specific snippet or the specific issue there a bit more. Use it so that people can use github as a better reference for learning more, and by doing that, if they're frequently finding the same project or individuals or anything like that, it'll be another incentive for them to try and contribute back. See, I'm thinking, tell me if I'm wrong, because I'm usually wrong, I'm essentially concise nuggets of information, like Stack Overflow, Stack Exchange, for a particular project, but essentially like a library within the repo that gets the Google juice that can bring people into it. Yes, something like that. I don't know necessarily about a library, but try and expose at a finer level than just a project. Right. Let me think about it. Gosh, this is getting difficult. Up the back in the top corner. Let me write that down. So for public projects, particularly feature requests, I would love to see upvotes for issues. So there's not a shitload of plus one comments, and then maybe a filter or something. I don't know, it could be just a new view on the issues page, but being able to sort issues based on upvotes. So for open projects, when people have feature requests, or even just high impact bugs, what about the community actually desires and wants out of the project? So quick question about that. You're talking about the way of voting the overall issue, or are you talking about upvotes for individual comments on an issue? No, for the overall issue. So it could be feature requests to be like a new thing, but it could just be a new view on issues itself. That would be awesome. It's kind of similar to the hotness rating in Launchpad. It's kind of similar to that. What do we think of that? The plot thickens. Here, Nicole. A couple of people have touched on this, but they haven't said it exactly, which is better searching. So I have had this problem. I was working on a project, and it was in two different repositories. There was no way to search both repositories. It's really difficult. So sometimes I jump out to Google and search from there so I can get back to where I'm going. And I just think it would be very helpful to have more modern search. And just to clarify, do you mean the search ability of finding stuff overall in GitHub? Yeah, so basically a lot of times I'm looking for, I want to see how they did something. Like I was looking for a particular piece of code. There's a company called Shotgun. They make software. They have it on GitHub. But rather than just going and asking, hey, is this broken? I can just go look at the code and see what they did. Oh, I see. And so I would do that a lot and actually have them fix it in GitHub as opposed to me fixing it. But it would also be nice to be able to say, hey, I found this broken piece of code and have a nice way to tell people. And the other thing that I found when I'm searching is sometimes GitHub pages go away, but then it's not very pleasant when you get there. Other people have referenced it like in Stack Overflow. They'll say, oh yeah, this solution is here in GitHub. But sometimes even the person who wrote it says that, but then their GitHub has gone away for some reason. Gotcha. What do we think about this? Let us finish it. Okay. You. I'm terrified to ask you. This is actually a real suggestion. Be nice. One of the things to make, to help you build a community as a project maintainer is to ensure that you're not really, really annoyed by the experience on issues. So as a project maintainer, please, please, please, a plus one button so people don't just post plus one as a comment. What's that like? I'd say it's different. You're talking about the individual comment, right? Yes. Or is it a suggestion of bearer's likes for the overall issue thread? Is that correct? I don't really think that was the same thing. So the idea back there was that instead of posting plus one, people would hear an upvote button about bearer. Oh. That must have been my day. Give that guy the car. Ah. See you after the car now, yeah? Terrible humor thing. Coming from the Wunder community, one thing that's missing on GitHub is proper translation solution because for one, everyone has a GitHub account, but translations are pretty hard and it would be great to have a translation solution that is usable for everyone even if he or she doesn't even know how to use Git. So you think a translation facility will integrate that? Right. Okay. Thoughts on that? I'm looking forward to figuring this one out. I'm going to get a lynch. I wish I brought more to cats. Single approach. Any, many, mind them all. Just chat here. I work with JavaScript a lot and looking up new packages MPM packages and variably gets me to a GitHub page. But usually, if I'm looking for a cryptography package or a new MPC package, I usually have to backtrack back to Google because I don't have a sense of how popular that package is and what other alternatives that they are. So along the lines of enhancing the search within the Git Hub website, if GitHub could have a sense of package repos so I could maybe add an MPM filter and then I could get a list of the most popular MPM packages that have their source code hosted on GitHub. And GitHub already has a great sorting methodology using the stars and that would really simplify my search for high-quality packages and make that really quick. All right, what do we think of that one? I think I've found that one. So first of all, a big thank you to all of you for your wonderful suggestions. I personally, and I know you're all going to disagree with this because there was lots of similar clapping. My view is that the winner was a vote for issues. So come and get your OctoCat. There you go. And my feeling, not just because of the applause but also the regularity from a few people, I think a GitHub page's templated website was clearly number two. So... You're going to have to share this after I can't among the four of my people. The one thing I can tell you, I can't comment on the upvotes for issues. I don't know just if that's on the red map or something like that. The one thing I can tell you at the templated website is that's actually something I've already put into my project plan, is I think that that's really important, making it really easy for people to get started. So I'm hoping that we'll build to see something that in the next six to eight months. In my mind, the pages, they will be something you would deploy yourself. It wouldn't be forced into it. All right. To make one thing they could do to make Git really usable, someone needs to finally get a clue and copy OpenSUSE's build service. So, building something like the OpenSUSE build service behind Git to where you can have the packages built there. So now we have a more trusted system for package builds. So I don't have to pull it, if I'm pulling down RPM from the creator, I'm not pulling it from them. I'm pulling it from Git where I've got a little more trust that they're not doing something to manipulate the file of these. All right. Thank you, everybody. And this was like the end of the day. Thank you for coming along. Thank you, Mr. Baker. So question. This is my normal speaking voice. Is this too loud? Okay. So can everyone hear me? A little too low. We're getting closer. Yes. Okay. So that sounds louder. Does that sound better? Fantastic. Okay. Welcome to Writing, Publishing, Books with Free Software by Mr. Nathan Haines. Mr. Haines is a local community council member of Ubuntu and California's leader in the Ubuntu community. Please. Thank you, Mr. Haines. Thank you very much. So as I've introduced, my name's Nathan Haines, and I'm a lot of things, but first and foremost, I'm a computer enthusiast. I'm a programmer. I started when I was 12. Actually, I was tanning on my first computer, and the only thing it did was turn on in about two seconds. Green screen extended, Microsoft extended color disk basics for Microsoft Copyright Night 982. It was eight years old by then, but I didn't know any better. I learned the program. DOS came out. Got my first PC. Programming was fantastic. And the other great thing that computers are great for are games. I'm an avid gamer. Unfortunately, I tend to buy games on Steam during their winter or their seasonal sales, and then never play them again. And good old games has only exacerbated the problem because they're like, so if you have 62 cents, you can get bio minutes. And I'm like, I downloaded that from the bulletin board in 1993. I should get this. And I actually did play for about an hour and a half, and hopefully I will play once more. But as life is on, I tend to taste games and no longer savor them. But I still have the heart of a gamer. And of course, I'm a computer technician. I've been a freelance computer technician for something like 18 years now, which is odd. Actually, if I think about it, no, I have a birthday in April, and then it will be 20 years. And I'm going to stop thinking about that right now. So I've had a lot of experience with computers, you know, using them, enjoying them, having fun, building them, tweaking them. And when you're 12 years old and you break your computer, you get the family computer, you get really good at fixing it before your mom finds out. So that led to my life choices there. I'm also an Ubuntu member. And that means several things. I'm one of three leaders of the California local community team. And we're local for a short. We're crazy about Ubuntu. And we do things like, we provide speakers in the California area for things like speaking engagements, install fasts, release parties. And scale qualifies as a speaking engagement. So we worked alongside Canonical and a greater global Ubuntu community to bring speakers from all over the world for Ubicon Summit actually on Thursday and Friday. And I think tripping out a little bit here and there. I can't claim responsibility for having Mark Shutterworth here, but I was sort of involved in the process a little. I'm also a member of the Ubuntu local community council. And we help sort of mediate issues for local teams all across the world since they tend to be by country and the U.S. it's by state. So if there are any questions or any help or if one new one starts up, we help make that process as smooth as possible. But the reason I'm here today is because I'm also an author. And so I've written lots of things in my life. I've written a lot of tech writing for work. I'd write, I'd find no documentation, and I would write some documentation. And I'd say, that's really great. You should do that for now on. And that's where the vaunted other duties as required in this job applications comes in. I've also written introductory magazine articles for tutorial articles for Linux Identity magazine. And just this year I actually sat down and wrote an entire book beginning Ubuntu for Windows and Mac users as published in September. And it's a good book, but I do say so myself. It's sort of, you know, there's all these books, Linux for Beginners and so on. This book assumes that you're already a computer expert in Windows and Mac, but that when you come to Ubuntu, things are different. And so that can be really frustrating. You're a computer expert, but everywhere you turn into Ubuntu is you're kind of stymied. So the answer, of course, is just to get a little bit of context and understand what's going on. And everything's really easy. It's like being in a foreign country and they have stoplights, but you're in Germany and the red light starts blinking, which is kind of weird, right? And that means get ready to hit the gas because it's going to turn green. Also stay out of the zebra stripes to crosswalks when it happens. Or if you're in Germany, if you go to a bar or a restaurant and it's full, you walk up to a table of people and you say, is this seat taken? And then you sit down among strangers and you chat. And so it's just no big deal once you know that. But to start out, you know, there's no context. So this book kind of walks you through the steps, through installation, gets you familiarized with the interface and then sets up a bunch of tasks. If you want to do this, you can start here. This is what it looks like. If you want to organize your photos, you use this, listen to music, you do this. A little bit of command line stuff, but not here's how you use command line. It says in the book, if you want to use command line, learn to use command line, go find a different book. But here's some fun things that are really useful on a command line. And then we do virtual machines and stuff. And it's not only great if you are learning Ubuntu, but it's also great if you maybe have a friend, if you love Ubuntu or another Linux distro, if you have a friend who wants to get started but is intimidated, this is the best way to start. So Ubuntu for those of you who don't know is a complete solution for your computer. It keeps everything secure to date because if you use an SES for the next five years, you get security updates and bug fix updates. And it's built entirely, with the exception of one or two drivers and firmware, entirely from free and open source software. So Ubuntu is what I'm going to use to describe some of the publishing process. And in fact, this book was written 100% completely in Ubuntu, aside from some Windows or Mac screenshots. So if you use a different Linux distro, then you already know that all distros are the same and equally as powerful and capable in the right hands. But if you are here at scale for the very first time, or if you're watching online, and you want to get started, Ubuntu is a fantastic place to start. So this talk is about writing and publishing the book using free software. And the first question that comes up, of course, is why publish a book. And there are many reasons. Some people have a story they want to tell, and some want to connect with others. Myself, I'm a budding want-to-be novelist, like most people. All Americans have the next great American novel in them. I don't, because I want to write sci-fi, but not as opposed to mainstream literature, literary fiction. But it's a human sort of desire, to want to connect with others and tell stories. As far as we know, we're the only creatures on Earth or in the known universe that actually do tell stories that can come whole-cloth out of things that have never existed before. And so a lot of people get stuck on that very question, well, why should I write a book? And is what I have to say important enough? And I would say humans are storytellers. In their nature. So I would say you're wrestling with this story. You have a cool story you want to write down, but you're afraid to share it. Don't worry about that. It's a human need to tell stories. I wrote my book here because I wanted to connect with others intellectually. I wanted to help share some knowledge, and I do talk to local Linux user groups, but I can't be everywhere. So this is, of course, a great way to get that word out. And everyone, of course, dreams of fame and fortune and being the next Stephen King or JK Rowling, and that probably won't happen, but there's good money to be had by publishing as well. And, of course, it's hard to be the most famous person, but you can definitely get the word out there. So publishing a book really has two sort of sides to it. There's traditional publishing and self-publishing. Now, traditional publishing has sort of been around for the last 575 years. The printing presses have been in somewhere around 1440. And so we have almost 600 years of tradition. That's why they call it traditional publishing. Before that, of course, you wrote with a paintbrush, skipped an ink on Papyrus Preston reeds. Before that, you pushed the reeds into clay. But the traditional publishing, the print press changed everything. And so if you wanted to, now for this book, you didn't have to hire a room of scribes and a scrubatorium. And so many of those things in traditional publishing that don't really make much sense in the last decade or so are because it's the way they've been doing things for a very, very, very long time. And as things, as the publishing landscape changes, there's just some inertia. So I'm going to describe that process in detail. Now, self-publishing has sort of been a dirty word for a very long time. It really started in, well, in the old days you could get that Papyrus or that vellum and you just start writing letters and that wasn't really very efficient. And it was when the Mimeograph Machine, the zero-graphic copy machine really sort of came into being where people could type or they could write things and then make lots of copies. So we have in the 50s and 60s, especially the 70s and 80s, fanzines and underground presses. And then you also have vanity presses which are companies that purport to help you publish your book and really discharge you for all the different types of steps that you would, a publisher would normally pay the money for. And then you have to buy a bunch of copies of your book and then you have to sell copies of your book outside the trunk of your car. And none of the national chains buy books that way. So vanity, publishing, vanity presses really gave self-publishing a bad name. And it's only been in the last, really the last eight years or so, and really caught on in the last five years, that online independent author publishing platforms like Kindle Direct Publishing through Amazon, Nook Press through Bunt and Noble, iTunes, Bookstore, Google Play Books, Lulupress, CafePress and so on have really made self-publishing physical books really cheap, really easy and something that has, especially in the last four years, become really legitimized. And so if you've heard of self-publishing and you think of vanity publishers, things have really changed. Let me talk about that a bit. So traditional publishing is pretty straightforward. It hasn't changed in a long time. The first step is to write the book. If you want to publish a book, you write the book first. It seems a little silly, but the way it works is that you write the book, you revise a few times, share it with some friends, you get their comments, maybe take their feedback into consideration, make sure you prove-freed it, and that's the only time that you're ready to actually contact a publisher. So they only take finished, completed fiction books. Now there's an exception to that. Nonfiction books aren't sold, the entire manuscript, they're actually sold by proposal. So for my book, for example, a friend of mine named, dropped me to an editor who was looking for Ubuntu authors, and so I got an email, said, would you pitch a book? We were looking for this or that. And so I wrote a table of contents, so on. He described why I was an expert, qualified to write a book about Ubuntu. And then they came back to the comments. I made some adjustments to the table of contents to the outline of the book. And they said, great, we like it. Go ahead and start writing the book. And we signed the contract, and then I started writing the book. But traditionally fiction, you have to actually have a finished book. So the way that works is that you typically submit a manuscript to literary agents, and they take a look, and they decide whether or not they think that they can sell your manuscript to a publisher. And then they accept or decline the manuscript. And if they accept it, well if they reject it and you keep submitting to other agents, if they accept it, then they'll take your book. And the agent will submit to publishers and see if they can get any bites. If you're really lucky, two or three or four publishers want the same book and the rights go to auction. If you're, most of the time, it just takes a while and one or two hits will come. They'll send a contract, you can review it, the publisher, when they want to buy your book to publish, they'll offer a contract. You always have the copyright in your book. You always own the copyright in your book. But what you're doing is you're actually selling your publishing rights, which is a subset of copyright. So you own the book, but you're giving away the right to distribute the book. And so most publishers actually want what are called first print rights, either in a certain area or in the world. And so what you want to do is have something that's never been published before. If you post it online on your blog, you have electronically published it and can no longer sell the first publication rights because you've already published it online. So you want to be a little tricky. You can get away with a 2x Serbs or maybe a first chapter, but basically if you're going to sell your book traditionally, you want to keep it offline. So you don't have to sell all your rights at once. You can say, I'm only selling North American rights. I'm only selling print rights. I'm only selling electronic rights. I'm not selling film rights or audio adaptation rights or audio book rights. If you didn't know that you could do all of those things, you should probably have an agent because the agents do that every day. Although that's how they make money. But there are some people who are a little worried about agents and so on, and every publisher has a policy on whether or not they allow what's called unsolicited manuscripts which is where you send directly to a publisher. Most don't, some do. And mostly they only allow agent submissions which means the agent goes through. There are various pros and cons that I might you to explore before you decide to send your book out. So if your book is accepted, the publisher offers a contract. If you like the contract, you sign it. And the publisher takes it from there, the end. And you will eventually be published. There's some back and forth, some proofreading, but they take care of most of everything. Self-publishing is completely different. Self-publishing, you're the publisher. So you take care of all those next steps after you write the book and it's accepted. So the way that works is still to write a book. And then because you're the publisher, and once it's finished and you've done some revision, you are going to hire a couple editors. There are lots of different kinds. There's copy editors, there's developmental editors. So a developmental editor which is something I sort of do on the side is that you take a story and they take the story and they read it. And they take a look at how the plot flows and they see are the characters consistent? Is the jumping mentor in the beginning is he just really happy and go lucky at the end? That's probably an error. Or they'll take a look and say, well, we're not really sure what the plot is, what the important point of the book is until maybe four or five chapters is in. You should know what the story is, three pages in. And they'll take a look and they'll help shape that. Copy editors or line editors attend to some great area, but they tend to basically go through what they want. Sometimes you can have them look for dialectical things. And I have one publisher who is British and she writes romance novels where usually one protagonist is British and one is American and the last couple they've all been American. So my job is to make sure everyone is speaking the right form of English is one of my jobs because she almost completely nails it, but her mistakes are invisible to her. So every so often the heroine of the story will have been stood by the counter, which we don't say. And my favorite recently was the protagonist, the male protagonist walked into the bar and saw all his friends at the bar, necking back beers. And I knew exactly what she meant right away, but the American protagonist can say, oh, look at those guys necking back beers like that. You can't say that. But also she hyphenates everything, everything, no one's hyphenated which is fine for British English not so fine for American English. The point is we want it to be one way the entire book through and she decides which way is right. I just make sure when I'm editing that it's the same way each way. That's the most important thing you can ever do because if somebody picks up your book and reads the first five pages and there's spelling mistakes and grammatical errors it's just weird to read. So I just look down and never buy anything you ever write again. Cover designers are also important. When you're self-publishing, you come up with a cover. Now I can make my own covers and in fact you'll see a little bit later on a cover I did for a friend of a friend short notice for just a book he wanted to give his Christmas presents he wasn't selling. And I think that's a perfect example of why you should hire a professional and not me or not do it yourself with a cover and tails. A layout designer takes your manuscript and makes it look pretty on the page or electronic form and you can spend a lot of time learning the technologies to do that or you can hire someone else to get back to writing. So if you're a do-it-yourself kind of person you can definitely get in there but if you do want to write a lot and maybe make some money off of it you might be wasting your time. But if you want, you may invest the time in once and then not have to hire anyone. But everyone has different skills. And self-publishing, because self-publishing requires so many different various skills that have nothing to do with each other some people can do it all. Some people are really good at a couple things or really like to do. I know one person who loves to do their own covers can't stand doing covers so I don't or I charge a lot for it. Sometimes at some point you're probably going to hire to hire someone else to help you. Last up of course is to publish the book. And in traditional publishing courses the publisher takes care of that. So I'm going to talk about what all that means. But I do want to sort of talk about money because that's the thing that nobody ever talks about. But one of the reasons we like to publish books or to write books is to get some money. And there are plenty of people who write for free. But if you want to write more seriously money helps, right? So money comes to you in the form of royalties. And again the system is completely different between self-publishing and traditional publishing. So with traditional publishing the way this works is that you get the contract to write the book and you sign the contract, you start writing and the publisher pays the author an advance on royalties. So I'm going to talk about this for you myself. A royalty is when the book sells the bookseller gets the money the publisher gets the money from the bookseller and then they pay the author a percentage of that. That's what's called a royalty. And it's paid for every book that's sold. So in traditional publishing the publisher pays an advance on royalties. So when I wrote this book I got money before the book was ever on sale. Long before the book was ever on sale. So that was one of the things that made it easier to write the book. And so the breakdown is a little different for a publisher but typically a publisher collects so a publisher sells the book to a bookstore and the bookstore doesn't pay the list price on the book. The publisher instead pays about about 45 to 60% off of the book depending on the contract for the vendors. Amazon asks for a lot of money but off. But they don't return the books if they're unused so it's different. And so the publisher only gets about 45 to 55% of the list price of the book. And they pay the author depending on the contract 8 to 15% of net profit. And if you have an agent the agent will take a little cut of that. Usually 10% now if you're a new author it's usually 15% of the kind of agency standard and maybe if you sell lots of books it kind of goes down. But the agent will get some money when you get paid. And so the publisher will pay you actually in advance. So the book seller gets sort of a gross profit. And so when you think of the you walk into a bookstore the gross profit goes to the book seller who only gave the publisher maybe 60% of that. Maybe 50%. So of the gross profit at the cash register. And then so from that that net profit to the publisher that's where your royalty comes out of. So in fact I'll give you an example. So this book was published through A Press and because this is a standard contract that is on their website I can tell you that they offered they offered a thing. Let me double check and see if I'm getting ahead of myself. I think I'm not. So basically they said we'll give you, here's our contract. They negotiated everything. They liked the outline. They said here's the contract. I said great. Read it over. And I wrote them back. You should always negotiate your contract. Always. They're going to give you the worst one side contract ever usually. And so your job is to just push back a little. So I read the contract. I love the contract. Almost everything about it was absolutely perfect. I didn't like the end of rights version because it wasn't clear what triggered the end of rights version. But when it happens, if it happens it was very clear I got this contract back and I didn't own the cover but I owned everything else. It was actually pretty cool. Everything was covered. I said this was pretty good. Although what happened was I took a look and of course I was interested in the royalties and they said we'll pay you a $1,000 advance on royalties and it specified a lot of places will pay you 25% on signing contract and then you write a bid and halfway through it's tending to be a little less lately but they said every time you hit 33% of the book submitted and approved for print we'll give you 33% of the $1,000 royalty. I thought that's pretty good. I liked that. Thought about it. Evald my editor and I said I love the contract. The one thing is well I told them and I said I thought they should pay me three times that. They had a really aggressive writing schedule and I said well I'm a freelancer and I'll have to write instead of taking jobs. They said you should pay me three times $3,000. They wrote back very nicely and Sweden told me they thought it didn't matter what I thought and that didn't go anywhere. They said it was a standard contract and they couldn't change that and so on. I wrote back and said I understand. I said well unfortunately five weeks isn't enough time to write this I think it'll be longer so can we relax the publishing schedule? They said absolutely. They said I had I think two and a half months and 14 months later the book was on shelves so I blew my schedule a little bit but you don't feel free to they didn't, I said I wanted three times more than ever willing to pay me and they didn't leave my email and send me this downloader. They explained and we went back and negotiated actually pretty quick because I did like the contract. But you want to be careful about that because once you sign it you're locked in and so for this $50 book list price I get about if you go through everything actually my royalty starts at 10% which is a lot higher than usual. It goes up pretty quick. But for the first 400 copies of this book $50 book I get something like $2 or $2.50 or something like that. I got published September 27th my first royalty statement should come any day now so we'll see exactly but it's about 225% but they did a ton of work for me as well. Self publishing is completely different. For self publishing you are the publisher and so because you're self publishing and you're usually going well you get 100% of the net profit basically and so usually you're selling directly on online digital bookseller like Amazon or Noop Press so you get 100% of the net profit when you are selling but the way that works is that you have the list price and your store front Amazon or Noop Press or Smashwords and so on is going to take a fee for everything they're doing web hosting bandwidth, storage containment processing which is actually really expensive so you will typically get about 70% on Amazon I think it's 65% on Noop Press or something like that with certain prices on Amazon you can get 35% instead of 70 I'll note that 35% is still 6 times what you're going to get with a traditional publisher and I think it's 21 times if you use 70. It's supposed to be between $299 and $999 so you get 70% of the list price if it's $198 $10 you get 35% so you have to sort of price accordingly although note that if I write a novel or a short story and I sell it for $3 on Amazon for $299 every single book that sells I get $2.08 so that's not too bad. So there's many maidens in publishing and this is for ebooks when you actually publish actual physical books you can create PDFs and go to create space or Lulup Press or so on and so for a 300 page technical book sort of like this and if you price it $25 you're going to make $10.50 because it's going to be about $11 or $13 to print so anything above that you get a novel for $799 or $899 you might make $1.50 for physical books and so that's something that you can sort of look at the pros and cons and weigh the benefits of it. So just to recap the royalties are completely different between traditional publishing and self publishing so for traditional publishing you sell the rights to publish your book you get like 10% you get 5% of the list price you have teams of experts working in your book and you have access to bookstores and libraries and so on and that can be really advantageous and so for self publishing you find it higher in your own team you still need the same people or at least the same roles you can fill in yourself but a bad cover will sink your book on Amazon there's too much competition a good cover and a good blurb will just stand right next to all the traditional published books but you will find it higher in your own team on the other hand you get to keep the entire creative control rights and marketing for your book so the publisher the traditional publisher chooses your cover if you're self publishing you choose your cover so if you don't like the traditional cover they might change or make some minor changes but maybe you get two changes but if you don't like it it's too bad that their team is going to decide it so you have to kind of decide what's important to you but most importantly I mentioned Vanity Press in traditional publishing all money flows toward the author that's really important you'll find agents out there non reputable but you'll find agents out there who are taking submissions they only charge a $25 reading submission fee to you and accept to reject it or if they've accepted $50 to start saying it's publishers there are publishers who will sell you a low priced value package to edit and lay out your book as you self publish those are scams every single time you are asked in the traditional publishing world to pay other people money to help publish your book it's a scam so with that book I got $1,000 for the book I got $1,000 because it's in their subscription program I don't have to pay back that $1,000 so I got $2,000 to write this book I got $330 months before the book was published a third of the way through the book I still could have walked away and not owed any money back they hired editors they hired covered layout designers and everything and hopefully they make their money back the book is doing well but I won't find out until I get my personality statements but it's not my problem if the book isn't doing well if they didn't make their money back I suspect they have no one asked me for any money ever nobody gets paid until the back end when the book starts selling I don't get paid until I earn out that $1,000 advance my book my share of the book has to earn out $1,000 before I see a check I got paid now when you're self publishing it's a little different because you're the publisher so obviously you're the publisher so you pay for your cover you pay for editors but you only do that in the context of you're the one publishing the book and then when you start selling books you keep all the money so there's a little investment up front but you should not pay all name author marking solutions for example once the book's ready, you're on your own to sell don't do that you can get very reasonably priced services and you can actually join any one of a billion indie author communities online and those communities will help you sort what's working so the first step of publishing is when it's time to write so that's what this talk is really about so when it's time to write there are some tricks some really basic steps to remember they're not even I'm going to go so far as to say tricks the first thing is that you pick a word processor and it can be a lever office writer it can be focus writer it's a really good minimalistic writer that's actually in the bin to repositories or your favorite tech setter which obviously is either to get it or nano and definitely not emack or buy a VI but it doesn't matter what you use to write all you need to do is get down words on paper I actually wrote the entire book and lever office writer I do kind of like focus writer but when it's time to write what you want to focus on is actually just writing when max came out in 1984 office productivity dropped everywhere because people started spending all their time in mac write changing font and font sizes and this one outlined and this one here's Helvetica and here's Times and here's some margins so when you use word perfect it was a dot text based thing you couldn't see any of that when you're on a graph interface you can and you want to sit there and make it look really pretty and that will keep you from ever writing a book so if you choose a word processor nowadays word processors do everything they do desktop publishing and so on so back in the day was just a fancy electronic typewriter the idea was to get words into electronic system maybe edit them a little bit and then put them out so if you use lever office go ahead and pick a header font choose an initial first line and dent maybe your body font and then don't touch anything else use the header style use the fault text style and just write because styles are good and it's important and in fact even writing this book I got a bunch of templates and they said we want you to only use styles don't use direct formatting but if you have trouble with the with the templates, the styles don't worry about it just write this type of text in and we have people who are double checking everything anyway so just make sure you write and it's more most important the most important thing of your book you can even use the text editor with no markup at all because if you traditionally publish they wanted double line spaced in career 12 point or times enrollment anyhow so you'll have to throw away all that formatting anyway if you're self publishing unless you're doing it yourself the editor will probably throw away a lot of that markup and reapply it themselves and you don't need help procrastinating when you're writing a book there's plenty of opportunity so I wrote my book about free software about Ubuntu entirely using free software and Ubuntu aside from a couple of windows and max screenshots for demonstration purposes everything else was entirely in Ubuntu even the windows screenshots were in Ubuntu in virtual box so when I got the acceptance letter and the first initial templates my publisher said welcome aboard and we want you to write using Word and we have these special templates for you and so here's the templates, here's the fonts and so this is how my publisher expected me to write but it turns out I told them well I intend to write this book in Libra Office until or if it actually causes any kind of problem I'll switch to Word if that's what it takes but I'm going to write it on Libra Office and so my publisher expected me to write the book this way but how I actually wrote the book was this way and it looks very, very, very similar now the fonts in the template aren't perfect but even when I was using the publisher provided fonts the names didn't quite match up in Office on Windows either because I did grab the trial of Office 2016 and install the fonts just to make sure it looked something similar before I got to work. They had a great template document showing all the styles so I just uploaded that, I just opened that, took a look so okay I can do that. So the book goes through post-processing, through print so the fact that some of these fonts might not be perfect some of the layout might not be perfect there's that weird font thing in the middle, maybe it's a projector sharp spot, it didn't matter and so the first page of each chapter had like a swoopy line decoration thing, chapter one swoopy line and then everything that hardly ever worked right on my system but it didn't matter because all the books went through post-processing, they stripped everything out of Word some XML type of processor and then it went to press so it wasn't a problem. And so what I would really recommend if you're writing your first book is to start with LibreOffice Writer. And the nice thing about LibreOffice is it lets you work with others even if they're using Word and so even though my publisher was actually using Word probably 2010 or 2013 or something, I don't know Orcair, I was using LibreOffice and LibreOffice allowed me to work with others. LibreOffice has the track changes feature and it's actually compatible with Word tracking comments so when I actually wrote my book I'd write everything in LibreOffice save it in open document text format as I was writing. And then my last step before send it to the publisher was just save open up file, save as save as docx and then send it over by email and then when I got it back to docx since it was just minor revision we kept that format, had all their comments and so on. So it's completely compatible with Word and it's gotten better and better and of course your editors or beta readers can install LibreOffice for free so if it's self publishing and you have someone say can you read my book and it's an ODT format and they say I don't have LibreOffice or I don't have Word you can say here's a copy of LibreOffice and so that's one of the nice things about free software is you can provide that software to others and then they can install it and LibreOffice is really an enterprise grade word processing office lead word processing presentation software this is LibreOffice of course and they'll thank you forever. Of course the downside to that is that you will be responsible for anything at all that happens to the computer or anything electronic in their home so two years from now when Microsoft fell it's your fault and they need you to help fix it because it happened after they installed that LibreOffice that you recommended them so that could be a downside and then of course any season editor may already have Word and you probably don't want to try and make them use a tool they're not comfortable with like LibreOffice but you can take those Word documents right back and it's no problem. So I recommend using LibreOffice to track revisions but some of you out there are going to say well what about source control bizarre git or subversion I'd say that's probably overkill I like the idea of it I very briefly considered it before deciding that was crazy good for tracking changes but not good for tracking comments and so if you just want a really complicated way to get a diff of one revision to the other version control will do that but the most powerful thing when you have an editor is that they can leave comments on text so you lose that with source control and let's say are going through the document every time they make a change they make a change, save it but that's good luck finding someone who will do that I think so this is what revising looks like in LibreOffice and as you can see this is one of the first chapters back in back from the editor and there's some comments there so those are all done in Word and they display perfectly so what we have here is that if I can see here the slide is too small and I want to show in this chapter that you can run Windows programs using Wine and so on so I have here I'll write Solitaire and I have here Windows Solitaire running in Wine and I thought that was really funny and so my lead editor actually here said please add a reference to this figure 2-11 before it shows the text up above because I wasn't doing that in the first two chapters and I got them all back and got to change every single one my tech reviewer here he thought that because when you install Wine there's a Notepad program that is not actually Notepad but looks just like it that people might also expect to see Windows Solitaire when really I grab this from an old Windows XP install or something and run side by side so he said please clarify because it does not come with Solitaire and you have to go find your own Windows programs but they run here and so that's the kind of thing that I thought was making a quick joke and then people said this could be confusing fix it and told me how to fix it and when somebody just was 100% completely right he's actually helping on the AV team so he might be listening right now thanks Jess you were great he was completely right there are some feedback from the reader readers editors tend to be a little more on the ball but you get feedback from the reader readers if they say something's wrong they're right that it's wrong they're wrong and why it's wrong so you don't have to follow everyone's feedback perfectly in general I found that all of my feedback was pretty much exactly on the ball the interior layout actually is the next step in the process you want to have your manuscript basically locked down and completely written you want to have pagination and so on and all sorts of things all set up and then you go and add an extra paragraph it can bump everything off and then you have to redo if it's like chapter one for example you have to redo the whole book so you want to make sure your manuscript's finished so it's the next step in the process after you've actually written the book and it's been edited and it's ready to go lever office can be used for simple things I've actually done this you want to use a sort of a style feature and the page format option and you don't want to do direct formatting rather because if you change the font if you select everything and change the font and then you copy-paste something and add a different style the font's not the same you just want to tell all headers have this font or this big all default text is this font and this big and so on in fact because you remember what I said you should not be doing this when you're writing your book playing with fonts and so on you can write the whole book and if you used header and default textiles you got the format option you got the style properties and then you can put in fonts and it just changes all throughout the document, you can see how it works it changes everywhere and you don't miss any headers or chapter titles because you select it all and you're changing it Scribes is actually the best way to do just real serious desktop publishing and unfortunately I don't have tons and tons of experience with that but it really is a kind of a nice way to it's much like Adobe InDesign or so on where you can actually specify text boundaries and wrapping around images and if you were really serious about it that would be a way to go and you get really fancy if you're doing something simpler LibreOffice might work and if you're doing electronic books you actually use a program called Sigil is what I recommend there are actually a lot of them but Sigil is an ePub formatting editor so an eBook is actually just mostly CSS and XHDML so it's really simple but for that reason you don't want to do that in LibreOffice or in Word or in Scribes so this is what the first page of the book will look like and this is a project the text is in Greek but it's that project I mentioned that for a friend of a friend I formatted a book one of his clients had her father had created a food company back in the 1800s and you would recognize it on the shelves today and in the 40s he typed up I'm a typewriter he's an autobiography so he borrowed it and a secret to her had it typed up sent to me I laid everything out so the chapters are way at the top there's no headers or footers it never is on a first page there's a link chapters at the top and a special font with small caps there's what's called a drop folio where the actual text begins lower and those are all details that you may not have recognized you may not have known that every book starts that way but if you had a book where it's just page to page and the headers are there and the page numbers you'd mainly say this looks kind of weird because it's not like every other book you've read so these are the details interior page layout looks like this and of course it is you said the top of the title and the author and the page numbers at the top and they can go different places but there are details so that again doesn't go on the first page any title page, front matter it's all different and the interior is laid out completely differently and an e-book for example will look like this so whereas a print book well you'll lay out so it looks basically like what you'll see on the printer page and in fact actually this is a PDF that did go to create space and was printed and came out just fine this is an example of Citadel now this isn't my book this is actually the beginning of Pay Me Bug by Christopher B. Wright and it's here because it's one I love the book and I have it on a Kindle I'm reading through it right now but also because it's licensed under a Creative Commons attribution non-commercial share alike for printer license and therefore I didn't have to ask anyone for permission although when I was writing my book I needed to show off a calibre which is an e-book management software and I asked him and he was happy if I could use a screenshot of the first page and he said yes so thanks Chris Wright so if you've ever used an HTML editor this looks really familiar complex formatting doesn't work in e-book devices so it's really simple, simpler is better when it comes to e-books because I have an e-ink Kindle and I almost never use a tablet unless I am then someone paid me to make their book look good and I make sure it looks good everywhere my tablet, my phone, my e-ink Kindle and so on for pleasure I only read on e-ink devices so you really want to make things really kind of simple you see all the chapters are actually broken down into separate HTML files and so Citadel helps you sort of work through that because it is a different process going from LibreOffice to another pretty much Citadel I think he doesn't use Citadel I think he used something else but this is what comes out so Citadel can help you make that change but you also might be better served hiring someone to do it for you shouldn't be too expensive last of all you do cover design and cover design is different between print and e-books so you can stop around cover whereas e-books don't the only thing an e-book needs is actually just a front cover and so you can use Gimp or Inkscape those are great graphical tools that you are going to use and so for print books so an e-book it can be inspirational to have the cover in front of you cover art is like a short story but if you are writing an actual print book you should wait until everything is completely laid out this is the last step in the process because the spines be so big and depending on how many pages are there and that's how big the picture has to be so you want to make that the last step in the process so this is a template for create space whatever it should look like anything in the red is called the bleed area so close to the edges that when they have the automated machines it goes through the press they cut everything automatically and it might shift a little bit here and there they can't guarantee anything in there it's actually going to be visible so you want to have a little bit of extra blank space around there so that it's not white edges where it misaligns or so your title isn't cut off at the top and so this comes last and we look at an example so this is another Greek example of the book I laid out for a friend and this isn't the actual title it's not the actual copy in fact we didn't have a trademark or copyright clearance to worry about there so I used images he gave me for this I actually had to purchase two stock images so this cost me way more than the actual cover I gave him did but this is what looks like you see the cover the back cover on the left the spine in the middle and the actual cover on the right ultra bio pool clothes and so on so it's a barcode and so on and so I like to think of this as the perfect example for why you should probably hire a professional but the client was very very happy and that made me happy so as far as publishing a print book goes traditional publishing means the publisher takes care of the step but if you're self publishing then you want to use print-on-demand now print-on-demand typically prints PDF files there are a lot of different places out there create space and give a spark, lulupress and so on this book getting started the boom 2 1004 was actually printed at lulupress and I'll have a look at it after the talk it's actually really well done you almost never know this book was actually traditionally published and they still used print-on-demand and it's a great book and you again would never ever know they didn't have to print-on-demand books and then pay for warehousing for example but basically you create a PDF it looks just like the ones I did exactly how it looked on the page and then you pay basically just a set cost and then if you sell it you can pad the list price so that you get the difference it's pretty easy publishing an e-book is a little different most e-books stores actually support e-pub documents which is a standard and there are a lot of different companies and you're going to want to sort of look around there's Amazon, Amazon has Kindle Direct Publishing there's Press, Smashwords, iTunes Direct to Digital, Google Play Books there's all sorts of places KDP or Kindle Direct Publishing is probably where you want to go unless you hate Amazon for some reason but if you hate the largest online bookstore in the world but you're trying to sell your book there's no direct applications but they have a really good royalty rate and technically it's not a royalty because they're just the storefront they're not really the publisher which applies to everyone here if you go exclusive with them there's a couple extra terms and promotional offers that are kind of neat and it's a 90 day window where if you hate it then you can just let that lapse and you can go off so it's as easy as uploading a file and then you're done so as you can see you can basically write and publish a book using pretty much only free software on your end and it's a pretty simple process LibreOffice, Inkscape, Gimp and you're pretty much done if you're doing eBooks so I want to leave you with one last note as regards digital rights management so I like to think of it as a restrictions management and traditional publishers usually give books well, when you're traditionally published they have the final say on eBooks as far as DRM DRM of course means when you buy the book you're locked to certain devices you can't read it on any others I'd recommend that DRM is not really helpful for self-published books or traditional publishing books but that's not your call then if you're self-publishing it only affects paying customers if someone strips the DRM and then distributes it none of those people got the DRM so it doesn't affect them and it can actually there's a plug-in for a calibre where you type in your Kindle serial number and then every single book every time you plug in your Kindle it syncs all the new books to your computer it automatically strips the DRM and like the time it took to transfer over the USB cable on all these self-publishing bookstores and I recommend that you just forego it sometimes people download a book and like it and they go buy it or sometimes they say, this is really good I'll go buy the rest of the books from the series or other books by the same author and in fact I read the first two chapters of Paintybug online loved it so I was kind of calm and I said that's really generous with him and I'm going to pay him by going straight to Amazon and paying I think it was $4 that's pretty much my time and that's the talk and if you have any questions I'd love to take them if we have time so I have a lot of questions with you first the question was so did I have an agent before with the publishers or did I already get one? so I got name dropped so I got a direct solicitation and then could just submit my proposal I don't know how big agents are in necessarily non-fiction but agents only represent completed manuscripts so you'll have the book first and then you'll submit the book to the agent and then the agent on your behalf will start looking so you'll find the agent once your book's finished and if you submit to a publisher and because they allow it without the agent and they accept it you're best served by finding an IT lawyer to negotiate a contract or an agent then to represent you so I have this book that this giant publisher has been willing to publish then agents will be much more likely to take them on because they only get paid when you sell and it's a done deal by that point to find a reputable agent you can look online there are lists I think you find your favorite books that are in the style of the book you're writing and you find out what their editor is it's usually on the copyright page so that you're not submitting a crime thriller to a romance agent for example that's the best way to do it questions the 6x9 format that you had is obviously bigger than paperback and smaller than hardback that's a standard is that a specific name for that size it is industry standard I think it's called B5 size I'm not quite sure so the one you're looking at is a math market paperback and you can't find anyone online for an on-demand that size it's like 5.58 inches by something I don't know why so 6x9 is kind of similar you can do I think 5x7 but when you create space for example there will be a giant list of formats and they'll do score formats and bigger formats but if you want extended distribution in bookstores libraries you have to pick an industry size and they'll list them all we offer this industry size industry standard, non-industry standard which one did you pick the 6x9 I can't tell from here on your side I think I I think I did that's a good question yeah 6x9 because that's the size you wanted it was a get that looked a little more regal but yeah I'd probably go 5x8 or something on a fiction book yes back there a friend of mine published a book I think with Lou I think it was she was self-publishing and for the cover they wanted some PDF they wanted PDF files but there's some sort of exotic flavor of PDF I don't know if you could talk a little bit about that I've never published myself through Lou so the first question was where did I get the template so a create space you sign for accounts your Amazon account you look, you pick the size and then there are templates for you there's more templates for the interior which I ignore and the cover templates I follow religiously this actually came from what it says on there there's another little company that does it but I don't see it booknow.com they give free things because they want to sell you something but this is free and I'm hoping and I just did it because I wanted the bar code on the book already instead of leaving that to create space but they'll do that normally and as far as Lou so the cover create space wanted a PDF so I did everything in Inkscape and then just said save as PDF and I didn't need anything special so I would check Lou again because things are changing so rapidly they might be a little more I can check that makes the publishing and printing a lot easier is probably what they're talking about certain sentences for publishers that's probably true I was lucky enough to be able to ignore all that through create space but if you, I don't know Inkscape anymore directly but when you export to PDF and LibreOffice you can save options and there's a ton of different things that can definitely be and then just a second follow up question when you're doing your research did you try and figure out if there's anything like that will take a LibreOffice and convert it to say sigil or is it all met both are separate processes so I like to basically strip all from so basically what I do is my process that people pay money for is I take their document grab a chapter copy and paste it into g-edit and then paste it to sigil of the markup myself and I can't craft the CSS file and that's the easiest way because I don't want any other changes a lot of authors actually take word or LibreOffice and they save as HTML and then they can use bookmarks and so on and they have really good results with that I just I grew up and the web started in 1992 we first started seeing it at home in 1994-95 they had a HTML editor, one side was the HTML the other side was a preview and that's how I learned to edit web pages so as you can tell from my web site so that's how I like to do it I was in terms of writing the book do you say it's 20 chapters you create one document and you're writing in that one document or would it be more advisable to say break it into 20 different files as chapters and then reassemble it and then the other thing that I'd like for you to talk about in self-publishing kind of the cost in terms of versus quantity number of pages in terms of your experiences because you have to pay for that upfront so with so in regards to let me do that so in regards to whether you break, you have one giant document for Manuscript or you break it up it really depends on the length of the document most of my clients will sort of take a I'll give that 60,000 words novel and it'll be one giant document I have to seek around to copy basic chapters for the traditional published books they actually wanted everything in a single chapter by chapter each document and that made it easier because I would finish a chapter and I would submit it and that was done whereas if I had and then they'd work do some work on it if I actually had a if I was self-publishing and writing a novel I would publish a student one document because I'm really lazy and don't like to handle that many documents but it really is a matter of preference the one thing is if you're writing something if you're writing something long, if it's just text you'll be okay, if you're writing something complex you'll plot the figures and pictures and so on it really is best to have separate documents because if the document gets too big it can cause problems and make the word processor unreliable so I would say that as far as upfront costs in self-publishing there really are no upfront costs anymore what you can do is you can get everything ready to publish put the e-book on Amazon put the print book on say CreateSpace which is also going to Amazon they'll take an extra cut there and then you can order your own copies for costs to give out to give as gifts or whatever but you never pay anything upfront so when you go to CreateSpace you'll find that they have black and white are color interior they have like the cream color or blank white color for pages that's the same cost you can actually go in and there's a price calculator this size trim because that's the amount of paper they use this many pages you can see exactly what that will cost to print and then from there you determine if they're for gifts just for yourself that's what you pay if you are going to sell it online then you can from there figure out what you want to market up at one and two Nate, I just have a quick question how much money do you know of anybody making any money doing this? so I worked really really hard to get some sci-fi novels up under my own name I've done some technical consulting for some Roman authors and so I once the process wrote some nonsense to 3,000, 5,000 works for a story this month in the process I know exactly step by step and I actually made I shouldn't say with no effort so basically picking backing off of their experience between scale and getting a ghost writing offer from someone who's making a lot of money who's like if you write a 50,000 I'll give you a template hit the beats here if you write a 50,000 worth story I'll give you $1,500 for story and if you really won't keep doing it maybe we'll increase it if it does well he made $80,000 last year and he's making about 20,000 every month and he's doing some ghost writing he does his own writing and he's had a lot of experience he's shared experience in that private group he's the nicest guy I've ever known when I said let me make sure I know the process I'm selling books so they're formatting right I'll go through I ignored his advice did one book, took me 3 hours to write did another took me another 6 hours did another book, did the marketing different cover, different types of photos styles, keywords, blurbs and I sold about 8 times more I made I think $160 that month on that one book so if you're writing on Kindle right now if you're writing short stories you keep publishing short stories you make a few hundred dollars a month usually once you learn what's going on if you pay attention if you write novels you can make substantially more than that a romance is really big right now sci-fi and fantasy are really big literary fiction can be big you kind of have to look at the draw there there's some luck involved at any rates but you can, if you want to do this side job you can make a few hundred dollars a couple hundred dollars a month and it's fine and you get paid for it right if you want to actually do it for real there are only certain genres that you can really make a lot of money in but it is totally possible indexing I noticed you didn't mention that that's an art in itself I've done a lot of foreign foreign language indexing do you know how important an index is for non-fiction did you do it yourself or did you find it out good question so especially because my book was sort of a past schedule my publisher was writers were very concerned I just got chapter and a half left what's going on there we really want you to concentrate on the task at hand and we can do that really quickly I want to know what I have to write and I'll think about it in the back of my brain I'll percolate and I'm not going to waste any time until I'm done but it'll help me and I don't worry about it and they're like okay here and then I did exactly that I looked at it, flipped through it so that's pretty cool wrote a temporary fuller dedication for the book and then I went back to writing so in the front matter I had the table of contents for example and they were very clear do not waste any time doing your table of contents instead of writing because you're behind schedule we have people do that and they said the same thing once the book's finished I said what's we got a conference call in skype I said what's next I said well we take this we finish the copy and it goes here it goes to the proofers you look at that at the same time we send it to indexers it's a good form listed in the copyright page of my book the form that actually went through and indexed everything I did get a copy in PDF form just before it went out it looked good to me got the final books out and of course there's one error there's one entry that loops back to itself this see this something weird that I probably should have caught but that wasn't my job so I don't know so it was none of my problems and traditionally traditional publishing you don't have to worry about it in self-publishing if you're doing nonfiction there are ways to mark certain subjects that later on Libra Office can create an index for you for a nonfiction book depending on the length my book's a reference book so the index sort of makes and breaks the book because it's meant to be picked up in red and the table contents is really nice and clear but if someone wants something specific they can go and make them fire foxes here and here and here so indexing for nonfiction is super super important I would say if you're self-publishing because it's such a unique skill you should probably hire that out I know it's nothing I ever wanted to do and so far I've been very lucky and succeeded in that goal of never indexing myself other than that one error I thought the index was actually short because the index things I never would have considered being the index so it's one of the things like layout or cover you really want to have an expert do it I would publish with APRES again in a second they've been nothing but fantastic and helpful any time there's a conflict or concern they cede to my expert knowledge which was great and on the other hand if I were writing anything shorter than this even nonfiction I'd probably do it myself a little more money that way is the question how hard would it have been if I hadn't had an in to break into the publishing industry and become an author the answer is not hard at all actually and well I know one of the persons who who got in contact and they love the suggestion but now that I think about it I recommend to them too so I guess that doesn't count I was told very clearly when I finish this book that as my editor there's sort of changes to the system but she isn't charged of picking out any of the two books that they published so I've written two authors email proposal just because I recommend someone doesn't mean they're going to publish the book they want the proposal to be the only difference is they know to expect you so having that can help if you have a friend who's an author for example and you know you have a manuscript in their style or when you send a letter you say you know this is my manuscript and usually you start a query letter with a synopsis at the end you know I admire the book you did here for my friend you submitted to you you worked with those scripts and they recommended that your services they love you as an agent with the caveat that when you say you represented my friend that must be true so my good friend Stephen King said that you'd want to look at this that's not going to help you so it can be a little more daunting but other than the fact they asked me as it turned out but if I had submitted to I don't I want to say submissions at apress.com but I don't know I'd email her directly to apress.com or any publisher you should find a place for submissions and it's scary to just send a query letter or so on but in real life that's how books get found and published I had a little bit of a leg up because they were expecting something I got to ask them you don't give me books giving suggestions what would you like to write on when you feel comfortable I said well what kind of books would you like and they didn't really want to tell me because they didn't want to tell me what their publishing goals were for the next two years because they don't want to tell suggestions whether it's beginner or intermediate or advanced level books on this topic or general topics then I was sort of on my own so it's actually pretty easy to break in easier than you would think if it's nonfiction you have to have the book nonfiction you find a publisher you find who it is books you admire if it's in that style because that's what they sell you go there go to their website, look for their submissions page they'll say they'll tell you exactly what they want and if you are smart you will give them exactly what they want because that's the easiest way to discount a problem author who's going to knock you things the right way and create lots of work they can't even get the submission right so double check all the submission guidelines they're not hard and yet people still don't do them be certain fondness in that they'll say I want this or that they actually gave me a guide I believe A-Press said we want this and this and that and it was pretty easy it's probably online A-Press is really open I'll give you some idea what to suspect any other questions alright well thank you so much thank you very much Mr. Dean and so before you go on the back table there is a pamphlet of information about this and so I have a question who has a friend who they want to use Ubuntu but is afraid to use Ubuntu you don't count anyone have a friend who you know or someone who is just starting out and just kind of wants to know where to start because I will give this copy of my book for free to all those people do you want it you can have it, thank you