Channeling a community to write a book

Speaker 1: Good day, everyone. My name is Felicity Brand, and today, I'll be talking to you about channeling a community to write a book. I'd like to start with a gratitude statement. I'm really grateful today that I didn't have to go to the doctor because my four year old daughter came in and said, mommy, I have a bead up my nose. Thankfully, we were able to blow it out.

Speaker 1: I'd also like to just, express my gratitude for being able to speak today at DevRelCon. I'm really excited to be able to share this story with an audience of, developer advocates, community builders, and people working in DevRel because I think it's, I think the story of how we wrote this book is just the epitome of developer relations. Let me just get to the next slide. This is me. I identify as a technical writer.

Speaker 1: I call myself a technical communicator. My current job role is communication consultant. I'm freelance. I work remote and asynchronously. I work for a company called Open Strategy Partners.

Speaker 1: We're an agency in the DevRel space. We help technology organizations, be they private or open source, communicate the value of what they do. And that may be to increase their reach or user base, increase code contributions, or just grow their community. So I want to talk to you about how we wrote this book and why you should do it too. As I've said before, I think the story of this book is the epitome of DevRel.

Speaker 1: I think it's a joyous expression of developer relations in terms of in terms of speaking with a whole lot of developers in a language that they understand, and on the flip side, sharing the knowledge of developers to a broad audience, that speaking listening activity. So, yeah, I'm talking about an open source product. What I'd like you to imagine is your own product. So whether that is open source or private or commercial product, you've still got a community around that. So, you know, I'd really like to kind of inspire you with this story.

Speaker 1: And and hopefully, you will do it too. A little bit about TYPO3. So TYPO3 is a an open source CMS content management system. It's it's an enterprise product. It's massively multisite, multilingual.

Speaker 1: It's quite a powerful CMS. The product has a vibrant, mature community. It has a membership organization, and it also has a 100% wholly owned subsidiary, of this commercial arm. And so that company provides long term support for the product. It provides other services, looks at some of the educational streams and certification.

Speaker 1: It also does, like, project project audits, and other cool things, to basically kind of support users of the product. So the reason why we wrote this book is that the community and the product still wanted to grow. They still want to increase their reach. They wanna kind of get a bit more international. They're big in Europe.

Speaker 1: They wanna reach The Americas and APAC. They wanna increase contributions, code contributions, and just generally grow their community. So it was decided that a book was was going to help with that strategy. So here is, me and my fellow authors, Heather McNamee and Geoffrey Maguire. We our publisher, A Press, wouldn't let us put a community as the author name of the book, so we had to choose amongst ourselves, which of us were going to be named as the authors.

Speaker 1: We were already embedded in the typo three community, So it was a, I guess, a natural kind of fit for us to help write this book. And we wanted the book to be not just for coders, not just technical information. We wanted it to open many doors into the product, and provide different kind of orientation and learning paths for various people with different goals. And we recognize that although we are, in the community, we're not the experts. So it was really our job to, channel the expertise from the community and and put it into this digestible form.

Speaker 1: We so so here's here's how we structured it. Four overview chapters and 10 tutorials. The idea is that it is catering to, newcomers to Topo three, so not just new developers, but anyone coming in to look at the product. And it's foundational, so, you know, we didn't want to have to update it every new release. So it covers the the bones and the foundation of the product and sits companionably amongst the other resources.

Speaker 1: So we've already got a great website. We have official docs. The book isn't seeking to supplant any of that. It's it links out. So, yeah, it's just another kind of asset in that the the content canon for typo three.

Speaker 1: So just briefly, I'll hit on what's in the book. So our chapters were, an initial kind of showcase for the features of the product. We've got case studies in there. It touches on the community, where you can find help and other resources. You can see what other people have done with type o three and, you know, just demonstrating the features and strengths.

Speaker 1: You can't do anything without a plan, and that's not type o three specific, which is what makes this book useful for any newcomer to web development. We've got how you'd go about planning a web project, as well as how you'd plan a site with Typo three and taking into account Typo three's approach to layouts and, rendering and functionality. We put in a chapter about the nuts and bolts of typo three and, developing with the CMS, what you need to know to build it and extend it. And lastly, the, boring but important information about, upgrading, security, hosting, caching, finding out what typical maintenance is required, and, setting expectations around updating and upgrading. Our practical guides, we were really careful to structure them so that, they had clear learning outcomes.

Speaker 1: So we did the why plus the how and just tried to make, make them really practical and clear. So you can work through them sequentially, or you can dive in and, do them discreetly, cherry pick what you wanna do. The last two there are pretty interesting. So we wanted to cover useful information about selling typo three, you know, selling an open source product, if you're an agency a web agency. Kind of some approaches and techniques and, conversations to have with potential clients about that.

