 Welcome everyone to the session of Unlocking Open Source Commitments for Ancient Community Handbook Best Practices to Foster Inclusivity and Diversity. Hi, my name is Jaskeer Singh and I'm working as a Open Source Strategist and a writer for Lost Chaos. It is a project under the Next Foundation. And today I'm co-facilitating the session. Yes, hi everybody. My name is Naritsi Sanchez. My pronouns are she, her. And I'm currently the Senior Open Source Program Manager at GitLab. Formerly, I've been the President and Chairperson at the GNOME Foundation. And I helped start Endless, which creates a Linux-based computer for people with little to no internet access. It's great to be here with you today. For your information, I would be leading the first half of this session. And the second half would be led by GNOME Foundation. So let's get started. So throughout this session, you can expect us to like we would be discussing about what is a community handbook and why is it important. Secondly, we would also be talking about the components of a community handbook. Last but not the least, how you can exactly join the movement. Awesome. Let's get dive into it. So talking about the attributes of a community handbook, it gets generally divided into four different phases. Documenting the processes. This is where you have to define all the processes involved inside the community. And this is the place where the new commerce and existing poverty members can understand that what all processes are involved inside the communities in order to omit any kind of leadership. Centralizing information is very important as well. There should only be a single source of a tool for finding how to do things inside the community. You don't have to replicate other things at different places. It just should be that the things are kept at one place. On-boarding the new commerce is again the important phase where you actually tell the new commerce or even the existing community members that how they can participate inside the community that what all workflows or the project history they have to understand before contributing. Accessibility and easily statistical. This is the thing which we have to keep diversity in the mind, taking into account some of their experience. Next slide please. Community Handbook also enables diversity. With this, it enables the geographic diversity. Like this is where we document processes that enables asynchronous working across different time zones. And people can generally utilize the translators for some kind of those tools to help them understand it better. Accessibilities, and this is where we keep those guidelines in the mind that enables people to access the content better. Inclusive language is again the important thing inside the Community Handbook. And this is where you don't have to use those phrases or sentences which actually affects the certain group of people. Community Handbook also creates transparency and openness. Here are three different examples of how it does. It involves contributing space. People should know that what you're working about. It also holds community accountable to their taxes. For example, that suppose if any community is working on some kind of feature or a book and they want some kind of user input. I mean like it kind of just a feedback from the user. But for this thing, they have drafted few of the key points inside the Community Handbook, but they're not falling off that. And they're just using common public channels just to communicate and get into their feedback. So this is where the challenge comes. So you just have to stick on what you write inside the Community Handbook. Or else just update the Handbook accordingly so that people can know that what the processes are and how they can participate inside the community. It also allows people to replicate processes in other communities. The world should know that what you are working upon and they can just adapt the things from your input, whatever they find very well. You don't have to replicate everything. Here we would be talking about the two different Community Handbooks where I would be discussing about the chaos project. And the Kittler Handbooks would be like you would be hearing about a Kittler Handbook strong news or something. So when the chaos was established as a part of the Linux Foundation project, there were a lot of discussion around the community that how and what all things are required in static community to adhere to words to processes or lay down the processes. So there were a lot of discussions around in order to adapt the Community Handbook for the chaos project. So for your information, this project was proposed inside the Google Season of Dogs. So Google Season of Dogs is one of the program run by the technical writers, work with the open source organizations, help them build better documentation for the projects as well as for the communities. So I was lucky enough to get accepted as one of the aspirant with the chaos project where I contributed towards the chaos Community Handbook and it was super fun. Once my proposal was accepted, there were a lot of discussions around what best tool to adapt or like what what all documentation tools we can do with and we finally ended up using it. It's not even my favorite but it's something which actually provides you with a better user interfaces, some some key features we could save with some better editing tools, even like it's just more user friendly when it comes to working with different tech writers at the same time. So it's really amazing. The Community Handbook chaos has been divided into four different sections. It talks about about this is where the mission, the values of the chaos project, the leadership importance of the community. You would be getting all of the information regarding these things under the about section. Community section is more specific towards the chaos project and this is where you will find the information about the initiatives or the programs the chaos had. The contributing is again, which is very important for any of the resources. And this is where people can know that how they can participate inside the community like they can contribute towards designing the documentation development even for outreach. So you just have to draft the workflows or the processes involved when contributing. Since common chaos project has been participating in various development programs. So the mentorship section basically covers about those programs in which the chaos has participated. Yeah, it's really great. Just have a look away. Awesome. So the section that the page you are seeing. The left part of here is basically the snapshot taken from the chaos comedy handbook. The left side of this context is the left Napa which contains different sections like about here is the section and the chaos history values roadmap these all are the subject. The central part of the page is the exact information which you want to provide to your users. So you would see here is a visual identity. I have drafted for the chaos history. And yes, again, it is always suggested to have something like I'm like just giving the context of a page with some visual identities or visual images so that people who don't find the reading the whole specific page can understand from the visual identity of the chaos history. You would find out how chaos evolved and how it has transitioned from different phases. This always interest you like just have inside your comedy handbooks. Okay, so this is again the second page taken from the chaos comedy handbook, which talks about the leadership processes. Since chaos has two different types of leadership inside the community. So this specific page actually demonstrate that how one can get involved inside the community or how one can exactly realize leadership inside the community. Similarly, we also have different pages. Like if you could see on the left Napa. Now you could be hearing about the GitLab handbook from the university. Awesome. Thank you so much. Just correct. Hi everybody so at GitLab, we are an open core company. So that means that we are built around an open source project. And that means that it's really important for us to work alongside our community. From its very beginning, GitLab had this transparency and openness in mind, which Jessica mentioned before. And it's part of the reason why from the very beginning, we adopted a handbook. At GitLab whenever somebody on boards as a team member, they're part of the onboarding process walks them through the handbook and how to contribute. Because everybody will need to maintain their own page or contribute towards their team pages. And contributing to the handbook does require editing through merge requests or MRs. And while this can seem a little bit scary to people who are not developers and not familiar with merge requests already. It's actually very easy. For example, in the screenshot, you can see how there are different ways to edit the page. You can open it in Web IDE or open in a static site editor or view the source. And this provides different ways for people to do so. I personally like the format where it basically looks like a Word document to me with markdown. And so I've become familiar with using merge requests and cannot and can edit the handbook very easily now. And also other web pages that require, you know, merge requests. And for me, it's already unlocked other things that I can contribute to. With our GitLab handbook, one of the things that's really important is to have a table of contents and a search bar to help people navigate. The handbook, the GitLab handbook is over 2,000 pages longer, you know, has over 2,000 pages, which is a lot of content. So it's really important for people to be able to search through it easily. As we talk about updates, we have this thing called code owners for each page or each section of pages. And what this is is basically people who are designated to make sure that the content stays relevant and that it's constantly updated with the latest information. It's kind of like having a project maintainer where somebody, you know, is actively working on this where they get the final say on whether something stays in or, you know, is left out, etc. And I want to mention that this is distinct from GitLab docs. GitLab docs focuses on product documentation and the GitLab handbook focuses on process documentation. Each team has to maintain this here on this snapshot. You can see the people group, engineering, marketing, sales, finance, product, legal, everybody must maintain their pages. An example of this just that you can see a little bit further is the open source program page that I maintain. On it you can see things like how to reach us, what we're working on, what our goals are for this quarter or what metrics we use to make sure that the program is succeeding. It also goes into really detailed things like what product skews we use for the various programs that we run, or, you know, who qualifies for the programs, etc. The point to this is to have so much detail that if, for whatever reason, a key person has to transition away, somebody else can step in and take over. And this with community, with communities is really important because a lot of us are really worried about the bus factor. Basically, what that means is like, if somebody gets hit by a bus, you know, can no longer collaborate. There are core maintainers that people are worried that if they burn out or, you know, just have a life change and can't contribute anymore, like what will happen to the open source project. And by having such detailed documentation, it again allows for smoother transitions or for more people to be able to help out for more delegation to be possible. So community handbooks in that way can even help towards preventing burnout or helping with that and easing transitions. At GitLab, we have a handbook first culture. And what that means is that you always respond with a link. If you can't find a link with the information, or if you can't find the information and provide a link, then you need to write the information in the handbook. And what this means is that it gets people in the habit of one, making sure that the handbook is updated, that it's easy to understand, but also that it's easy to find. Because maybe the information does exist on some obscure page, but nobody's ever going to find it. So by having everybody in the community constantly linking to the places and making sure that, you know, it's easy to find, it enables people to just be able to jump right in themselves and search and find what they need. Okay, so hopefully now Jessica and I have given you a little bit of background about, you know, what it is, why it's important, and some examples of the ones that we're working on. And now we're going to cover how you actually begin creating a community handbook. The first thing I want to mention here is that we are still defining these standards for what a community handbook is. We're creating templates and guidelines for other communities to be able to quickly and easily create their own. Jessica and I first started talking about this topic at Moz Fest earlier this year. We have lots of people interested, but people always kind of got stuck at the how do I get started and you know what specific examples are there. We joined I triple ESA open the documentation and curation team, and we're working on this. We'll share some of what we've started to talk about already, and we invite you to join us to keep defining these. So the first thing that we all agree that should be part of your process for creating a handbook is creating buy in among your community. To do this you want to document your proposal in a public way. So that might be in issues or a wiki and something that allows anybody to be able to view it. And then you want to request input from the community. They might be able to do that by commenting on the issue itself, or you might want to create an email and posted on the mailing list, inviting people to go view it and give your feedback. Once that's done in the first you have some ideas about what the community thinks and you know maybe have started to iterate a little bit on it. And then you can get formal approval from the governing body. This might be the board of directors and executive leader, some other leader within the community. And this just gives your proposal and, you know, this whole process, a bit more legitimacy. So if you're in a working group, or tap into a relevant program, the one that Jessica mentioned was Google season of docs, and you want to establish regular meeting times, maybe once or twice a month, or every week, you can decide. In the process, you want to regularly update the community, so that they continue to give you feedback. The more that the community feels that they're able to contribute to defining this for, you know, the community handbook for their community, the more they're likely to actually adopt it in the end. And then you want to just throughout the process and put change management skills to roll this out. And I wanted to specifically include this terminology change management, because then it's a skill that we can all learn to help us be leaders and be able to have communities adopt big changes. The main is, you know, you announce it at an annual board meeting as and have people vote on it, or it might be also training influencers to update the handbook so that then they can also train other members of the community. There are many different things you can do. And I encourage you to read more about change management skills to improve your own. If you are deciding what tool to use. We don't want to give hard recommendations, but we will give you some desirable characteristics to keep in mind. The first is that you're the tool you use should be searchable. It should also be accessible, visual user friendly, and it should have version control, because the worst thing would be for somebody to delete all the pages you've worked on and not be able to get it back so make sure that you can revert changes. One of the tools that we recommend looking into our get lab pages, get book, get hub pages. There are many others, but these are some that we encourage you to look into first. When you think about crafting your handbook and adding various topics. These are some things that we think should definitely be included. There should also be something about the community and about the project. So what's the mission, the vision, the values, the history, the governance model and the code of conduct. There should also be something about the specific teams and groups, and how to onboard onto each team, what specific processes they follow. There should also be a sort of meta topic about the handbook itself, because again you're trying to encourage everybody to contribute so you want people to understand when the handbook is used how to update it, and the whole process around it. Consider adding something about the social factor. So, in case somebody comes upon your handbook, how do they meet other community members and what tools do you use to communicate. How can they talk to other community members as they consider making improvements to the handbook page. Another thing that you'll need to do as you create your community handbook is establish writing style guidelines. So keep the following in mind as you do that. The first is inclusive language, which again Jessica mentioned before, but I just want to reiterate how important this is. And it includes things like not using acronyms that you know people may not know and feel either, you know, just like they can't contribute, because they don't know what's going on, and or things like using the same gendered pronouns all the time and not being inclusive of others. And also things like using certain vocabulary that might be exclusive. So try to make sure that when you're writing, it's made so that anybody can easily understand it, and you're not using, you know, vocabulary that that is a little bit difficult for for people to understand. You also want to keep in mind accessibility, and just for tonight have been men have been asked about this specifically a few times in other presentations. So we have some tips, we have a link to some helpful resources around how to write with accessibility in mind. At the end will provide a link for you to follow in case you're interested on that. And the other thing is just to keep in mind your tone and voice for the handbook, so that it's consistent throughout our updates handled. This is something that is really important for you to instill in your community early on. So, as I mentioned before there's a handbook first culture. So this is helping everybody get into the mindset of responding with a link. And also considering adding those code owners or maintainers to just add an extra layer of accountability and responsibility where, you know, they're in charge of making sure that their sections are updated or that they can have a little bit of can have input into what should go into their section or not. One moment slides are falling apart. Here we go. The next section is just really how you can join the community handbook movement. We hope that we've gotten you excited about this and we'd really like you to join us. So here is a QR code that you can scan and what it will leave you leave you to our slide decks that we have with links to the various resources that we've mentioned throughout the presentation. We also, as I mentioned are working on as part of the IEEE essay open community. And so we invite you to define the community handbook standards with us. The other thing that you can help us do is coin the term so that people understand exactly what we mean by community handbook. This is different than the regular product documentation that already exists. And then we invite you to spread the word in your communities. Feel free to copy any of the slide decks that we already have to pitch the idea further. We also welcome other outreach ideas. So feel free to connect with myself or with Jessica at LinkedIn or Twitter, and just let us know what you think. And with that, as I mentioned, we have a lot of resources, links to the pages that we've shown as screenshots here, and we hope that these will be useful for you as you're creating your own handbook. Thank you so much for joining our session, and we will see you around. Thank you so much.