 Hello everyone. Thanks for coming to my talk. I appreciate it. It's virtual, so it's a little bit different this time. I'm sorry. I can't see all of you. And by the least you can see me and see my slides. So let's get to it. My talk today is community transformation, enables skill-long-working through data-driven initiatives. And it is a work in progress. We've not finished this initiative. It's a very complex initiative. And so I'm going to give you an update on where we are, where we want to go, and how things are going so far. So let me just start with who am I? My name is Sri Ram Ramakrishna. My friends call me Sri. And I work for a company called IT Renew. We do, it's called Circular Data Center. And so my job is a Principal Ecosystems Engineer. And although this talk is about community, so I've spent most of my open source or free software experience working in community and especially with the Canom project. If you're not familiar with the Canom project, it is a human interface to your hardware. So it's a desktop. And so I've spent over 20 years in this project. And so it's one of my pleasures, filthy pleasures being able to do this. But I'm thrilled to be able to work in open source and free software and also be able to do this. So big thanks to my employer who lets me spend time on this. So anyway, moving on. Again, 25 years experience. So when I came up with this initiative, you know, a lot of it's probably no surprise to most community projects or even corporate projects that projects want to grow. And a lot of times projects usually have a drumbeat. A lot of times they want resources, they want maybe IT resources, maybe they want developers and so forth. But a lot of times I've noticed while spending my years in the Canom project, which is a fairly complex project, that what people want or complain about is not always the truth, right? So when people say they want developers, do they really want developers? Is that really what they want? Because adding developers means a whole kind of chain reaction of things because you have to onboard them. You've got to train them. You've got to integrate them into the project. And so a lot of those things come into play and now you're dealing with an incredible amount of complex overhead. And a lot of times when people say they want these things, it's in addition to many other things they may want. So, and if you onboard just that or just maybe the wrong skill sets, you're going to start seeing the agenda board where you're getting stresses somewhere else, right? And it's really an interesting observation going through the years of watching people do this. And we know this a lot. I mean, like if any of you listened or read Mythical Man month, you know that adding more developers to a project does not make the project go faster or runs more and more efficiently, right? It's simply a, it just adds complexity because there's so much more overhead that's generated. So this initiative is really about how do we build teams correctly using data to drive that, right? So in the, for the GNOME project, this is a great example of trying to be able to see if we can do something with an initiative like this and see if it works or see if it does what we intend to, right? GNOME is a great test project because it has, it is a very large project. It started in 1998. It has gone through many series of changes and being it's involved over time. We started with rudimentary tools and then as the project growth, it grew into multiple teams where before you had just this one mass of developers and that's it. Now as we go forward, they're split into many different kinds of teams. So you have teams that are doing engineering. They have teams that doing marketing and engagement, people who do translation. There are people who do documentation. There's a release team. There's an IT team. And if you start looking at it, it starts looking like a product team. And with so many different moving parts and a wide set of skills across the board, it is the perfect initiative to see how can we scale a project. And so this, this is, this is where this scalable onboarding comes in. And please don't look at that misspelling on scalable. So then I, I've given all those things. And then the question is, is what then is. And you can't really answer this question with that data, right. And as I probably before, wrote does not mean adding developers to a project. And so you need to be strategic. And where that is depends on what each team is and each team is different in the way they go about doing development. Some people are doing development, some people are doing non-programming skillsets. Each of them have a particular way of doing things. And so how do you get that data? And, and you start with what resources you have right now. Think about that for a moment. You have a large team. How do you get information? Where is the beginning part of researching how you grow a team? And then I had, so when I started this, it's sort of like, okay, where is, where do I start with this? Where, where is it? And then it occurred to me that I don't really understand from a high level how GNOME works, like at a 1000 foot level, how does GNOME operate? And what, what are the roles? What are the, what are the descriptions of those roles? What, how do people interact? And with that really understanding your project and how it manages its resources, it's really hard to set a level playing field on how this works. So let's see. So what should we do? And so let's start with roles and just, and description. So GNOME is a full stack for open source projects. And one of the things we did was break down all of the volunteers and what they do. And that happens in many different ways, right? So I already told you we had engineering teams, we had documentation team and things like that. And from a high level, we're, we're breaking it down at, I don't know, the complexity of those teams are very interesting, especially at the engineering level. So, but somewhat repetitive. If you look at the engineering teams, you have a set of core, core engineering things, right? So there's a stack. And so each stack has a maintainer and a set of contributors. So you have those and each of those maintainers have their own set of ways they're doing things. Then if you, that's, that's then, then there's the release team. And, and then the release team has their own set of things that they get from, you can basically decide what is GNOME? What is the product? What do you release? Then you have the marketing team and they're subdivided into many different kinds of roles. And since that's kind of where I come from, you can imagine that a marketing team has people who know how to do storytelling, people who understand social media, people who understand onboarding, right? Or socializing or all these things. There's even a code of conduct. That's part of, part of that. And so there's all these various teams and their roles that you have to document. And once you have them documented, you start thinking about what they do, right? So in this case, I'm going through these slides. We have beliefs engineering and all these versus basically all I talked about before. So that's, that's, that's a set of things that's we put together. So the next, the next step is the, you know, how do we as a team interact as a project, right? So in this case, we, we decide to build an interaction map. And so we look at how these teams, this is a very simplified version of what we put together because the real version is, is, it's got arrows flying all over the place. It's, it's literally chaos because there's some of that is how to operate today. And I think at some point I wanted to take what was operating today and think what should operate like in the future. Right. That was sort of a, a, a want or a need that I wanted to do is how, how can I make this a future thing. So, but one of the interesting things if you look here is you have these arrows pointing where and you can kind of see some weaknesses, right? And you see the, let's take a look at the engagement team and engineering team. And you see that the, the engagement team is only one directional arrow, right? Yeah, in a, a, a, I think a well balanced project that should be bi-directional. And so while we're going through this, this is the kind of things that you, you look through them is like, oh, I see a weakness here. This is, this is not how things should be. We should think about how those things work. And, and you can also see like the documentation. The documentation team actually is sort of an interesting team here because the documentation team is really only fixed on, not on the, this, like the, the stack, right? It's actually like the help guy. So if you type in F1 on an app, it tells you how to use it, that kind of thing. The engineering team actually takes care of the documentation for the APIs and so forth. But they do rely on the engineering team to tell us, hey, what is the new features that is happening in this product so that we can update the documentation and so forth. But it's still a one directional arrow that, that was surprising, right? Again, this is how this thing is working. And you can see that, that there's a lot of time wasted just doing one directional communication, which can, can do that. So when you're thinking about scalable, what, what do I need to make these arrows bi-directional versus one directional, right? What kind of skill sets is required and kind of thing. And so, so this, this actually, when we did it, it kind of surprised us in some ways on, wow, there's some problems here, right? So that, that was something I, I thought was quite interesting. And, okay, so the other part we wanted to do was personas. Personas is generally been used in marketing or product development or various other things like who's going to use this project product. And in this case, we're using personas in who do I think our volunteers are? And, and what will they be doing? What are their backgrounds? What, all of those kinds of things. And, and the reason we put that together is because personas is something that lets us get us into the minds of who is coming in to volunteer, because part of onboarding is, is the strategic part of onboarding is who do we want. And so when we're trying to articulate a message, and you want to attract certain kinds of skill sets, we, we have a sort of an idea like what would resonate, what kind of people are out there. And a lot of that is a reflection of the volunteers we have working today, the volunteers we might meet at conferences, or various other kinds of things. So it's, it's really quite, what should I say, interesting to see what, who was out there and what their background was. Some we made up just because it's, it's like, well, how would we talk to somebody who is a 50 year old systems administrator, but wants to get wants to go into marketing, right, you know, and that way you kind of say, oh, yeah, okay, if you're old systems administrator, which actually is me, and is, is interested in marketing is what would, what would that skill set have all kinds of skill set what they have. What kind of things would they be using or what is their experience level, that kind of thing so these personas really help us that decide where would they, where would they be where are they located so that. So, we found the idea of doing personas for for those to be quite valuable. And here's an example of the, the kind of volunteers we tried it right so you see. We have a new, someone who's a new contributor. Jane here is a university student skilled with Python is looking for an open source project to start making competitions to she's 20 years old she's from Nigeria. And, and, and one thing we went afterwards was to say, what problems did you have trying to get into open source or what, or even to the kind of project. And so the. Yeah, you know, like documentation did some of the documentation is not work. And so these are ways to treat you think like, okay, you know, they may be problems. Same thing goals, but they want to be, they want to join the minimum project. They want to be part of the community. So we have Ruth, who is a graduate microbiologist now, not your typical maybe of the source developer, but, you know, she, but she's trying to change from being a microbiologist to a self learning to a developer. So actually, Ruth, it could go is actually a real, a real, a real person and a real volunteer who helps us is actually on our team mission team. She's actually been, have been accepted in a number of talks, and so forth. So her path is, it's been quite fascinating to watch as she also gets into the open source world. And so she makes a really good persona of what is what would be a typical kind of volunteer will be their background. So, so we have let's stop for a moment. And let's think about where we are right now. So we've gone through about 10 slides about what what is a what is the working idea of your role of your organization. So you have a working idea of how this project works, you know, working idea how it interacts with others. In fact, there is an opportunity here to think, how do they interact with other products, right, so nothing says that you don't, you can't look at it from that perspective, that you can't not look at it from, from that right. In fact, there's another initiative, talking about an app ecosystem, where we are doing a matter project where we are looking at how we interact with each other as a overall ecosystem of various degrees. And, and then we looked at what kind of projects are volunteers and your background. So, these are all pieces that information that we can put down and, and, and refer to as building blocks. When we go through the rest of the initiative, right, because sometimes they're, they're maps, they're maps of information to, to refer to to see where, where are things going on and where are the stress points, where are the various lists. But that's not, that's not all we're doing right now. Now, if you remember way back at the beginning of this talk, I talked about how the project is a complex project with lots of different teams, and every maintainer has their own idea of doing this. Now, from a social engineering point of view, how, you know, how does, how do you convince a team to do that because if you're going to take on and grow a team. A lot of times that might mean adding people, it might mean doing documentation, it might mean changing how they manage your project. And, and so if you can't, my point here is you can't do a top down approach and say, This is the way we're going to do it. There's too, there's too many open source doesn't work that way or free software does not work that way. It requires the ability to convince someone that this is the way to do it. This is no different than how we do development. It's like receiving an MR and convincing somebody or MR or PR and saying, Well, you know, I want you to take, I want you to take this. Well, you're making this change. But you're, you, I mean, tell us how this will actually help us. And, and to do that is you have to find a team that will actually be willing to work with you, because they do want to grow their team, that they are in a position where they're exhausted, that they are to continue doing what they're doing, they need more people and they're suffering burnout or various other things. Those are a great team to work with. I mean, one, it doesn't actually have to be a team that is in dire straits but that's one example. Another one is an upcoming team that may be just starting out and wants to set the right foundation for growth. That's another kind of great team to work with. So, so that's, that's a thing. So start with one team, and then work them to be successful. And then you go and say, Hey, listen, we have the metrics, we have the ability to show that we grow this team to a point where we can. Now, they're working great and they're set for the future, because we understand how this team grows. And we want to do that for your team. So this might seem familiar to a lot of you who are in the corporate world. We have to do kind of similar things. And a lot of times, if you're working with sister teams, we, a top down approach doesn't always work right so. So, my password. Okay. All right, so who was the team we work with. And in this team, this is actually a team, but it's actually a, the set of mentors. So the mentors team are the people who help with mentoring folks who are coming in. In GSOC, or outreach, or things like that. These are internships that come in. And we have to build, they come in and then we've got to have to do the onboarding with them. Now, unfortunately, it's been the same set of mentors that's been happening over and over and over again. Right. And so, now there's a sense of burnout because no new mentors are coming in to help expand in an equitable scenario. So the old mentees might come back to mentors. So, so the thing is, if that's the case, why it has, why have we not scaled mentors to the point that we can have more folks because a lot of these mentors are also maintainers of projects. And so the combination of mentoring, the combination of maintaining a resource project, and then work and life, all of that ends up becoming quite a bit of problems. So, so this, this is, this is what they came to us with and say, help us figure this out. And figure out how we can grow our mentors because we're feeling beat up every year. And each year it's getting harder and harder to do the mentoring. So, with that in mind, the idea would be to do a problem statement. And the problem statement is works like this. And we define that mentors are exhausted and burnt out. That's a problem statement. And they are dealing with problems where they're essentially repeating the same onboarding process over and over again. And this is sort of part of where we gather the data right so we look at what all is happening in the time that they're going through this. And so we started by interviewing mentors and mentees. And, and for each of them, we built a, a problem right so we start off with the mentors. And so they source it for those who are curious of what are some of those problems and maybe some of you who are mentors at Opus on open source and Richard you saw, you, you might have seen some of this. They've had problems with language problems with misunderstanding things. There are problems with cultural backgrounds. What it may constitute a joke may not be a joke. And so there's all these things and that's just the cultural human interaction issues that actually happens regularly with just many types of people, but also avoiding them into the project so a lot of them are the same set of questions there that are being asked on a by angle basis right. Why does this happen, why does this happen, why do we do this and then so you end up having to go through these cycles and over and over again and people get tired of answering the same questions over and over and over again. So it gets a little bit taxing when you're doing all those. So, then we went with the mentees and and so that's a different set of issues. A lot of them comes a lot of that, like, they never feel like they're part of the project because they do not. There's no socializing so like mentees are working in a vacuum they have they have almost a father war right so you have a group of an intern working on a project and then they are they have their set of their mentors and then a channel where they hang out in and and then that's it though but they're not they don't see the other mentees, they don't see the other people working on this so they never get into a area where there's there's camaraderie or any kind of things so they don't actually feel part of the project, right. So, in fact, the only time they feel that way is actually when they come to the in person conferences and actually meet the other other interns so so so so so that's that's a interesting thing is that is that's the only time and then they kind of did it all comes together now with these coven times and then the virtual that's much harder now so how do you build build a rapport and so these are the kind of problem statements that going through that we record one after another and and call it all new responses. So, once you have that, and this is, this is sort of where we're still at that previous stage or again all this time. Unfortunately, when when you're dealing with a group of people who are already resource. They're limited. They also don't have as much time to talk to you either. Right. So, so the process can scale a little slowly, because we have to, we have to go at the speed that they can handle to do it so. From here. It's a it's more of a projection of what should happen. And so I'm heading in that direction so at this point we build a project plan and and I take a lot of how we did this from the chaos project. So we, I'm involved in a chaos project working group and actually, Georg link, who I work with is giving a talk at the same same time slot so if you've seen mine and you should definitely go and see this talk. And anyway, as an aside, the project plan so how do we how do we build that so once you have the pain points or the thing you have to start working on. What is the, how do we address each issue. What is required and a lot and a lot of times, it's not usually again, adding more developers. And one of the interesting things that I have noticed that my open source projects. They say we need developers but they never say we need more project planners, or we need people who know how to triage or we need, you know, so a lot of time order is what we need more than anything else. And as we went through this, I actually, when we went back on interaction map or roles, I put, I put project managers or something is like, probably needed, because they, they understand how to look at how something is happening and correct, correct things. You know, they can understand what skill sets are needed. What we're all those things as a project manager myself for time. This is sort of this is an evidence of that mentality. And so if you're. Going back to the document, you're, you're, you're saying, okay, to do this, we're going to have the right you start up with what are the tasks to so it going back to the mentors, if you say, we are repeating the same thing over and over again, you're well, that means that we, we need to write documentation. So, once you have the documentation, then you go, well, I need to look that up. Now you've already went through the roles and descriptions. So you know, because all those things are laid out for you, you're not sitting and wondering, what do I need, because that's why you want to go in and document those roles, so that you can go back and say, yeah, I need this because documentation is not just documentation because there's many kinds of documentation. So if you're, if you're trying to document the project and what it does, then that's one of mine. It's not the same as a documentation team who's writing online help, or are the people in engineering who are writing APIs, right? This is cultural description of what we do, how does it happen. And or, or on the sense you go to the release team, say, well, those are the people we need to, to write this stuff. So, now you're able to get, because you did those roles, you can get much more detail over what is required to make, make that happen, right. And so that's, that's, that's the exciting part. And you don't, you don't, you're not thinking, you're not lost in how to do that because you have those things laid out for you. So, again, once you do this, you write that and then you, if you don't have a skills, then you're going to be mapped to the skill set. If you don't have a skill set for that, that means we need to recruit that skill set. And so now you know, as an organization, where to put time, effort, money, or any kind of thing, because you know, where at least to where it fits in in the overall scheme of things. And one thing I've got to understand about volunteering and recording is that you can always find somebody who would be interested to work on this project. I, there, I, in just this initiative alone, I started with one person, and I've got eight. I started another initiative. And I started with one and then became three and then became seven. So people are, and all of them have very different skill sets of whatever it is. Is this in the ask, but once you have the ask, you better know what the context is to get them in through the onboarding cycle, right. So that's something you have to think of. And the last part I didn't talk about is how do you measure? How do you measure success? So when you're going through it, you need to think of, what does success look like to me? And, and how do I record that? Because otherwise we'll never know that your team proved properly or maybe there's some wrong adjustments. So those are, those are things. But so once you have that plan in, in, in place, then you can, you've got your resources in play. You have, you put your issues in and get lab or get up or whatever it is. And you have some semblance of a plan. Now, I'm not guaranteeing that you're going to get there, because it's volunteer right. And that's one of the big things about community projects is volunteers is, is non fungible, right. It's, it's, they're there, maybe they're not there like this and you should be, we should be grateful for whatever work we can get at any time. I love the project, and they have a great experience and things like that. You know, going through this, I think really percolates interesting ideas. So one of the, one of the great things as an aside. We, we figured out was as part of mentors is we don't have a video that that doesn't is an onboarding video. And if you've ever, if some of you have, this is very US centric, and I know this is a conference, but every urban to summer camp, and you go there and the camp counselors, they go through this whole thing, this is camp. Clackety clack or something. And they go through this whole spiel about whether this so that you feel like you're part of the, the, the camp right in some ways. And I realized that we don't have anything like that. And, and so once we put that in there, like, Oh, well, if you map that back, I need, and I go look for the roles and I need a video guy. There it is. There's the video guy. So, and then you look at the person and well, where would I go and so, so you see how those things all map out Once you have measured and you've got a roadmap of success, you're going to be like, Okay, we got something right. And this is where the social engineering part comes in. Once you have a happy say the mentor, they're going to be like, Wow, this is a great and a great experience, you're feeling better. So you take that experience and you walk to the next group of people. You're the next team that might need help. And by that time, hopefully your team is diversified and, and, and you're not burned out going from our views because it does take a lot of effort to to plan all these things right so then you go on to the next team and then you decide okay Alright, now what, what do I do now, right. And so that and, and I show them, look, it works. You should do it too. Here it is. Now, each one of them are going to be different and how that plan gets executed because each of them does work differently. You know, working with mentors is going to be very different in working with the engagement marketing team, they're completely different sort of things. What they might feel burned out on could be all kinds of things can own as a project that is as close to human beings as a whole normal human beings not it tag or anything like that gets a large share of noise that could lead to burnout right so how does how do you deal with burnout when there are individuals or things out there that are constantly giving negative, negative vibes. So that's just an example of issues or if it's a release team, you know, they're constantly thinking about what is part of the project sometimes they're in sometimes around, what is this consistency and another challenges so like and each one of these have different stories that you have to address but that's one of the great things because no team is like. And so, when you start again, it's a completely you want to say slate queen and you start again. So, but so I gave a bunch of a size of experiences but a lot of things came to life for me, you know, and I do know this process is pretty slow. And, and it takes time. But if you have a good set of people, they can definitely help. And it feels great not giving this time I feel excited about doing this and you can see how I'm talking I'm animated right. The stuff is amazing I want to do this right. So, so this, this is something I care deeply about. As I do the initiatives that I've done is that putting something that scales and and use your good onboarding process is pretty, pretty cool. And along the way, we picked up other folks who we almost had. Sorry, for free freeze. But a lot of things like, I do a lot of things I did not know about, you know, before and I've been here 22 years. And this process was funny because I'll give you one amusing anecdote is, I don't think anybody in this project actually knows how I'm going to release habits. And so, so it is magic. And, but it's like, like something something something that suddenly it just sort of comes together. And I lose happens it's it's, it's quite thrilling. But again, there's a lot of things I did not know about. And when you ask around like, how does this happen. I don't know. I don't know. Again, it's. So, um, matter bits is, as I was saying previously, I modeled this around chaos project, which is an amazing project, we should be involved in it. It's awesome. It really, it really laid the foundation down to how to do this initiative. And there is a initiative before that I'm working on the call the app ecosystems where this is actually met up. So I'm doing with the project but that is the entire ecosystem of Katie genome and other other large community projects, and how do you be able to create a dashboard just it's the same kind of thing. The other parts was, I invited as part of research. I invited a lot of external red hat, and other places that was that was that not only we were able to talk about things like what was your onboarding process like we had a few folks from open stack and then we had some folks from red hat. We've talked to us about various other things. So, so just, just, just turn a little bit like a lecture series so it was, it was really, really quite great and of course the revelations we were can stay with mentors was fantastic. I was really excited about feedback and I'm like, how do we fix this, you know, this is great stuff. I'm, I'm really into key learnings and, and again, I love to repeat myself. So, if you do do this. Feel free to talk to me. It gives you, again, the, this process gives you a lot of insight. There's a lot of context about how do you understand and understand the issues and things like that, and each thing is different. So what works for us may not work for you. So, if you want to, if you want to come around with us, I'm happy to share the work we did with documentation, the overall project plan we did. We have recorded meetings, some of the meetings that we did with open stack and red hat are all, are all recorded. So if you want to see some of them to do that. And, yes, that's pretty much it. So that's the end of my talk. And I hope you enjoyed listening to me virtually. I certainly enjoyed talking to all of you about this. Again, I'm super, super excited about this thing. It's really awesome. And I hope to come back in about a year and give an update on how things worked out. And if it worked out the way I expected to, if it did not, you know, it'll be, it'll be, it'll be interesting. So, if you want to contact me, you can reach me at my email, I'm sure you can on that art, or my personal address for you. You can follow me on Twitter, although that's mostly politics. I don't know if you want that kind of thing, but feel free to follow me. I, I forgot to put in my debt to, but I do have a debt to where I do focus on technical topics. So anyway, I think I'd like to thank the Linux Foundation for being a part of this. And thanks again. I'll be staking staying. I'll be here online. So if this is a recorded talk, I'll be around to take questions. And be happy to answer anything you might have. I have a wide set of things I do. So, thanks again.