Speaker 1: We also, included a chapter on debugging and troubleshooting. So that was more about kind of, tips for young players and places to look and how to go about problem solving in the product. Yeah. So something I got from Sam Juleen, who is a developer advocate, and he writes the Developer Micro Skills blog. He kind of boiled down or boiled up the idea of developer advocacy into these two broad categories of speaking and listening.

Speaker 1: So he's talking about, you know, literally speaking at presentations, but also, you're communicating to a technical audience. And then that listening part of, getting feedback and acting on that and listening to your experts. And so what I wanted to say was the way we wrote the book initially was just immersion in the community and heaps and heaps of listening. So, we went to loads of events. We did lots of interviews, face to face and written interviews, and just spent time speaking with, you know, these highly technical, passionate developers about about the CMS, what they liked about it, the different use cases, and the very specific areas that they worked on.

Speaker 1: And so we gathered a whole lot of raw data, and then we brought our superpowers. So, Open Strategy Partners, we're a team of primarily, well, technical people, but we write. We create a lot of content. And so that's what we could bring to this project, is our structure and processes to turn all that raw data into a cohesive whole, to turn it into a book. Right?

Speaker 1: We worked in Google Docs, which was great because it allowed us to share the content amongst the community. We could draft chapters. We could share entire chapters with members of the community and get their feedback. In some cases, some team members, community members, directly contributed whole swathes of content when the spirit moved them. And so then I could come in and edit that and and make it consistent.

Speaker 1: We were really proud that we we kept it in the community. So we we can truly say that this was a community effort, this book, because we are the as authors, we're community members. All of our contributors came from the community. Our publisher, Apress, you know, was able to source reviewers, but we chose technical reviewers from within the community, so that we could just be absolutely sure of the accuracy of what we were writing. The typo three community has their own design team who create graphics for their website, and so we engage them to create diagrams and graphics for the book.

Speaker 1: And code testers. Yeah. So we wrote our tutorials, our 10 practical guides at the end of the book, and we had three members of the community step up to test those. And APress provides a code repo on GitHub for every book they publish, so our cotesters were able to verify that code in our repo. And the other cool thing is that, the repo also holds out errata.

Speaker 1: So, APRES has a process for being able to submit errata, and we can then handle that in the code repo. So that's cool. Okay. So you might be thinking, we've got a website. We've got official docs.

Speaker 1: So if you've got new folks wanting to come in and learn about your product, maybe you send them to the website. If you've got devs wanting to get started with your product, maybe you send them to the quick start guide. I would argue that a book answers the need much better. It lets you meet the needs of different types of readers in one go, and that's the power of writing a book. So rather than have a collection of blog posts or tutorials, it it gives you the opportunity to really carefully curate your message.

Speaker 1: And that lets you target these different readers. So books are this particular book is foundational. Book books are linear. So you if you've got a real newbie, you can give them a book, and they will sit down and read it cover to cover. They'll get the overview.

Speaker 1: They can work through the tutorials. You may have experienced devs who are new to your product. So they probably wanna understand the basic principles right away. Maybe the system architecture, development approach, coding standards. So you're not making them wade through docs to get that information.

Speaker 1: The book can also help decision makers or maintainers, anyone evaluating the CMS. Perhaps they're gonna be maintaining the things, so they wanna know about release cycles, how to upgrade, performance, security. They might eyeball the guides at the end. They probably won't work through them, but they'll certainly scan them to get a feel for how everything hangs together. So you're not making them wade through your docs or your website to when you're writing the book, you can kind of serve that up to them in a neat little package.

Speaker 1: So books ain't dead. Print books still outsell ebooks. And you shouldn't underestimate the affordance of a book. You could pick it up. You can hold it.

Speaker 1: You can have it on your bookshelf in your Zoom background. Instead of reams of online articles or procedures, you've got a tangible portable asset that goes where you go and tells the story of your community or product. So what I wanna leave you with is the message that you should consider writing a book. By creating a book, you're tapping into the expert knowledge of your developers and channeling that into this useful asset. And you're creating a resource.

Speaker 1: You're creating a a curated resource to help other developers learn. And on the flip side, you're telling the story of your product and, like, sharing the value of what your developers have built. Okay. Well, that brings me to the end of my presentation. Thank you very much for your attention.

Speaker 1: I'm sorry. I'm asleep right now, so I don't think I can handle any live questions. But do please get in touch with me because I'd love to talk with you about, writing a book if you wanna approach that. Or if you've done it before, I'd love to hear your story. So thank you very much.