 Okay, we're live. Let's get started. Sorry for the delay. We had some technical difficulties Okay, are you ready to start? Um, I'll be sorry. I'm a little confused. I'll be now using the computer or the phone We're using the computer and we're live the session is live right now Okay um Well then sorry Not wanting to cooperate But I want to welcome everyone to our topic today About successions planning What is this claimer up front that we will be using open source as The way we talk about open source and but we do recognize that the free software movement is important and Have an important contribution to make and there's an overlap, but we'll be using open source now I've personally been part of open source for 15 years now and What I'm observing is that early members of the open source movement are Getting to an age where they are going to retire soon And this was also talked about yesterday in the keynote with Dirk and Linus and so this is what this session today is about How do we make sure that on the one hand we can carry forward the legacy and the movement? while on the other hand inviting in new people and get them up to speed on the values and how open source works and everything and We want this to be an open dialogue with everyone on this session Well only one of us can speak at a time We invite you to write in the chat ask questions in the Q&A window and we will get to those throughout the session We would like to introduce ourselves now. I'm Geo link Oh Just so that you're aware we will be upfront about our identities and biases in our background So if our introductions sound a little different from what you're used to that is because we want to be as transparent as possible because that Has impact on how we do a succession planning So my name is Geo link. I'm a cisgender gay white male 30 years old I grew up in Germany and an immigrant in the United States I've been privileged throughout my growing up my parents have been able to give me a lot of opportunities and My mission is to help open source projects and organizations become more professional in their use of metrics and analytics So I do this through my work in the chaos open source project and as director of sales of detergent Already shared why I think succession planning is important and I'm passing it on to Maria to introduce herself Hi My name is Maria Cruz. I'm a cisgender white gay female. I'm 33 years old I was born and raised in Argentina and I emigrated to the US almost five years ago and I've been privileged Similar to girl in that my parents were able to Support me throughout my studies and I I didn't have to work when I was in university My personal mission is to support on the represented groups to join up open source projects And contribute from their unique life experiences. I started my career in open source almost like in 2013 so yeah seven years ago when I started working for the Wikimedia movement Doing community engagement for learning and growth and now I am a program manager in the Google open source program office Where I focus on community engagement for cloud native projects and the reason why Succession planning is important to me is because I think there are already so many voices that are missing in open source and I think that if we are able to look at this from a diversity lens We could bring on more collaborators and contributors to the open source movement and I think With that I'm gonna pass it on to Michael Thanks Maria Hi everyone and thank you for joining us. My name is Michael Downing and I am a cisgender middle-aged white man I was born and raised in a small town in the United States Later attended engineering school and graduate school and then spent time working with and living in the developing world specifically Western Africa And I've been doing that over the past decade or so So I'm back now in the US and my day job is the director of community for the dial open source center at the United Nations Foundation Our work there is really focused around growing and supporting open source communities Working in activism humanitarian response international development With the goal of making them both more sustainable and more impactful Before I did this I helped lead an open source project called open MRS Which is the health IT platform designed for the developing world and really helped guide it from kind of a stealth research project and do more of a grass Roots volunteer driven community and so succession planning is really important to me And in our work we've experienced a lot of projects really not reach their full potential Or at worst be kind of an undeserved failure mostly because of things like burnout or changing organizational priorities a Lack of inclusivity and and software feature design all those things factor in And we've seen a project start to kind of scratch an itch that a developer may have But then suddenly become bigger and really more critical as other people kind of latch on to it And so this means maintainers and founders often they're not ready to think about things like long-term plans or sharing leadership with other people the good news and I think we'll talk about this today is there's a lot of not too painful culture shifts that you can really take and Start to change how a project can look at succession planning In my mind through the lenses of sustainability and through growth So I'll toss it over to Don who will join us as well Yeah, so I'm Don Foster. I'm director of open source community strategy and VMware's open source program office I'm also on the governing board and I'm a maintainer for the chaos project I'm a cisgender white 49-year-old woman who grew up in a rural farming community in Ohio I now live in London I've been privileged to have been able to get a computer science degree that allowed me to travel the world Not right now, but before while doing interesting work in the technology industry And I've been worried about what I like to refer to as the aging problem and open source communities for quite a while now I'm let's face it. I'm getting pretty close to retirement and I look around within the communities I've been involved in and a lot of the leaders and contributors are people They're around my age and they're also Starting to think about retirement in not that many years, but succession planning is not just about age, right? People change jobs. They get burned out. They become ill or in the worst case, you know Somebody could die unexpectedly and it's human nature to Ignore or put off these really painful topics because we don't want to talk about them But if we haven't done a good job of succession planning while the project and the people are healthy Then we're going to be scrambling to pick up the pieces when something unexpected happens And with that I'll turn it back over to Georg Okay Awesome. Thank you very much for being on the panel today. I really appreciate you bringing your Experiences to the table and to the conversation we would like now to start the conversation and I invite everyone in the audience to please write us your questions and comments and To have that conversation with us as best as we can I see the first one coming in so this is great To start the conversation And diving into The things that are being done and what we can do We thought it would make sense to unpack what the problem is with the lack of succession Planning and what that can lead to and I know we have a little bit alluded to this already So the question that I would like to have on to the other panelist is what does it look like to have a lack of succession planning for the open source movement? So on one hand we can have succession planning in individual projects, but then also we have the open source movement So what does that look like? I Think the problem with succession planning is very similar to the problem Of lack of diversity in open source I think that if there is no data or strategy to address this missing participation We are at the risk of of project burnout founder burnout and Projects becoming stagnant as well and then I think one of the status I mean Other than the lack of participation one of the status consequences is that the the software that we're all building together Doesn't really reach its full potential Yeah, I'd like to add something there to Maria's really great points And you mentioned burnout can happen in a lot of areas right? I can we're all familiar with maintain or burnout either personally or first-hand or through other of our colleagues, but Often I think funders and other people who are supporting open source projects can also get burnt out and I think that's a really good point Maria In our world in the non-profit world We've done a lot of work with the organizations and governments that fund open source projects that are used by Either their own governments or by charities and we've seen them have a lot of concern about This kind of burnout or or projects this kind of fade away as the interest wanes and so, you know part of our work is really trying to amplify the Inclusivity amplify the participation in those projects to help avoid that because when a project You know kind of fades away or or the velocity slows down in our world I couldn't really lead to a risk to Individuals and like the beneficiaries of the programs and services that are out there in the developing world or in charitable Situations who are really relying on open source projects to get that work Delivered or get those services delivered to them. And so it's really important to have healthy communities and And having a kind of a line of succession Set up where a lot of different individuals can help contribute to leadership and a lot of different organizations can help There's a really good factor to Yeah, and you touched on in the question about The movement and the way I see I see the open source Movement as kind of a collection of projects So I think this is one of those things succession planning and mentoring and all the things that go along with it Are things you address at the project level which then sort of boils up to more at the the movement level Just to tie those pieces together Those are all great Points and how do we so we understand a little bit better what it looks like to not have a succession plan Is there a way to maybe have some metrics or some objective Measures that we can say hey look this project is lacking succession planning Have you seen something in the wild that could help us? To make an objective case. Hey, this is something that is not happening. We should do it Yeah, one of the things that I look at from You know, so I've been looking a lot at our VMware originated open source projects and doing metrics around those and one of the things that I look at is How many people are regularly making contributions to a particular repository to a particular project? And so sometimes referred to as the bus factor I think in another presentation this week. I saw it referred to as the truck factor It's also called the pony factor, but it's basically do you have enough? Core contributors that the project could survive if something happened to a single person or a small number of people And I think it's important for us to look at that and I think it's important for us to to measure What the what the contributor risk looks like so how many people do you have? Contributing on a regular basis to a project and is it is it enough that the project would be okay if something happened to one of them? And I also see this as an opportunity So so one of the things you can look at these numbers and you can see this as an opportunity to mentor other people So maybe two people are doing most of the contributions And then there's a sort of tale of other people who are making a few contributions And if you only have one or two people that are making most of the contributions This really is an opportunity to mentor these other people who are just making a few contributions and bring them Into the core of the project and have them contribute more and move into leadership positions Which is really what you need to do for succession planning Yeah, I agree that We've done in that it it's very important to to build metrics and to build metric collection processes that allow us to listen to learn and understand what the situation is and Going back to Who are the voices that are missing today? from open source One initiative that addresses this at Google is the next billion user and Initiative they they actually they focus on Understanding how people are coming online and what their usage of technology is and and developing different tools to help everybody build better tech for everybody so that Everybody can access it for whatever needs they have So I think having these kinds of insight is it is really important to be able to make technology accessible to everyone Yeah, I would just add the yeah, the the work that Google has done here with the Digital confidence toolkit and the other the other things that they're looking at in terms of getting people connected and getting them access to tech Is really something of high value for us in our world in our nonprofit world In international development especially And it's funny because often you'll hear things like nonprofits kind of are trailing behind technology and things But and it's true when it comes to the kind of open source analytics and community health analytics But the good news is that they've long been comfortable in the nonprofit space of measuring impact of programs and so what we've been able to do is kind of leverage that type of language and that type of thinking to Say okay now open source as part of your supply chain You're using that as part of the the tools that you're using to get services delivered to people And so we need to understand the risks that are kind of deep there in your supply chain And so we've been able to start to have that conversation with the important people To make sure that they invest the time and energy to to do those metrics and do those analytics on community health And the good news is there's lots of good projects out there like like chaos that I care works on And others that can kind of give us guidance on how to do that so we don't have to reinvent the wheel But ultimately for us, it's about you know identifying high potential projects that maybe they just need a little bit of an extra push To become more inclusive and then become more stable and to have a good, you know long-term future ahead of them with lots of leaders and coming from diverse backgrounds and For us, it's all about kind of reducing that risk of failure again Excellent. Thank you. It's really not really good to know what it is that we need to look towards to understand what projects are Are possibly missing this succession planning now I want to take some questions from the audience Yeah, it looks like your audio is cutting out again. My audio is okay Now you're back. Let's try it again. If not, I'll ask the question. Thank you the So I want to now go towards asking about how does this actually look doing succession planning and aerial asked a question That is very practice practical of whether a fear of change is Exist by those leaders that are trans Okay, game work is breaking up again So is there a fear of change by the existing transitioning out leaders when planning for succession? I would say I've got some firsthand experience here and I would say often And it's kind of it's going to vary depending on the culture From what I've seen but in many cases when you have kind of a single founder style open-source project Where it was either one person or just a small number of people you get this You know what management people call the founders dilemma often that play there where they're kind of really nervous or reluctant to kind of give up Control and kind of let go and put things in the hands of others as they grow And so part of that can can come into play when you start having those conversations initially And so I think fear fear of changes is a valid reaction for folks to have And in some cases that I've seen People have kind of written suggestion plans where you have kind of a phase out or a mentorship role Or the person that's coming in to take over has a chance to build a relationship of their predecessor And kind of get that relationship and that trust built up and for the the person who came before before to kind of Transfer some of the knowledge and practices that they have and hopefully that What we've seen it tends to kind of ease the fear of that transition happening But again, you have to plan for it and you have to realize that takes some time Yeah, one of the things we talk about a lot in the kubernetes community is how we can make it Seem like a good idea for maintainers to step down and bring someone new in their place when they just don't have time Because it's really hard to get people to let go and one of the things we've done a little bit within kubernetes is we You know, we started to put emeritus fields and in some of the leadership spots. So they're not They're not completely going away. They're sort of there as an advisor if somebody has questions, but they're no longer responsible For things on a day-to-day basis, but they still keep a little bit of that status, which is really hard to give up in open source communities Yeah I I I definitely see that Because I think it's hard to break in sometimes in some open source projects and and build techno social capital as it is called sometimes within a project and being being built With reputation as well, but I definitely I mean from my experience working With the wikipedia I definitely thought that there was fear of change and I just wanted to say that in a way it's understandable because of what Don was pointing out about losing all of these Experience that I was able to Uh, that anyone was able to to build for themselves in a project and reputation I think the other factor to understand that fear is that sometimes certain models work really well and changing can Can alter that so um There's a saying in the wikipedia movement that wikipedia is Not supposed to is works in theory, but not in practice And it actually works in practice And I I so I guess what I'm saying is I understand where the fear is coming from but I think that Making space for mentoring and making space for Older contributors to to mentor and teach others how to become good contributors is really important in this sense So thank you. Thank you. I hope my audio is back to normal Um Don you touched on kubernetes. Uh, josh berkus was asking also about kubernetes and whether In uh in this huge distributed project With many specialized areas Um specialized knowledge required there Um, do you have any advice on detecting and ameliorating these tiny areas of concentration? Yeah, that really is super hard because in a lot of cases, um The metrics aren't going to be that granular because it might be just like a little tiny area of the code base That only one person knows really really well and it's it's really hard to get metrics that That help you understand uh contribution at that level. I think it's I think it's possible So I think you can do some of this with metrics, but I think you also need to apply some Some kind of human filter on that right you need to talk talk to people and understand The work that they're doing which is really hard in a large project like kubernetes But I think it really I do think it really boils down to encouraging people especially people with this niche specialized knowledge to To mentor people and and bring them up so that more people more people have this knowledge And that's incredibly hard because mentoring takes like loads of time And it can be really hard for people who are very busy And I think the community the kubernetes community does a pretty good job of having mentoring programs So that's certainly a start, but you know as josh mentioned, this is a this is a hard problem to solve for sure I just want to give space to see if michael or maria want to Add anything I can't I can't speak for kubernetes specifically But I would just build on what don said that You really want to try to get to a point where you have Normalized the culture of mentorship whether it's through, you know more formal programs like google summer of code or outreachy Or just through kind of the way you work on on activities, you know pairing with people You know finding people to co-lead projects with you Having kind of an apprentice model set up Anything you can do like that in your community to set that up where you don't have that single point of failure Is a good thing even even just documenting as you go making sure that you're doing kind of what I call open source hygiene You know making sure your conversations are documented if you have a phone call or a voice conversation So people can at least refer back to the the paper trail of how things got done That's better than nothing. It's it's certainly Got room for expansion, you know in terms of bringing people along and building that culture of leadership but Yeah, changing the culture is really a good a good first step I loved to quote something deb Nicholson used to say and talks a few years ago about handing out titles like they were candy to people In other words be very liberal with Signing lots of interesting leadership roles and making kind of making up new roles for people as you come along because Ultimately, there's room for everyone to to take on something in an open source project Yeah, and I think there should be mechanisms and I think someone actually Is asking something similar to this novek is asking about formal governor Do you think that formal governance structures would help succession planning? And if new SS projects should start with a formal governance framework as a foundation I mean, I I I think every open source project needs needs to start with A solid governance model. The question is How can you build in this leadership role? into that governance To recognize the people who are contributing in this capacity because what I've witnessed in different open source projects Uh Is that the edits or the contributions that count are for example, wikipedia are the edits to the content or adding content on the wiki projects on other projects are these are contributions A That are measured in pull requests and and issues and contributing code mostly we have very solid software to Count how many lines of code we people are contributing But we don't have the same The same solutions for counting when people Take time to meet with somebody to to explain how they can join a working group or or a special interest group So how can we build? I think it's actually a really interesting proposal. How can we build this in the governance model of a of an open source project in order to recognize this effort as well The other thing I would just think that you can oh go ahead michael No after you please Um, the other thing that I think can help with with governance One of the things that you can build into governance models is something like again What we've done in and kubernetes as some of the groups have what they call formal shadows And that's it's not I mean it's kind of built into the governance and that we have we have special teams So like the release team does a really good job of this the contributor Summit planning team also does a really good job of this but having having an assigned Shadow or more than one assigned shadow for every single role Gives you an opportunity to mentor people and those people then become release leads in the next You know the next one or leads for particular areas for the contributor summit And that's a really great way to build in this this kind of concept Yeah, I would totally agree with that And and just as important as kind of the formal governance role structure and and named responsibilities are I think maria highlighted something that's important for us to remember is that we don't always have good ways of acknowledging those efforts Because you know, we're we're running on on you know platforms like it lab that just count commits and lines of code and things And and as a result sometimes It can do us well to kind of hack together some solutions Uh, for example, I've seen people use tools like discourse and the badging system that it has to kind of honor kind of varying degrees of contributions for documentation or community outreach types of activities and you know, no matter what tools you're using Find a way to to acknowledge those contributions in some formalized way and make that kind of a practice in your community Is a huge a huge benefit to people and when people come in new they see that there's a route for them If they're not coders there's a route for them to stay involved and to help move the project forward So in summarizing what i'm hearing and to answer the question It the formal governance structure does help with succession planning and having it purposely built into how we operate the community Now here's a related question from ray pake asking Do we have any examples of open source communities with good succession planning? That is well documented. We have already touched on a few and I want to add one more question to this Is is there any examples from small projects or is this only something that big projects do? I don't have a good answer for this But I think it's actually probably more important for smaller projects To do this because they tend to have fewer contributors So something like a kubernetes Somebody could probably pick something up if something happened to somebody but if you've got Yeah, you look at open ssl a few years ago when when we had I'm drawing blank. I was called now heart bleed. I guess and If something had happened to one of those two people who was working on it Um, that would have been a huge problem. So I think succession planning is actually more important for smaller projects It's harder but more important um I don't I can't think of a small project or big project That has already a good succession planning Strategy it doesn't come to mind right now. It doesn't mean it doesn't exist um but I I the the one thing that comes to mind are initiatives to To Create the leaders that we want to see in in open source and one of the the initiatives that I've seen Is very solid is mozilla foundations. Uh open leaders program They Let me check my notes. Yeah in 2016 they started Uh training the different cohorts of people on what it means to to work in the open How to do project planning? There's like Guidance even on how to write a readme file for github Uh, and a lot of different tips on Uh, how to manage events how to have an event strategy, etc and This program I I was able to take this program as a mentee in 2017 and then I was a mentor in 2018 and I I think it's a very solid program to To just give the basics of open source and help people understand What does it mean to become a leader and how can you open source your project? Whatever your area of expertise is if it's open hardware open science Is civic tech, etc What how should you do it and why should you do it? But then this is uh, yeah, it's a program Hosted by an organization that is very It's advocated to open source It's not something that is owned by any one project in particular so one of the So good michael now just quickly to add I think um You need both this this base of leadership skills and I think you need Really to look at it on a case by case basis for projects from what I've seen It's because it has to fit into the culture that you have And you have to work with the people that you have even if you don't have the the ideal lineup of A wonderfully diverse set of skills and backgrounds You've got to start where you are and so you need to start really by taking those leadership skills understanding Really do kind of a gap analysis. What you know, what do you not have in the community that you need? And what do you have that people are interested in and building up for themselves and really um in the open amorous Experience that I had it was about having individual one-on-one conversations seeing what people wanted to take on What they were passionate about but maybe didn't have those right skills yet and then Really developing a plan for each of those people to move into those roles of leadership So yes, it's uh, it's a very artistic and less of a scientific approach from what I've seen so one of the things that comes to mind when I think about small projects in succession planning is um, and this comes from a conversation with a maintainer who has uh A project that he's basically the only one maintaining it, but it's used by almost every linux machine out there and He said he's not worried about the succession planning if something happens to him because the project is part of In this case. It was the GNU project There are others in the ecosystem that are doing related things and if you were to go away someone else Can step up and take it over so even if you're looking at numbers and metrics like Bus factor it might be one But if you consider the ecosystem that the project exists in it might actually much better um And especially in these small projects that have a very specific purpose and they do it really well because they've been around for 20 years um That's just something I wanted to bring into the conversation as well that those projects do exist And succession planning is taken care of by the foundation or by the group of projects that they're part of Yeah, gary. That's a really good point. It's um something that we've found in our studies is that Not every project needs to grow right sometimes one, you know One maintainer is is just fine as long as you have a plan for kind of what happens when they go away because You can get some major disruption or you look at open SSL for example And understanding like okay, what's the risk what it will look like to transition this off to another another individual at some point You don't necessarily have to have a team working on everything um, but you do need to at least Have hopefully given a little bit of thought of what happens if you do get some disruption Because at the end of the day if you are big enough where you have an ecosystem around you That means people are depending on what you're creating and what you're maintaining. So, um, you know, they They owe it to themselves ultimately to make sure that there is some plan in their mind for what happens if there is Some disruption and maintenance Yeah, and this is another case for making sure that all of the work done in the open source projects is really done in the open So that people can go back and figure out What decisions were made why that particular architectural choice was was taken And and be able to reconstruct some of that history if we had to So one of the things that comes to mind also with succession planning is what Heather was talking about yesterday during her opening keynote That we need to account for all of the people coming into open source and create healthy communities that are welcoming to onboard them Tools that I've seen communities use are Making sure they have a code of conduct where people who come to the project actually Know how to what is expected behavior and that it's a safe environment and making sure that we have The mentorship in place people have already talked about that What are some of the of the other things that you have witnessed that really helps? Bring in all of those new people coming into open source and helping them Step up in the future so that we don't have a succession problem I hate to keep bringing up kubernetes Which just happens to be the most recent project that I spent a lot of time on but I do think having a really clearly documented contributor ladder that helps people understand how you move up and has Small incremental steps on the way to do that can really help You know if you look at kubernetes like the first bar is to become an org member And that's that's really low. You just have to do a couple of things and get a couple of people to vouch for you And that's relatively easy and then as you do more and more things you can end up being a reviewer and eventually an approver and there's a You know a really clear Documented way of doing that along with a lot of resources and documentation for contributors That really helps and I think having that kind of step by step process for people can help a lot To bring people into the community Yeah, big big plus one on that. I know a lot of the projects that we work with um Well, the first thing we do is we call it a kind of a risk coin one side of the coin Is about kind of the engineering work and the software itself But the other side of the coin just as important Is to understand do you have a healthy collaborative community and and like don said having formalized? Kind of a progression ladder any type of formalized community norms things for help to help people get oriented quickly and successfully Is really kind of a prerequisite to have? A healthy growing happy community and if if we find projects that don't have that We help figure out help them figure out what that looks like for them and get that created and get that well communicated as people come at new It's just it's too important to the success of a long term, uh, you know thriving open source project Um Because we really want to tell the whole story you might have really awesome code But if you have kind of a toxic community, um, that's kind of You know buckling at the seams People might not catch on to that right away and they may have some make some pretty important decisions about Starting to use, uh, you know, whatever it is that you're building without understanding that risk And so we want to make sure that, um, the the good code is backed up with a good healthy thriving community to Yeah, I I think to add to to what uh, don and michael have said already. Um I think it's very important to To commit as a project to commit to the code of conduct In a way it's like saying, um you uh You're putting efforts into seeing the kind of behavior that you want to see online and and there are many different ways in which you can Enforce this but I think it's important not only to have it but also to to enforce it and make sure that people understand This is how we talk to each other here This is how, uh, we treat each other and this is not this other kind of behavior is not going to be tolerated Uh, I think having a commitment like that communicates to anybody who is a newcomer This is a safe space and we want you to be here. We we want your contributions um Otherwise, I yeah, it's it's going to be really hard to to have people that want to join to contribute If they don't think that they are treated well Yeah, thank you so So then I've posted an interesting question asking when you look at today's open source community. Do you see yourself? Do you see your earlier self and the newly minted open source contributors? and If I can add on to that, this is a yes. No question. Do you see yourself? But if you look back to how you got started in open source and I'm going to say all of us have Had a progression throughout open source Maybe you can share some of the steps that we have gone through and what has helped us Step up and get to the point that we are today Yeah, so so I'll start um gay arc and uh, like you, uh, I started waiting into the open source world about 15 years Or goes ago or so And we weren't nearly as sophisticated back then in many regards in terms of how well we interacted with other humans and I was coming not from a software engineering background I was studying electrical engineering actually at the time But so I was perfectly comfortable tinkering But not enough where I knew that I could kind of get in and get my hands dirty with the code And so for me reading the materials the documentation that was out there Going back in mailing list archives We're kind of the the common ways of of trying to wade through and find my way in the project to begin with Eventually we'd end up on things like IRC chat and try to troubleshoot questions or figure out how I could participate in some way Um, so I think making sure you have good resources for newcomers It remains a critically important thing To build up a you know a long term I hate using the word pipeline, but a long term Line of people who are going to be advocates and participants and leaders in your project Because there those are the people the people who are coming to your project new today are the people who very Very well, maybe leaders in five or ten years down the road. So treat them well. Do your best to help them You know more swim their way through the materials that you have out there Yeah, I think one of the things that really helped me like I'd I'd been involved in open source Especially on the community side for for quite a while But then um, I I started working with uh, Denise Cooper at intel and she started sort of bringing me along to conferences And doing you know on panels and and actually speaking at conferences And that was really sort of when my when my career turned from You know just being some random program manager or you know, I don't know Whatever I was doing sysadman various various jobs To having a lot more visibility and it was able I was able to shift my career into You know doing the open source community thing kind of full-time in a much more senior way And that I think was was really important And so that's something that I've also tried to do with people is You know bring newer newer contributors into into joint talks or you know Help help people along in any way that I can and make recommendations and try to try to bring people up with me Because I think that's really important um I I really like the question I was thinking back to the first time that I contributed something and I do see myself in in new contributors, uh, and if I have to think back uh I think the one thing that really helped me a lot was having a mentor at the time It was my boss uh at wikimedia argentina who who taught me a bunch of things about editing wikipedia and uh And then later on it was other people Sorry, uh later on it was other people that showed me the way and I I recently was able to find in the k-native community There is a contributor who's super excited about um the community aspect of open source and uh, he Raised his hand in a in a number of times and I could see oh he he wants to contribute in this in this Area and so I looked him in and I said, can you can you be a community manager for For the blog of k-native. I'm trying to put together an editorial team for for The k-native project blog and and so just being willing to to open Uh Your work to others and and partnering with them and seeing would it be comfortable with this and and if they are excited then this is the way and uh, I think Yeah, it's important to To be humble in in acknowledging the things that one doesn't know and then To also be generous and and try to bring other people on board as well So we are getting close to the end of the session and everyone sorry if we didn't get to your questions Please head over to slack. We are going to be in number two community leadership Ospo to do after this session to answer any additional questions and to just hang out there Um, just a few closing closing thoughts also Um, do you have any suggestions next steps or advice to give? As a closing thought here, and I'm just gonna ask don do you want to kick us off? Yeah, sure I think I think it's important that we need to have these succession planning conversations now before it's too late Um, in addition to the aging problem that we talked about where I mean The space that we are in the middle of a global pandemic, right? That could impact any of us and as much as none of us want to think about that I think it's important that we start doing things in our own projects and mentor the next wave of people who can take over Our responsibilities over time Thank you Don Michael Yeah, so so in the nonprofit space we often struggle and try really hard to get people to move from motivation into action So I think hopefully we've planted some ideas for all of you here listening about how to Raise the importance of succession planning But I really want to challenge all of you to start thinking about specific steps that you can take So what are the bottlenecks in your community? So what are the risks? What's the long-term vision for your project? Because dealing with the issue of succession planning can be a good way to kind of Wait into other difficult conversations that your community may be have have put off for a while such as diversity inclusion Or personality clashes or other painful issues. It might be lingering So please take this as a as a call to action and figuring out what your uh, your community's next steps can be Thank you Michael Maria um, I think If I can give one piece of advice When thinking about succession planning, I would encourage everybody to stop looking at the years ahead And look around you right now at the present moment and ask yourself the question whose voices are missing right now um, because engaging those communities that are not yet part of open source Uh could really bring a lot of new voices and perspectives to open source projects that are much needed Thank you, Maria. I All of your advice is super applicable And I know in my own community in the chaos project I the way that I started The succession planning is to just document all the things that I'm doing And to start a conversation. Hey, if someone were to have to step up What is there that? They they would have to do so just documenting that having that conversation And uh, yeah, that's that's how I personally started this now Thank you everyone for participating today. Thank you for our amazing panelists for joining us today I really appreciate all of your comments and questions in the q&a Please continue this over in the slack channel. This is again number two the community slack channel and Yeah, I hope you've learned something taking something away from this and I hope to see you around in other places So thank you very much Thanks everyone. Thanks everybody Thank you everyone