 So hey everyone, I'm Syed, it's great to be here and I work as a senior software engineer at Red Hat. Today I'm going to be talking about leading and growing an open source community. So let me go to the next slide. So let's talk about what open source is and what does community leadership mean. So as contributors to a project become more familiar with how the project works, they may wish to become more active in helping the project grow. Ultimately this means they will be taking on more responsibilities within the project. So today we are going to discuss in more detail what this means. What it means that is to lead an open source project and a community. The fact is that contributing to an open source project and leading that project to completely different modes of engaging with that project. So let me try to explain why. Let me move to the next slide. So as a contributor to an open source project, your duties to the project may be more or less straightforward. Fixed bugs, answer questions in the project's channels, etc. When assuming a position of leadership in the project, your real role becomes more comprehensive. You may have to drive technical direction, begin speaking with the authority for the project in public venues, just conferences, initiate programs to recruit more project members, or change the project's processes and policies. So in short, you are now assuming increased responsibility for a project success or failure. Next slide please. So why do we want to do that? Why do we want to take on responsibility for a project and a community success? There are many reasons to take on a leadership position in your favorite open source project. It may range from the needs of your employer as to your own personal joy. As you consider taking on a leadership position in the project, you might want to take some time to think through your motivations for doing so. Having a good understanding of why you want to lead will help you choose the best places for you to apply those skills and interests in the project. It might be a conflict resolution or better issue triaging processes to make sure that the users are getting more help quickly. And it's no secret that leading an open source project has many tangible benefits when it comes to seeking employment, but also many individuals choose a leadership position for the simple reason that they appreciate their social connections in the project community and wish to be of greater service to others in the community. So if we move to the next slide, we will explore some of the goals for today. So we would be talking about the responsibilities leaders have, the transition pathway from contributor to leader, and some ways in which excellent leaders help the project avoid common social challenges. So our goals for today include understanding common challenges associated with expanding, maintaining and popularizing an open source project, exploring steps how new community leaders can begin to address those challenges and identify steps where leaders can take to achieve project success. So an additional note over here would be that I personally can't see that you will leave our time together equipped with everything that you could possibly know about being a project or community leader. Every project is different and I don't know a free bit of advice that can help you lead each of these different individual projects. So you will need to translate this advice into your own context. What we are going to do today is examine the most common avenues for meeting the challenges new leaders face, general policies for getting started that we have found to be the most fruitful across communities. So moving on to the next slide, we would be aware to begin by stressing that anyone interested in assuming a leadership role in a community driven project will need to begin by asking three fundamental questions about that project. These are how can you expand the project, that is the add contributors and increase participation in the project, how can you maintain the project, that is ensure that your project is, that it is sustainable and that the public stays on course on pursuit of its mission and vision and how can you popularize the project, that is increase its feasibility, make it an appealing destination for users and contributors and keep it relevant in an ever growing ecosystem. For the remainder of our session today we will focus on each of these three questions. So the first thing that we will be, the first question that we will be talking about is the, so Leica, can you move to, yeah, can you just move to slide 11? Okay, thank you. So let's begin with the challenges expanding the community, like how do you increase community participation and contribution. On the next slide, yeah, so we would be talking about two types of challenges here, one is community challenges and the other one is technical challenges. So on community challenges include things like undocumented or insider information or what we call folk question. This talks about excessive and undocumented insider information or folk question which makes newcomers not have enough context and lacking that context makes them feel excluded. Then there is the issue of unwelcome social dynamics. How welcome do you feel when you join the community, especially how welcome do new contributors feel when they join the community? Perhaps the project is not as inclusive as it could be. Undifferentiated contributor base. Communities lacking diverse contributor base may not seem welcoming to newcomers, especially those from underrepresented groups. This means diversity along all axis. Things like types of skillset, vendor diversity, number of industries represented, gender diversity, racial diversity, geographic diversity and the list can go on. So when working to grow your community, if it appears that the community is only comprised of one type of contributor, people who are not like the existing contributor base may not feel very comfortable joining. And the most obvious challenge again is language barriers. Communities that communicate in only one language can be intimidating for those who don't speak that language. Moving to the next slide, we talk about the technical challenges. So this includes lack of clear onboarding and getting started documentation, lack of peer documentation on ways to get started and deter newcomers, aligning contributors with project needs, aligning contributors with different skills to the most appropriate domains inside the project can be challenging. Finding contributors with specific domain knowledge can be another challenging part. How do you find additional contributors with specific domain knowledge of very specialized use cases? That might be really difficult at times. A project's code base may be directed at specialized use cases. The project might be relatively niche. So locating additional contributors who share its typical use cases might be really, really difficult. Then again, there is unintended use cases which users might be applying a project software to situations that the project's founders have never thought about. So the founders might themselves be limiting their outreach. So let's move on to talk about contributor pathways. So every project and community will need to address these challenges in ways that are most effective for them. However, in general, we suggest beginning to address these challenges by examining a project's contributor pathways. So in the next slide, we'll talk about what these are. So opportunities for new volunteers usually begin to lending the unique talents to an open source project are called project contributor pathways. So the greater the number of contributor pathways that your project features, the more likely it is to recruit participants with various skills required for project success. So when you're thinking of ways to expand your project, focusing on contributor pathways is a great case to begin with. So in the next slide, let's take a look at some common contributor pathways. So firstly, here are some for pathways with community focus, things like documenting software processes, onboarding and mentoring new members, localizing content into various languages, copywriting, managing social media, organizing events. So does your project currently offer new and existing contributors opportunities to contribute rewardingly or even take ownership of work in each of these pathways? That's the question over here. So again, in the next slide, let's again examine some pathways with a more technical focus. So some of the technical pathways might include adding a new feature and documentation, fixing existing bugs and triaging issues, refactoring existing work to improve it, performing quality assurance, improving user interface and user experience, release engineering, creating and maintaining project growth map, code and user interface localization and so on. So again, ask yourself, does your project currently offer new and existing contributors opportunities to contribute rewardingly to or even take ownership of work in each of these pathways? If not, one general way to begin expanding your project is by making concerned, if concerned, efforts to formally like refine, document and advertise these contributor pathways. So moving on, in the next slide, let's explore these challenges associated with maintaining a project, sustaining its growth and as our prior expansion efforts succeed. So in the next slide, now we look at some of the common challenges again. So this includes additional infrastructure and overhead, adding additional tooling and infrastructure creates additional work of coordinating participants in a time otherwise which could have been spent in the project code or especially for small leaders who may have to take on responsibilities for deploying and maintaining new systems in addition to coordinating volunteer work. Then there's a challenge of preserving community intimacy. Preserving the intimacy of community is very important because it's this community intimacy that makes it so appealing and it requires more care as the community keeps on expanding. So very few people may actually know one another and when this starts happening, social bonds weekend. The next thing is keeping a growing number of participants involved. So keeping all participants informed about project development requires more time and effort as that community is large. Managing competing visions for the project as a community grows, competing visions for the project might create contributor tension, especially people who are newer to the project might feel confused where should they proceed with which vision can they focus on. And the last point again is architecting and scaling a mission and vision. Projects that begin as a personal hobby don't always have explicit and clearly defined community mission and vision statement. Without these, projects don't scale well. Moving on, let's talk about governance models. So in the next slide, yeah. So every project and community will lead to address these challenges in ways that are most effective for them. However, in general, we suggest beginning to address these challenges by examining your project's governance model. The specific combination of rules and customs that define who gets to do what and how they're supposed to do it is called a project governance model. The better you understand the project's governance model, the greater your chances of successfully helping that project evolve. So as you are looking for ways to help sustain project growth and success, we recommend beginning by examining your project's governance models. In the next slide, we talk about six common governance models found in open source projects. So every project has a governance model, even ones that say that they don't really have one. So begin by pinning down specific details of the way the project is running today. Here's a list of the six most common governance models, especially in open source projects. We don't have the time to explore the individual model. However, it suffices to say that knowing how your project is running and who is making decisions is a perfect way to begin thinking about making the project more sustainable. If your project relies on too few people, if decisions aren't being made in the most effective phase, then begin by addressing these issues. Moving on to the next slide, we talk about the dimensions of governance. So fundamentally, you will need to begin thinking about various roles people play in the community and the various policies and procedures that govern and direct people in those roles. Roles are the specific functions and contributors perform in and for the project. Roles have rights, responsibilities, and expectations around them. Make sure that these are explicitly documented. Policies and procedures are the specific rules and processes that direct people in particular roles and define the limits of acceptable behavior for the project, best practices, etc. So make sure that these are also explicitly documented. Simply documenting roles, policies, and procedures will go a long way by helping your project become more sustainable. And finally, moving on to the next slide, we talk about popularizing. How do you popularize a project? How do you increase a project's visibility, making it an appealing destination for users and contributors, and keeping it relevant in an ever-growing ecosystem? So in the next slide, we again talk about the form challenges. So these include increased competition for contributors' time and energy, competing for contributors' time, attention, energy is becoming more difficult than ever as the number of open source projects increases globally. Community materials available in a limited number of languages. So when projects become popular, they connect with diverse groups of contributors. But often what happens is that the project materials are only available in a limited number of languages. And if your community is not communicating in English, many people may not even be aware that it exists. This is a very common challenge across all, like, most major projects, I would say, probably. Then there is the growing threat of maintainer burnout. As the project becomes more popular, maintenance might experience burnout when trying to keep pace with it, mismatched expectations between enterprise users and hobbies is always a big challenge. And then there is the proliferation of platforms for user engagement. Finding the best ways to reach up to potential users and contributors can be really time-consuming, especially given the way people choose to consume information. So users now expect to hear things about, like, hear about things on platforms like Reddit, Facebook, Twitter, and so on. So figuring out where to meet people and where they are when you are, like, and where you are is a very tricky question. And that becomes a very big challenge for the community. So let's move on since we are almost out of time. Let's talk about reward models. And so to interrupt you, we have only one more minute, and we need to... Okay. Okay, sure. So as with other challenges we addressed so far, we could discuss many things here, but in general we have found that focusing on a project reward model is a great place to begin with. So I won't talk much about reward models because we don't have much time over here. So if you could just move forward a couple of slides to slide number 29. Yeah. So there's an overview of general kinds of challenges. This was more of just an overview of the different types of challenges that you're going to face as you assume a leadership role, expanding the community, maintaining that growth sustainably and popularizing a project along the way. We are already out of time, but yeah, just to give you a sense of light. To do a quick review, here's what we might have next. So in the next slides, we just wanted to talk about measuring success, but I knew I would be out of time. So here are just a few keywords to remember when it comes to technical contributions. And if we move forward a couple of slides, again, I did a quick workload of how you can track non-technical contributions. So yeah, and in the end, I would just want to say that, you know, people choose to lead open source projects for various reasons, including organizational needs, a sense of personal responsibility or personal fulfillment. By choosing to lead an open source project, you are especially assumed an increased responsibility for that project's success or failure. New community leaders face challenges related to expanding, maintaining and popularizing their projects, and they can begin to address these challenges by examining their projects. Contribution pathways, governance models, and reward models. So they will need to determine the best way to gather feedback from the community and to communicate the value of various stakeholders. So with that, I would like to conclude my talk or I would be sharing the slides on the Discord channel and with Venka so that you can also share it. Okay.