 Hello, everyone. This is the mentoring effectiveness of LFX mentoring programs. My name is Nate Waddington. I'm a developer advocate with the CNCF, and in that role, I do technical writing, as well as help run the mentorship programs across the CNCF. I'll let Diane introduce herself. All right, and I'm Diane Mueller, and I'm part of the mentoring working group under the CNCF, as well, the tech lead there. And I'm also the director of research and advisory services for a small analytics community company. Thank you. It's a jet lag day. So forgive me. At Betergia, and we have been working together on measuring and helping to manage the mentors and the mentees that are part of the CNCFs and the Linux Foundation's mentorship programs. And how to improve them. And how to improve them. That's the key. And to that point, so I'd like to explain just a little bit about the programs that we run. I've been a part of the CNCF for probably about three years now, but about probably a year and a half ago, maybe 18 months. I had started working with Ehor to transition. Ehor was running the mentorship programs prior to me. And unfortunately, he was living in Ukraine and had to step away to defend his country. So at that point, I had some very, very big shoes to fill because he had been running this whole program himself along with a ton of other things. And so one of the things that I was, again, I came in as a technical writer, so trying to figure out community management, which is a big, big part of open source generally, was something that was new to me. And so after speaking with some folks, we decided to create the mentorship working group under the CNCF's tag contributor strategy group. And the goal there was maybe a little bit about the tag contributor strategy is it's all about maintainers helping maintainers and having folks help each other to grow new contributors, which made for a good fit for the mentoring program. So its goal is to increase the number of maintainers, obviously, the number of contributors. We want, I mean, one of our big wins, and this is something we'll talk about a little bit later, if we can have a mentee become a contributor, a continuing contributor, become a maintainer, and then become a mentor again, completing the circle. That's top shelf goal there. So we want to increase the quality of mentorship of the CNCF. We want to increase the diversity of folks participating, both mentees and mentors. We want to increase the number of projects that participate, frankly. We have a lot of projects in the CNCF, and we'd like to see more of them contribute. We'd like to increase the number and type of work that's done. There's a lot of talk about code contributions, but there are non-code contributions. If you're a technical writer or a designer or even a project manager, we have got some work for you. So this is the type of thing that I'd like to increase the diversity of types of work. And so when we set up this working group, one of the things I was doing was having a monthly meeting, and I kept having these very rudimentary spreadsheets with numbers saying, oh, well, the last term we had, this many people come in, and this many mentors, and this many projects were. And then I don't know if you reach out to me or if. I think I saw one of your spreadsheets and, oh my god. Oh my gosh. That's not a way to track things. Yes, it's a start. I had an intuition on some of the numbers that we were getting, but when Diane saw the state of the effect of what we were doing, we started a collaboration where we really started to try and dig into the numbers because if we can't measure what we're doing and we make decisions, how do we know that the decisions that we made were successful? So I think at this point, probably I want to hand this back over to Diane to talk a little bit about how we move forward with the data. So if you go one more slide, and I'll talk a little bit about the research methodology that we've used. And I'll step back a little bit, too, and say, so for the past 10 years, I've managed a large ecosystem of participants in the OpenShift at Red Hat communities, which if you've been following the CNCF and Kubernetes, that was an exponential growth of the number of people participating in the community that I was asked to help manage and grow. And so when that happened, I stepped in and started using some tools from a company called Batyrgia that allowed me to manage and track the participation of developers, whether they're end user developers, code contribution developers, people logging an issue, all of that sort of stuff. And it was the secret sauce in my minor success in that world for a number of years. And then when I made an attempt at semi-retiring, I decided that I'd still contribute back to the CNCF and come play in the mentoring working group because mentoring is near and dear to my heart. And so what I tried to do for the mentoring working group as their tech lead is to apply those same tools and techniques that I use for growing an entire community to focus it down on the mentees and the mentors in the CNCFs, the cohorts for the different years. So the things that he had tied up and found up in spreadsheets. So many spreadsheets, too many spreadsheets. And we still have spreadsheets. We haven't gotten rid of all of them. But they have two main data sources. Besides GitHub, they have the Linux foundations, very nice, beautiful web portal for the mentees and mentors. And that has a back end to it that allows us to download the names of the participants and what cohort they're in. And my cohort, I mean, what period? Were they spring, fall, summer? And which year? And what term it was? And we have a whole thing. So we went and the Linux foundation, what he didn't mention, was there are a whole lot of other mentorship programs. So this little bit of research we're going to talk about today is just focusing on the CNCF one. So people who worked on CNCF mentorships. So we focused on that. There is the Google Summer of Code that the Linux foundation participates in, Outreachy, and every other Linux foundation that has a mentorship program. So the same techniques we're going to be applying. We'll talk a little bit about that to a few other things, like the Linux kernel. And so we'll talk a little bit about that. So what we tried to do was take the baseline data out of the Linux foundations back end from the mentorship and then use that to create, if you want to go one more, to create the subsets and the filtering for the different groupings, which allowed us to use all of those wonderful dashboards that we had. And we were being pretty particular about which ones we were doing. So it allows us to see people who are commenting issues, how they changed over time their affiliations with companies. So if they came in as a university student and then managed to get a job with a CNCF member organization or went off to another career in accounting because they didn't decided that maybe insurance adjusting was more fun, so you can go again. So that's kind of where we're doing that stuff. So give us another thing here. So I tried very hard to be very quantitative about it. So he's got all the qualitative stuff. The Linux foundation does a number of surveys every year asking people, how was it? Did you get what you needed out of it, those kinds of things. What I was trying to stick to would be very structured data collection, some of the things you can't really argue about, whether they made a commit or not, whether they logged an issue or not. And one of the keys to doing this is not just at the end of the term, but during the term, if someone hasn't yet made a merge or a commit and they're in a mentorship program, that's maybe a red flag for the admin of the mentorship program to go reach out to a mentor. And to that point, actually, it was interesting. One of the anecdotes I'd like to share here now is at one point, Diane was going through the data. And she said, Nate, there's something a little bit weird about this particular individual. Why this individual looks like they are this other individual. And I thought to myself, there is a very good reason for that, and that's because that person had changed their profile to apply again. So they said, you know what? For the LFX program, we're only allowing a person to participate once, but they wanted to participate a second time. And so they changed their data and made a look at it. And I only found out about that because somebody had opened a support ticket saying, hey, this person doesn't fit the category of being eligible to participate. Now, had I had that data set three weeks earlier, I could have solved some problems right off the bat. So these are the types of things, as an administrator, that I'm looking for in terms of these data sets. So the whole goal of this was to create repeatable, reusable dashboards for people like Nathan and other people in other mentorship programs to be able to flow through. And watch and monitor the programs as in real time. And then over time, to be able to see how this affected their careers, whether they went on to become mentors, whether they went on to become maintainers. So take a little bit. So this cohort dashboard is, you can see that's doing something here with a filter, which is the list of all the names of the people who participated. So Vitergia comes with a bunch of identity management tools. It's called Sorting Hat, if any of you are Harry Potter fans, which is kind of the whole gist behind Vitergia's naming conventions, I think, for their products. And then filtering it on for the last seven years. So then you can get all the stats that you would normally see for developer participation. But this time, it's filtered down just to that cohort. So those two things are really powerful when you can group people together and then look at them over time as they're evolving. So the other thing is we can see things like retention. So one of the key things that we're really looking for is if they stayed in their project, post their mentorship. So some people come in and they do multiple internships. They do a Google Summer of Code. They'll do one with Intel. They'll do one with Red Hat. They'll do one with us. They're building up their resume and their career. But they're jumping from project to project. And so really, which is great, and lots of people do that. I'm shocked at how many did so many. I look at these people and I'm like, oh my god, where did you find the time to do that? But what we're looking for in the CNCF is we're trying to train more people to do things, like Kubernetes and be cloud natives. And we would really like, if we're going to put the effort into them being mentored, that they would stay and grow into being active participants. So we can look at, post their event, we can look in and see who stayed and who didn't stay. Whether they stayed in the focus of their mentorship or whether they went on to work in one of the other. How many projects are there? I have 177 projects asked on my check. So there's lots of things for them to choose from. So we're not totally particular. Well, and that's one of the things too that I think one of the things I'd like to do is redefine what winning is a little bit. If somebody is coming in and doing cloud native computing mentorship and then decides, oh, you know what? I'm really into storage and goes off and does another internship with somebody else and says, OK, well, I'm not doing cloud anymore, but I'm still working an open source over here. I think that's still a win for us. And that's the type of thing that we can find out here as well. And you can't do that with a spreadsheet. So here you go. So part of it too is the retention, whether we retain them within the project so they continue to work. Say they did something in flux as an internship and then they stayed on and continued to work in that, or whether they were at a university and then ended up working at another company, especially wonderful if it's a CNCF member organization. The other thing is even if they didn't go to a CNCF member organization, maybe that's a new potential member because we may not have known that that company was using flux or service mesh or Kubernetes. And here we have this wonderful database with all the indexes and that we can see over time their affiliation change, so their career growth and what projects they're working on are really important. So you start to drill down on that. The other things that are really interesting if you're a total data nerd like we have become than I am, is the connections between projects and people. And some mentors are better than others. Or at least are more prolific. More prolific. And I think this is the one thing. If anyone is watching this out in YouTube land afterwards and you are a maintainer on a CNCF open source project and you haven't come and talked to Nate about utilizing the mentorship program, it is the hidden secret of the whole CNCF. They are paid for the most part. Our mentees are all paid. Are all paid. Some of the Linux kernel ones are unpaid, I think. But some of the older ones. Potentially. Potentially are some of them. But if you're a CNCF and you have an artifact or some documentation or something you need done, this is an amazing program to participate in. And it doesn't really, it's not that hard to get involved in and there's a call for papers coming up soon. But one of the things we start to look at is the connectiveness that they retain from the mentor. So in this case, if we zoom in a little bit, the next slide, we can see that affiliation was meshery and we were trying to figure out why was all this meshery stuff going on. And that's a wonderful project. They sponsored a whole bunch of small artifacts and really effectively used the mentorship program. If you go one more time. And then this guy popped up. If you haven't met Lee Calcott, then you haven't been around the CNCF very much. But he runs a small company now called Layer 5. And he has really effectively used and grown a number of people within his network of who have then either gone on to continue to contribute to meshery or actually even if you click one more time. Oops, have gone on to join Layer 5 as employees because they spent this time being trained. So this was kind of one of the wonderful things about being able to drill down on the data and see it over the life of these people's careers. We focused in this first half of the research because we've only been doing this for a few months now. About three, yeah. Three months on the mentees. But the same can be said to be true for the mentors. Some of the mentors, these are the first times that they really managed other people. It's a great growth opportunity for them to learn skills around managing developer resources. So let's go again. So you can also see that it's not just the meshery project that benefited. We can drill down and see that this small little cohort that we were looking at had contributed to over 33 other CNCF projects. So you can see all this from the GitHub data, from the comments, from the issues, from the mailing list participation that we've pulled into the data lake that we use and the indexes that parse through it all. So these are the kinds of tools that we're really trying hard to, oops. Sorry. You can run that if you'd like. I think I can run that. Let's see. There we go. Sorry then. So we can see these things and what we're really looking for is patterns and best practices. So when we look at someone like Lee who's done this and we still do have spreadsheets, we can also see other companies and other projects that have really effectively done this and we can encourage and talk to those mentors and find out what they did and what the best practices are. And some of these things popped out big time. Let's go to the next one. Before we move on, I really want to emphasize that. Mentees who participated in the mentoring program with Lee went on to contribute to 33 other projects. That's a force multiplier. That's an impressive amount of contributions to have generated. Yeah, and so you have also this other virtuous cycle of people who were mentees who became mentors and so we can track that too because some of that data is flagged there and... It's flagged and it's a very rare thing to... I think I can count it on one hand how many times this has happened in the last few years. So finding those pieces of data is really helpful because then you can go back and see what the process was. Like, oh, well, who was doing this? What were they doing? Yeah, and then you can nurture these people and support them and then help them go back to their organizations and say, see, you allowed me to do these 10 mentorships at, you know, with Huawei and Hong Kong, Ren was the example that we pulled up but there were lots of these patterns that we could see in the data now and all of these things, if you're managing, if you're at a foundation or an open source project and you're trying to manage your mentees, you can't find that with a spreadsheet and so this allows us to see these connections between people. So then if we're looking for a mentee that has contributed to, say, EtsyD or logged an issue at least on EtsyD and then maybe is working in Kubernetes and you're trying to find someone to mentor, to work on some artifact, you can use these tools to do that and that's really what we're trying to do is kinda look at people as they flip through and become mentors and mentees because those people, I think originally you had to be a maintainer to be a mentor and I think they've switched that around a little bit now. Yeah, we did, we made that change about a year ago and again, maintainers are some of our most time-starved community members and to say that, oh, if you wanted to participate in the mentoring program, you have to be a maintainer was too ornerous and so one of the things that we found was saying, okay, if you have a trusted contributor with commit access or approve access at least and the maintainer is willing to sign off on it, then we were able to grow, I think we went from something like 50 or 100, last year to 100, almost 150 this year, even small changes like that saying, okay, you know what, who is eligible to be a maintainer or can we have multiple maintainers on, rather, sorry, mentors? There's too many M words here, maintainers, mentors, mentees, saying, okay, you can have multiple mentors on a thing and not every one of them has to be a maintainer as long as the maintainer signs off on it at the beginning, then we're able to include a whole lot more people, really grow our pie. What was the next one? It's no much. Yeah, so the other thing, you know, a lot of it is about retention rates, like did they stay in the ecosystem? Did they go to join a member organization? Did we grow a skilled developer or a technical documentation person or a website person or a kernel, you know, what is being able to watch these things and grow them has been really, really, really helpful and, you know, some of the stuff, you know, making sure people don't disappear off the radar, we had one of the best practices that came out almost immediately was on the Linux Foundation's profile pages, an incomplete profile was almost a perfect red flag for someone who was not going to be retained in the ecosystem. You could correlate those two things pretty closely, so we've been able to go back and in this next cohort, make sure that they did do a good job on their profile page and so people could find them to hire them. These are basic things, but you wouldn't expect them, but you can see that corollary pretty close. Well, this is where this is all feeding back into is, as we're writing our administrative guides for our mentoring programs, these are the types of things that we're putting back in, saying, okay, well, these are our list of best practices as we know them. So go for it, other areas of research. All right, so today you heard in the opening keynote, Linus was talking about 50% of the maintainers have been there all the time and then the other 50% are doing one little kernel patch and then walk away and disappear. And so one of the thing, and it was really gratifying to hear that because it correlates with some of the numbers that we're seeing, so we've also started working with the Linux kernel mentorships. So that's really the next series of cohorts that we're gonna do some deep diving and analysis and we've started. And one of the things we did because we were so interested in seeing how the retention in the ecosystem and how important it is to get them to stay to be maintainers for the kernel because the average age is getting older. That's a fair characterization, thank you. We got some gray hairs going on that we really wanna make sure that we're nurturing these things. And Shua Khan who works with the Linux Foundation, way down here you can see if I can do this. This little one is Shua Khan and we filtered up here on just all the names of all of the people that she has gone through and she's been one of the mentors for. A lot of times there's two mentors for each of things but I just filtered on. Everybody that Shua had worked on and what companies they were working on. And so this is, she's got people working on Elisa, on the kernel, on drivers, all kinds of things underneath her and we're really trying to use this same methodology we use for the CNCF to help with the Linux understanding, the Linux kernel mentorship program and how we can make it more effective. And again, this is for me, I mean I love these diagrams and I know they're very tiny and you probably can't see them so download the PDF and scan them out. But the really interesting thing for here is to start to look at the affiliations and I did this the last seven years but I think it's, Linus said 23 years of that so we have all the data for the Linux kernel in the data set now. So I could go back to this and what's interesting here is this is the network diagram of everyone and how they're related of hers to Shua. So all of the people that she mentored, this is her connection list and whether they're still in the community or not and whether they're contributing. But it also over time the affiliations show up as well and it's the affiliations that show up in these graphs at the time of their contribution. So one of the really key things is being able to do that and if you go to the next slide I think that shows it a little bit better. It's like, this is just Shua's diagram here but you can see that she worked at HP until 2019 and then Samsung now she's at the Linux foundation but at the time of the majority of her contributions in the last seven years, though I think the last one that was in that cohort group was she was working at Samsung. So the affiliations still stay tagged to whomever they were working for or they declared themselves as working for. And the data is really, it is coming from GitHub what they did over time, the historical data analysis of GitHub and the repositories and taking all that information and being able to pull all of that together. So if you go one more. So for them it's again the same thing that's really beyond retention is really trying to find out mentees who became mentors and the most important thing really in the Linux kernel is and we can grab the maintainers MD files from all of the sub directories and use those to flag people as maintainers and see and compare who's come in as a maintainer after they did a mentorship program and growing more mentors. So sorting out who can be a mentor and partnering them with older or not older wiser more experienced mentees and mentors. And the next thing that we're doing in one of the things I'm really psyched about being here is we're adding in all of the projects from the automotive linux ecosystem too. So we'll be able to see if there's any crossover from the Linux kernel participation to all of the stuff that's going on in Yachto and everything that's happening in AGL too. So making just like we had for the CNCF all of the CNCF projects in one big data set that we can compare where people are moving to and from we can do the same thing. My hypothesis is there's a lot of overlap between a lot of us going on in the Linux foundation. Or not. Or not. They could all be working on drivers and never going to the core. So go for it. Yeah. And so that's, again, so what we're trying to get out of this is how do we improve our processes and our practices. LFX profiles are a big part of people being able to get hired from having done a mentorship, making sure that your GitHub profile is, if you just have the default profile, that's good. But you can change that and make it a real, you can tout your achievements right there as your own personal website, but within the GitHub ecosystem it really is effective. Again, I sort of talked about the once is enough anecdote already, but it was really one of those things where it sort of showed me the power of having data sort of at your, instead of having to have somebody open a support ticket saying, hey, there's an issue here, to have been able to catch that and not have to have gone through any disciplinary action and just said, okay, well, instead of accepting them and then saying, sorry, you're actually not accepted, to have been able to predict that and catch that in real time would have been amazing. And then some of the things that we're doing and the Linux Foundation is already doing this, but following up with surveys to really find out, okay, well, because this is all self-reported and whatnot, looking at LinkedIn, looking at GitHub and whatnot and associations there, reaching out to former mentors, former mentees and seeing where they're at today and how they feel having gone through the program earlier. I think that was one of the things, too, is that the research methodology, I'm all about the data. That's really, I love the data, but I think one of the things is all the follow-up surveys that we have to do as well, we have the connections to the people through the Linux Foundation's mailing list and trying to make sure that they stay connected to the CNCF or we know why they didn't, if something happened or they all did go on to become actuaries instead of developers. What happened? It happened once, so that's why I keep rounding on that. But it also allows, make sure that nobody falls off the rails here. We can really keep track, real time, of the participants in the present cohort as well and flag much more, much better early warnings when somebody's not participating actively or has not been able to meet with a mentor and stuff. So it's a mix of the qualitative stuff and the quantitative stuff. And I always say, if you don't have context, you can't do this. If you just have the data, you need someone like Nate who's dedicated to this, knows all the players and where they're hiding. And speaking of the players and where they're hiding, one of the things that I feel like we need to get better at in our program is thanking them. A lot of folks spend a lot of time mentoring. It's not a small thing that we ask folks to do. And there's also the companies that they're working for. All of our mentees are paid. That's coming through the LFX, but the mentors we expect are all paid by their employer to do this work. And so thanking both the mentors and the member companies that are supporting them is another piece that we're adding in, moving forward saying, okay, how can we thank folks? How can we show tokens of appreciation be it credibly badges or other pieces of appreciation that we can bring forward? I'm gonna say one more thing is that, I'm here, improving engagement practices, but also giving people like Nate at the different mentorship programs the tools to do this because I think he just sort of glossed it over. I think they went from 30 to 50 people in a cohort to like 150 people. And when there's only one administrator, that's a really tough thing to manage and to keep track of these people and to not be able to have some sort of a dashboard or something to help with the automation. So these guys, Ihor before him, Nate, the Shua, the Linux, who's managing the Linux kernel folks, these people are just doing amazing things. And what we really, as part of the mentoring working group, we wanna thank them as well and also give them the tools and the best practices and documentation feedback loop to make this even a bigger problem for them to solve. And so again, going back to some of the mentoring working group thing that's part of, we've now recruited a community member to help administer Google Summer of Code with us. We're just shifting chairs now. And so I'm still staying on as a co-chair. We're being on a new co-chair who will likely be helping with some of the administration of the LFX program as well. So we're trying to, even in the organization, have community members come in and participate in this way as well. And this is just an interesting piece of 170, and this is again CNCF sort of focus rather than going back to the Linux foundation level, but only 55 of 177 projects have participated in the mentoring program so far. And so while as a project, why would you want to participate? Well, you get a piece of work done, right? You're helping grow your project. You get to recruit new contributors. You've got an increase in your project's visibility, especially if people are writing about it and doing blog entries for the work that has been done. So it's a real opportunity to help grow your project in a very productive way where you're helping people come along and grow their careers. This slide actually was, I think, left over from the member summit, but I'm gonna keep it in here because if you're a member organization of the CNCF, why would you want to participate in the mentorship program? Well, again, you get a piece of work done. If you're supporting an open source project that you're already depending on as a part of your business and you've got one of your employees working as a mentor, then you've got the opportunity to learn who some of the folks in the ecosystem are and potentially that's a way of recruiting people into your company. So yeah, both recruiting mentees as contributors but also potentially recruiting mentees as employees. I think the other thing, the visibility that we get now down to the affiliations of the mentors and the ability for us to go and thank the mentors organizations for letting them be mentors. I think sometimes it's a surprise to the mentors organization that their person has spent this time and effort as a mentor. And I think that's one of the things that we're trying to build into our practices for the mentorship programs is making sure that they're properly supported by their member organizations, that the member organizations really see the benefits of allowing their employees to do so. And that's really one of the key things here for member organizations. We've always heard Kubernetes is hard, all these things and we need to get these skilled technical developers out there and technical documentation folks out here. This is why this program exists and anything we can do to facilitate scaling Nate. There's a lot of very talented mentees out there. Please hire them. So why should you be a mentor? And I think that this is very similar to why you would want to be a mentee. It's an opportunity to grow your career. A lot of, I hope, and I'm coaching now, our mentors to include mentoring work in their promo packets. If they happen to be working for a company that does that. You're growing your network, you're meeting folks who are new in the program, coming up and potentially if you're new in a job. And you're saying, hey, I've got this open source project that I'm working on and I've written a proposal for a mentorship term and submitted that and got that accepted. So you're showing thought leadership on, okay, what needs to be updated in a project. You're doing interviews and figuring out who should best do that work. So you're hiring people, you're managing the work that they're doing. These are all full-time programs for the mentees. So if you're bringing somebody on as a mentor, not only are you mentoring them and coaching them, but you're also checking their work and understanding. So now all of a sudden you can see, okay, well, this is how I'm communicating with my mentee. We've got these issues opened up. Here's the PR that my mentee has opened up. Here's the feedback that I've provided them and the changes that they made based on my feedback. And then you've got, hopefully, a merged commit and then you can say, okay, not only have I coached somebody through this whole process, I've also been able to communicate that to my boss, potentially, and hopefully getting some recognition from that, from the employee side. So I think we're just about out of time here. So I think we've got a little bit of time left. I've got two minutes on my clock here. Are there any questions? How many of you in the room, I have a question, are running mentorship programs with your projects today? There's a couple of you in the room doing that. So I think, and are they CNCF projects or outside of CNCF? I'm outside, I'm from WordPress. Oh, and you've have a really lovely site inside of WordPress recognizing mentors. I've gone over and taken a peek at it. So much like the Linux Foundation has its profile pages with the mentees and the mentorships, the WordPress folks have a very nice way to showcase the people who are working on that. And I think that's one of the key pieces, outcomes here is is there a way, besides listing on your LinkedIn page, that you can as a foundation add value to this stuff so they can get a, it's almost like recognition too. It's very well done over there. So kudos to you over there. Thank you. And there's a stop sign in front of me, but there's a question way back here. So go for it. I'm at UC Santa Cruz. And so we have a couple of different ways that we engage university students with outside projects and also internal research projects. My question, well, I have a few questions. I'll come find you afterwards. But my first question is, so you indicated the data can reveal something like a particular mentor who is having huge impact. And I was wondering if you've done any work yet to investigate the characteristics of a good mentor, like inventories that you're distributing to, like there's some really interesting mentorship inventories that assess how mentees feel respected, engaged, et cetera. Or there's other ideas you have about that. There's actually a lot of literature, academic literature out there. And we've been working, starting to work with the OSU, Oregon State University. And they've done a good extensive listing of all the literature. And I keep getting the stop sign here, but I'm gonna talk to you afterwards. Yeah, I'll come find you. Yes, and there are some, what I'm trying now to do is take those academic findings and see if they actually fall out in the data. And so do the corollary there. So, and there's, I think OSU gave us a list of 18 factors that they had culled from academic papers. And now I wanna apply that to the data to see if that actually shows up in the data. And like the little example we gave of, did they have a decent profile up there? And how did that affect their career opportunities afterwards or their retention in the ecosystem? That was hilarious, cause I had no idea that that would be a flag for that. And it was quite, it's quite fun. And you can go down wormholes, but there are a lot of what we're trying to do is take this information and apply it to the documentation for training mentors and mentees in the documentation for the mentorship program and roll it out to other parts of the Linux foundation and the academic and other foundations as well. So I think folks are coming in for the next talk. Is there time for one more question or are we finished? We are. We are done, thank you all for coming out. We appreciate it. Thank you for coming. Enjoy the rest of your day. All right. Take care.