 open source way, the guidebook for community management best practices. My name is Karsten Wade, and I'm a community architect in Red Hat's open source program office. Although I served as a project lead for the 2.0 release, I'm otherwise one of many writers, editors, community experts and open source practitioners who worked on this guidebook. And you can find a full list of contributors at the end of the guidebook, which I'll be showing you in a few minutes. So this is an opinionated guidebook. But frankly, much of the really good guidance and practices around creating and sustaining an open source project are fairly well known by experienced practitioners. It's certainly not a lot of secret sauce in here. But the impetus for this project came out of a number of discussions over recent years in response to the ongoing growth of new communities and people who are new to open source in general. The consensus of those discussions is there's a need for maintaining a guidebook written by a community of practitioners for all open source practitioners, bringing a diverse range of experiences, but having a common understanding of what makes a practice best. And there are many ways to share knowledge and learn. And this guidebook by this community is for the reader and practitioner who enjoys, prefers or learns best from and among a group of like-minded people. People who like to form as a community of fellow learners and practitioners. This guidebook is centered on community management best practices. It allows you to start from the very beginning to consider and engage with the open source way from the very beginning of your idea for an open source project. And it carries you through the creating through the sustaining of your project from attracting users to when they passed your scant barriers to become contributors. Before jumping into the guidebook and showing you around, let's take a moment and review the overall community growth method in the guidebook. And the method is generally mapped to the sections of the guidebook. When from getting started to attracting contributor users, guiding participants, growing contributors and then measuring success. When starting, you want to do the harder work of being completely open and transparent from the beginning, even when there is no one there watching would be open and transparent. And putting up the infrastructure of participation with barriers appropriately lowered for users and contributors. All while focusing on building something for your users. Make sure when those potential users arrive on your webpage, at the top of the webpage is a short description of the project software. It should include a purpose that users can understand and imagine. It should give them something to do right there, a call to action, download and try out, log in and try out, a quick start to use, and so forth. Making software and content your users need is one of the main purposes of an open source project. It is out of those users that most contributors arise from the enthusiastic advocates all the way to the most ardent contributors. As people try out and become users and explore the world around your software, make it easy for them to participate in whatever they find. Make information easy to find and form access straightforward. Make it easy for enthusiasts to share what they know about your project. The idea that contributors come from users was true when open source was characterized by the hub. And it is still true today when users of your software now include companies making products out of it and corporate foundations wanting a common platform for competitors to share. So whether your users are a broad base of individuals or small organizations or your users are some of the largest corporations on the planet, the conceptual math still applies. Of an entire corporate participant in your project, only a handful of people will contribute directly to the project in some fashion. Many others will contribute indirectly in their work supporting the overall user organization's contributions, sometimes behind the scenes for years. So that's it. The bigger your user base, the bigger the pool of potential contributors. So open source projects are a type of community of practice which is a group that gathers to share, learn and improve practices in a particular domain they're interested in. In the science that studies communities of practice, there's this idea of legitimate peripheral participation which describes how newcomers become experienced in eventually old timers in a community of practice or any collaborative project. From the Wikipedia page, quote, according to legitimate peripheral participation, newcomers become members of a community initially by participating in simple and low risk tasks that are nonetheless productive and necessary and further the goals of the community. Through peripheral activities, novices become acquainted with the tasks, vocabulary and organizing principles of the community's practitioners. Gradually as newcomers become old timers and gain a recognized level of mastery, their participation takes forms that are more and more central to the functioning of the community. End quote. One important takeaway from this is that contributors don't compare gliding in from nowhere. They are made from within the project. And while it is true that people with needed skills and expertise do come directly to projects to contribute, the process by which they arrive will have followed the legitimate peripheral participation path in some way. In the corporate contributor example, there will have been some period of precursory activity from the sponsoring organization and so forth that precedes the uplift to contributor. Once arrived, that person will still have to learn all the ways and means of the community before they can become an experienced and effective member regardless of their incoming cashier. So an important goal for a project is to be sustainable. This is about more than the economics. Although that is an important part of the conversation, all the money in the world isn't going to make a toxic community healthy again. A sustainable open source community is one that is able to take in new contributors and promote them to leaders without the stepping back of old timers, meaning the breakdown of systems. A sustainable community can have key maintainers able to go on long vacations or choose to step back from the project without scrambling and struggling. So in choosing what to measure for your community, maintain a holistic viewpoint and don't get stuck on simple first order data like average time to close a bug is the only thing worth watching and caring about. So as we get ready to take a look at the guidebook, I wanna share some thoughts about the flow of the book. So the guidebook can be entered into and used in a number of ways. You can read it from the beginning to the end and build your knowledge as you go. You can start with what interests you the most and follow some cross-references and skip around to read. You can come with a specific problem or general question, then find and read only the content relevant to your situation. It's most of the ways, I reckon. The chapters are written to work as a standalone set of principles and practices on a subject. For the most part, no chapter is a prerequisite to understanding any other chapter. We made the stylistic choice as a way to provide the most value to the reader without spending six more months polishing the chapters so they move together perfectly smoothly. Though most of the chapters are co-authored by two or more people with the merge work sometimes done by a third person. When we have a style guide to follow, you can sometimes tell there are different writers that work on a chapter. But overall, the content has been curated and polished to be useful for different types of reader's needs. We'll continue to polish the content in future versions so the reading experience is smoother over time. And that's open source content, release and iterate on improvements in the next release. So now let's take a look at the book. All right, there are a lot of different things about this book from the 1.0 version with the structure and the reading experience and so on. But a sizable chunk of the core ideas, they are much the same as they were 10 years ago. Most open source principles are larger the same or somewhat evolved. There are two key differences in the content itself from the past. Some topics that only got a few paragraphs mentioned in the past now have entire chapters. Take governance as an example. In 2009, it was much less of a popular topic beyond certain groups of people. By 2019, when we started outlining the 2.0 version, it became worthy of a chapter itself and in fact is the longest chapter in the guidebook. Some topics were not being discussed at all or openly in many community management circles. One example of this is the chapter on community managers self-care, which is currently the second longest chapter. So let's start looking at these chapters one by one. So first there's presenting the open source way, which is the introduction that sets the vision for the guidebook that explains how that vision is delivered in the sections of the shape of things, presenting assumptions being made, the structure of the guide and which I've described to some degree and a community practice always we build on itself. When it comes to getting started, this section is for the early worker, even work done before a community is formed to establish and set the right direction from the start. So there's community 101, which provides a broad overview of how to analyze your community and others. And then there's the new project checklist, which is a checklist of the elements that are typical and essential to starting a new project. It's quite like the one we hand out to red engineers and it's good for making sure that you've considered all the common stumbling blocks. Another is creating an open source product strategy, which is useful when you want to plan and prepare for creating a new commercial product out of your open source software project. In the section on attracting users, we have the understanding that you can't tell all the ways that you can attract your special users to your unique project, but this section can help you, it keeps them having them run away when they arrive, give them a friendly and warm welcome. Beginning with the communication norms and open source software projects. This is the heart and soul of how to prevent or deal with difficult and toxic situations, as well as the whole range of communication practices that keep things running smoothly. This ranges from project roadmaps to issue tracker best practices. The chapter to build diverse communities, make them inclusive first, explains why and how to focus on inclusivity as the first step of increasing the diversity of your community. This chapter offers an overview of efforts by various open source communities to make projects more diverse and inclusive. It also offers initial steps, open source community projects and project maintainers can take to begin building communities and projects that benefit from a diverse community contributor base. In this section on guiding participants, this helps you to understand general participants and enthusiasts. And in particular, why do people participate in open source communities, gets into the kinds of motivations that can help people to contribute to open source. They're extrinsic and they're intrinsic motivations. And growing contributors is a section with the most complexity, which is similar to the relationship of contributors in a project. From users to contributors helps you create a welcoming environment for newcomers who may or are interested in becoming contributors. Chapter, what is a contribution? It provides a short concise explanation of a contribution and then a list of examples. Chapter, essentials of building a community is a concise single chapter covering a range of essential components in building a community. Chapter on onboarding focuses on the basics and resources for bringing new contributors into your community. It describes the concept of contributor pathways as ways to help newcomers grow to become experienced contributors. In the chapter on creating a culture of mentorship, covers the concepts and practices for creating a peer to peer mentorship program. Most successful open source projects have formal or sometimes informal mentoring underway all the time and find it essential to contributor success. Projecting community governance is a thorough exploration of governance in open source communities. Community roles is a deeper look at the many different types of roles beyond code and other typically named contributions. Community manager self care represents a new area of best practices for the 2.0 version, one that I'm not sure many of us would have thought up or set out loud 10 years ago. The idea for this chapter came about during a content design workshop at Fosdom 2020 in Brussels and the community manager who suggested the content ended up writing the chapter for the release. So one note about this chapter, as with all our chapters, we had a subject matter expert or SME review the content. Where other chapters were in the domain expertise of other writers and editors, we could often cross check each other's work. In the case of this chapter, we asked Dr. Karen Hickson to review the chapter with the author. And then finally the section on measuring success encompasses the lifecycle of a project and the metrics you use to keep track of health and accomplishment as chapter on defining healthy communities helps you understand what a healthy open source community looks like coming from as high level right down to hands-on inquiries. These inquiries take a part and consider many aspects of a project as viewed from the outside looking in and from inside the project looking at itself. The chapter understanding community metrics is a discussion of the many types of topics to measure with questions for, question suggestions for each topic followed by a few sections on choosing metrics for your project. And we have a worksheet in our Git repo to work with this chapter. And finally, we have the chapter on announcing software releases, which is a step-by-step milestone-based process with templates for preparing for and announcing a software release. And rounding things out, we have the contributors chapters sections which include the chapter writers, all those who worked on the chapters themselves and then the project teams, primarily the editorial team that led the completion. All right, so let's go back to the presentation from here. And then as we come toward the end, let's just circle back for a moment to talk about the open source way community itself. Now it is a slightly odd thing to say we have a community of practice around communities of practice, but that in a very real sense is what this is. We are defining and curating principles, practices, and stories, reasons why, from across many open source projects, which are themselves communities of practice. And we're doing this as a community of practice ourselves. Anyway, our first efforts around curating, creating, finding and merging in useful resources for our useful users, such as guidebooks and courses. And then we'll continue expanding outward, make updates to the 2.x series with a print version and listen to what the user's contributors want next. A common tool of communities of practice is a meeting or a meetup to include presentations by members or special guests. With discussions among members about related topics. And I'm looking forward to starting those, the schedule for those later in 2021 and going through to 2022. So now we're coming to the questions and answers period. And in case you don't have any questions here, so I thought of all of you out of the material I didn't have time to include in the main presentation. And as I finish out, I just want to put the attributions of the images used in the presentation today, including the attribution, the attribution for the CC image here itself. And finally, thank you for spending your time with me and for sharing your attention. If you have any questions, feel free to reach out to me. You can find me on their social media as Quaid or you can email me at kwaid at redat.com. And I'm now available for your questions.