 Hi everyone. Today I will be speaking on the topic building mentorship opportunities at your open source organizations. First of all, thanks for providing me this opportunity to share my insights and experience on building relevant mentorship opportunities at my open source organization. And today I will be speaking about the very same experiences. Before getting into the topic, let me just quickly introduce myself. My name is Harsh and currently I'm working as an engineer at local stack. I'm also overseeing the technical community at Mojo Global. Mojo Global is an open source community under the Linux Foundation where we basically develop climate action tools so that we can reduce the overall greenhouse gas emissions in the land use sector. I will also be heavily talking about Mojo Global and how we developed our own mentoring initiatives over there and how we are supporting a community of more than a few dozen contributors so that they can contribute to a wide array of the projects that we are developing over there. So just tighten your seat belts and let us get started with this whole session. So before getting into the notes and grids of my session, let me just quickly introduce what Mojo Global is. So as I mentioned before, Mojo Global is a not-for-profit open source collaborative organization under the Linux Foundation and we have a huge community of scientists, experts, policy developers, contributors who are mostly students so that they can help us develop our huge series of open source software, one of which includes Flint. Flint basically stands for full land integration tool and it is a C++ framework that allows different countries, entities and organizations to independently develop a measurement, reporting and verification software which we basically colorically call as an MRB. So through the Mojo Global toolings, we are helping these users and entities so that they can estimate these greenhouse gas emissions and they can credibly track it and remove it from the land use sector. The reason why I'm speaking about Mojo Global is because a lot of the things that we have put forward in this session, these things have been practically done and learned by developing various range of mentorship initiatives at Mojo Global itself. So this topic is quite close to my heart and that's the reason we are just mentioning about it. So I joined Mojo Global community back in 2021 as a very new contributor and back then the community was not that very great. We had less than half a dozen active contributors and we had many of the people who were just contributing for the sake of some sort of an open source program like maybe Google Summer of Code or Google Season of Dogs or something further. So we did not get selected for Google Summer of Code but we did get selected for Google Season of Dogs and during my tenure at Mojo Global as a Google Season of Dogs intern and further as a community manager, we heavily invested upon increasing the size of our community, supporting the various community members who are looking to contribute to our projects and making sure that they feel home while they are contributing and they simply don't feel left out. So the result of all of these initiatives have almost led us to more than 400% increase in just the last year. We don't have the exact numbers for this year but I guess we have been simply growing over the time. So this is a kind of interactions and this is the kind of example that I want to put forward before we officially begin with this session because it sets the course for all of the lessons and all of the things that we have learned over the time that will help me communicate this much better. So at Mojo Global, we have like various working groups like mentorship working groups, documentation working groups, interface design working groups, implementation working groups. In this session, we will talk about how we do things at the mentorship working group and how we further develop these mentoring initiatives at Mojo Global itself. So with the whole course set and with the specific context set about the whole session, let us get started with what the agenda holds us for today. So in today's agenda, we will be covering over five basic pointers. First, we will be identifying the pain points in bringing forward the new contributors to our community. Next, we are going to find like what sort of relevant mentorship opportunities are there for new contributors and what kind of things that they can participate in and how we can officially support these new contributors coming in our community. Third, we are going to talk about how to build a mentorship working group by taking some of the lessons that we executed at Mojo Global itself. Fourth, we are going to talk about how you can bridge the gap between the mentors and the new contributors so that these new contributors don't feel left out when they are contributing for the very first time and how the mentors can officially take the charge of building the capabilities of these new contributors and make sure that they feel welcomed and they feel safe within the community. Fifth, we are going to talk about some of the best practices, like what you can do to make sure that you get inside these mentorship programs. You make sure that all of the mentees whom you're like basically mentoring, tutoring and doing all sort of things, how they are officially supported so that they can build out their careers and more of these things. Finally, we are going to have a Q&A. Since this is a prerecorded meetup, I will be available on the relevant Q&A channels so that I can clear out any specific questions that are coming up about my talk or about anything in general about open source and mentorship. With this in mind, let's get started up now. The very first agenda of our talk today is identifying the specific pain points in bringing the new contributors and some of the lessons that we have learned over the time about why do these new contributors don't exactly contribute and what are the ways that we can make sure that they feel safe and they feel included in the community that will further prompt them to get started with the contributing. So let us ask the very first question to us. Why exactly do these open source participation matters? So open source as we all know, it's a collaborative model to develop software and it can include various aspects of software development, not just coding but also some no code contributions which might include documentation, bug triaging, user interface development, user experience development, product management and much more. So open source which was obviously regarded as a one-dimensional aspect earlier where people are just hardcore software developers committing a lot of code to make sure that this project exactly has a functionality that you might expect them to. Now open source development has multiple separate dimensions altogether and this makes it even more easier for people to contribute because now everyone can feel included in the community. They can be software developers, they can be designers, they can be documentation writers and everyone can feel free to contribute in whatever way that they can. So the reason why open source participation matters, the very first point is that you get to fix these bugs, these issues, these enhancements, these feature requests collaboratively and by reducing the overall risk. If the whole open source project is a one-man or one-person show, it might just lead that the one person is responsible for everything. They will be responsible for creating new features. They will be responsible for fixing the old bugs. They will be responsible for supporting the new users who might be just having some troubles using that project. So we need to make sure that people are doing this in a collaborative manner so that we bring a sense of shared resource and we bring a sense of a shared responsibility as well. The second point is that we need to have shared development resources for reduced costs. Obviously, if one developer is working on that project, that will just make sure that the whole technical depth on that project will be accumulating over the time. Sometimes it can go for maybe a month or two, sometimes it can even go for decades where one single person is so much overburdened that the whole technical depth has been introduced to the project and we simply have no sense of how we can get out of it. Third, we want to build some training resources so that we can build internal capacity. Internal capacity can refer to something of a capability building that every open source organization has so that they can fix the old issues, enhance the new ones and also bring out some new features that can support an ever-growing community of users. And finally, you get to find a mentor for yourself. You can basically teach to learn. You can grow your reputation. You can go to various conferences just like me and maybe share your experience and that can overall lead to a great participation model within your community. So why exactly is open source participation good? This question can be answered from a lot of different perspectives. For users, you get to become a part of the community. You get to get some visibility. You get to attract some other users. You also get to find relevant service providers. You also get to find some donors and that's something that we're not going to cover out. The second, it is for the contributors because they get to provide some feedback. They get to improve the code, the documentation, the new features and everything that can help improve that project. For maintainers, we need the open source participation so that we get to streamline our strategy. We get to streamline our direction. We get to build the tools that can meet the needs of the new users, the new developers, and we can also exchange our expertise with a huge community of users, developers, contributors and much more so that the overall steering of the community is straight in the right direction. But now the dilemma for most of the new contributors and, sorry, not the new contributors but the new maintainers is that why are we not getting enough contributions? We just build a huge fancy, great open source project. We have open source data. We have a really nice, maybe a readme. We have a really nice website. But why exactly are the people not contributing? What is that that it is holding them out? There are many three reasons for that as far as I've seen in my experience. The first one, the contributors don't find enough supporting materials. Pretty sure that you must have some great videos, some great resources, a great readme. But in the essence of trying to market your open source project, everything just ends up to be a marketing material and not something that the contributors will exactly find useful. So that's the reason why you need to heavily invest upon specific materials that can help improve your project. The first one to start with is obviously the official documentation. If you don't have something like a developer documentation, you don't have something that can allow a developer to set up the project on their local machine. You don't have references, you don't have guides, you don't have tutorials. Most of the people who start up being a contributor to an open source project, they first try to use that project themselves. And if they have no references, no tutorials, pretty sure that they will be lost in the first instance itself. Second, contributors exactly have no one to look up to. They don't exactly find the relevant mentors, the community navigators, the maintainers, whom they can ask a relevant question and basically get clear about. And further, sometimes even if you happen to get some of your contributions merged, you might not feel appreciated. You might not be celebrated. And this might just lead to further demotivation. If your contribution has for some reason been rejected, you might feel even further demotivated and you will just make a mental note that, hey, I'm not going to make a contribution anymore. So lack of open source collaboration can just open up a Pandora box of multiple ill doings. First, it will lead to a low adoption drive because no one knows about what your vision is. No one knows about what your practices are. It will further lead to an overburdened work schedule on maintainers because they now get to do all sorts of things. They now need to build the new features. They now need to fix the old bugs. They now need to support the new users, everything. And finally, like the lack of contributions can just lead the existing users to turn away because since a maintainer is overburdened, since they have no one to basically delegate their work to, most of the users will not exactly find themselves confident of using that project. Maybe ask yourself, you go to an open source project and you find over a thousand issues open and maybe over 500 PRs open. Most of the users, including me, we will feel entirely motivated to exactly use that project. And due to all of this, the product will simply crumble under the heavy development scope and this will just lead to a short in lifespan. Your project will be dead even before it has started. So to build an active and vibrant community, we need to make sure that we have the following things. The first, your project is easy to use and easy to understand and easy to for others as well. So if I'm building out a project and if I need to communicate it with others, it should be literally easy for me to get started with. Second, I need to build a contribution guideline. I need to build a community funnel so that I can bring in more folks who can feel included within the community. This is one of the first and the foremost things that I actually evangelize, that if you're starting out with any open source project, better get started with a contribution guideline and better get started with a community funnel. Third, you need to build diversity in your community. A lot of the projects literally face poor diversity, poor representation of minority groups. And this can further lead you to lose out on some really great ideas that can further improve your project. And finally, you need to make sure that your project enforces a code of conduct. A code of conduct will literally help you to focus your synergies on the right things and also weed out the bad actors because not everyone is really nice online and you really need to make sure that the good people don't turn away because of the bad actors. So bringing out a code of conduct can literally make sure that people feel welcomed into your vibrant community that you're building right now. So this ends up the first agenda of our talk and now we are going to talk about what sort of relevant mentorship opportunities that we can build out for new contributors. So the first question itself, why should I be exactly bothered about mentorship? The very first thing is the open source teams are volunteer based. No one is exactly getting paid to contribute to your project. Most of the open source contributions are volunteer based because people come in as volunteers. They find out some free time in their schedule and they just want to get started with contributing. They are diverse. They are distributed across the globe. So you might end up mentoring someone who might be sitting in a different part of the world and this can be a hugely enriching experience. You get to build the capabilities within the community. Remember what I talked about, the capability building in the community and the resources. This is the exact moment when you want to do that. The third one, the mentorship programs will help you find some new contributors who the heck doesn't want to get new contributors on your project because the number of contributors that are increasing on your project, the more confidence people will get in using your product and these new contributors will further become the future maintainers because once they get past their initial learning stage, they can now independently do stuff. They can independently execute their own plans and they can get to partake in the overall decision-making process. And finally, as a maintainer yourself, you get to trust your team and you get to delegate your task. You literally cannot do everything on your own so you need to trust so that you can delegate it to others. So within Mocha Global itself, we have been working with various mentorship initiatives, various mentorship opportunities. Some of these include the Linux Foundation mentorship itself, something that we call or call as the LFX mentorship. So over the past two years, we have been a regular participant in the LFX mentorship. We have literally mentored over a dozen mentees through various projects and we have been supporting these mentors, these new mentees by asking them to work on some of the projects that we have. Some of the ones that I have listed over here is using machine learning to predict deforestation, cloud native climate change mitigation, and environmentally sensitive growth model and online courses for Mocha Global's purpose. So LFX mentorship is an open platform for all of the organizations that are a part of the Linux Foundation. So if you have not started with that, maybe you can just get started with an organization profile and you can start listing out the various projects that you have in the mine and you can start looking out for relevant funding sources. So LFX mentorship is a really great place to find some new people who are just getting started with open source and it is a really great way to build up some new talent and retain them out. Next, we have Google's open source. So Google open source has been running this particular program called as Google Summer of Code. I've been a Google Summer of Code participant last year and this year I'm a Google Summer of Code administrator. So Google Summer of Code is a 12 weeks long open source program where people just basically get to participate in over 200 plus organizations contributing to various aspects of software development. Google has also launched the Google Season of Docs, which is primarily focused on technical documentation and documentation engineering. And this is also a great program for technical writing as well. I have been a participant and a mentor in Season of Docs as well. And finally, we have got Outreachy. Outreachy specifically focuses on people coming from underrepresented sections of the society. So they might include women, LGBTQ plus and more so that they can get to participate in open source development around various organizations itself. I have been a participant in almost all of these open source programs either as a mentee myself or as a mentor and all of these mentorship opportunities help us to find some new mentees who can get to work with us and they further take up some new responsibilities after their mentorship gets over. Some of them become maintainers of the respective project themselves while some of them just go forward with their career trying to mentor some other folks into getting started with open source. So as I listed before, there are multiple mentorship opportunities. There's Google Summer of Code, Google Season of Docs, Outreachy, LFS mentorship. If you're not able to participate in any of them, you can also start with your own mentorship opportunity. Over here, I have listed an example from Async API. Async API is also a member organization of the Linux Foundation and they hosted their own mentorship program because they got rejected from all the others except Google Season of Docs. So they decided that they have some funds through Open Collective which was nearly 15,000 US dollars. So they selected nearly 10 people to work with them offering each one a sum of 1,500 US dollars over a period of three months that was very, very similar to how Google Summer of Code plays out. And it was a really nice example of a community organizing its own mentorship program in order to support their new contributors. So with the mentorships, you get to build the diversity, you get to sustain your community because mentorships are pretty much low barrier to entry opportunities. Most of the newcomers who are entering into open source, they don't need to feel basically prepared for some technical interviews or technical grounds or assessments. They can just get started with picking up an issue, finding some unique ways to tackle it and you as a maintainer will get to review these, provide some constructive feedback and further. Mentorship will also get you some diverse contributions. It will also allow you to support the contribution with a good exchange of background expertise. Sometimes you're familiar with something which your mentee can learn from. Sometimes you're not familiar with something which your mentee itself and that's such a good way of building an exchange of shared practice. And finally, of course, you will build more confidence about mentors because you get to lead your projects, you get to provide these guidance to the new contributors and this will overall lead to a better self-esteem. So we have talked about all of this. So how can we exactly build out a mentorship working group? So that's a very interesting question, but let us first talk a lot, tackle the question on what exactly are working groups. The very first thing that navigating a community is difficult. It is difficult both from a coordination perspective and for the new participants to find the place. For example, let us say a participant joins a Slack community. They say like, hey, I am XYZ maybe and I'm looking out to find a new project which I can contribute to. And without a working group in place, you are just blurred out that, hey, this person says that this person is skilled in front-end development. What project can I exactly delegate to them? What person can I exactly ask to help this person out? What sort of issues this person can work on? As a maintainer yourself, this will exactly fry your brain out because you get to do a lot of things. You get to do a lot of thinking for each and every contributor. But now that you have a working group, you can simply say like, hey, it is nice to meet you. Thanks for joining our community. Why don't you just go inside this particular working group? You introduce yourself and maybe the working group coordinator can get in touch with you and they can help you find a relevant task to work upon. That's such a nice way of delegating things and working out stuff. So these work groups are not exactly about accountability. It is not to create some silos where people are working and they need to report back to you so that everything is working fine. Rather, they are about communication so that you can build out these capabilities, these new contributors in a sustained manner. You basically delegate these accountability to the folks who are responsible for a specific project or a specific aspect. These are the people that you basically call working group coordinators. And everyone who is joining a working group, they are pretty much joining out of their own interest, out of their own will. And they can do a lot of things. They can contribute, they can help, they can answer, they can help out some other new contributor as well. Or maybe they can discuss out with you about some new strategies. The opportunities are simply endless. So how can a mentorship working group help? The first thing, with the help of a mentorship working group, you get to mentor other folks, obviously. And you also get to outline, plan and execute an initiative. Let us say your organization has decided that, hey, we are participating in Google Summer of Code this time. But now that you have a lot of questions, who is exactly going to write the proposal? Who is exactly going to find the projects? Who exactly is going to find the mentors? These are too many questions that a single person can solve. And that's where a mentorship working group can basically help. The second is a mentoring working group can help the contributors learn and support them. Before any mentoring initiative, I have a mental map that, okay, these are the folks who have been inside this community for a long time and they really deserve to participate with us. So with a mentoring working group in place, you can basically support these contributors. You can oversee them, you can guide them. And you can basically allow them to participate in these initiatives so that they can sustain their contributions. And finally, a mentoring working group can also build a capability upscale because now the contributors will know that their contributions actually matter. It's simply not a voluntary initiative. It is simply not a scheme to get all of your code in and basically leave them out with just some good experience. You want to compensate them out with some really good initiative. And this is the way that we actually do that. So if you are building out a mentorship working group for the very first time, the very first thing that you can do is to actually find the relevant folks who are interested in these kind of things. Not a lot of these software developers are actually interested in planning, execution, evangelism and all sort of those things. But you really need to find out the volunteers who are exactly into these kind of stuff. They need to be interested in mentoring. They need to be like highly diverse. They need to be like purely welcoming to new contributors. And they need to have a good eye to detail who can actually plan things out and who can look out for the new initiatives. Once you have found out a new initiative, you need to plan it out well. Ensure that you have some good enough mentors for any program. For example, if an open source community is going to Google some more of code with, let's say only two or three mentors, it is a sure-short way to get rejected because two or three mentors, it's simply not enough number to support a good number of projects. Third, you need to define an idea of success. Success is something that's pretty subjective for every open source organization. Some might consider success to be a completion of an entire project. Some might consider success to be something that has been a learning initiative for the mentor and the mentee, obviously. You really need to look at it from a long-term perspective and see what is success for you and basically put it in the outline, your mentorship guide, so that the mentees also have an exact idea that this is how you look at success. And finally, you need to ensure that your mentee is taking away enough to learn and grow in their careers. Everyone has a career to build. Everyone is looking out for some new learnings, new opportunities, and sometimes you just need to let them go. But you need to make sure that they have enough learnings in their career so that they can grow out and they can help out the other folks in the community as well. And this is how you get to define some success metrics. Some of the success metrics might include how many mentees continue to contribute even after the initiative is over. For example, at Mojo Global, we basically keep track of how many of the mentees have been contributing for the past one or two years, who have been a participant in various open source programs that we were a part of. You also need to consider on what sort of new things have they learned. It can be technologies, it can be soft skills, it can be experience. It can be some other stuff. And this can be purely communicated by the mentee and the mentor themselves. You also need to consider what the overall feedback was for the mentor, from the mentor about the mentee and from the mentee about the mentor. And this is a really nice way to judge on how good a mentor has been in mentoring the new person. And it is also a good judge for you to understand on what kind of people you want to select for an upcoming mentorship initiative. Because sometimes things might go south but it's simply not your hands to control them. And finally, you also need to communicate with your community, like how the interaction was with the new mentee, how did they perceive your new contributions coming in. What is their exact feedback about it? Because if you're in a community, you need to make sure that everyone has a shared sense of responsibility. So even if the mentor is directly communicating one-on-one with the mentee, you also need to make sure that the mentee is communicating back with the community to ensure that everything is going fine. And this brings us to the next topic which is bridging the gap between mentors and the new contributors. So getting started with mentorship in the community is a tricky aspect. The first thing that you need to do is actually build out a guide. And if you're building out a guide, make sure that it is pretty much out in open source. This guide should include your code of conduct, your ethics, your guidelines so that you can ensure a safe and sound environment. Without a mentorship guide, you're basically ensuring that things might go sound and you simply have no code of conduct to ensure that everyone is on the same line. Second, you need to understand your mentors. What does your communication and mentoring style look like? Some of the folks might be very much interested in video communication. Some of them might be just interested in text communication. Some of the mentors are pretty much about active mentoring. They might just get into pair programming sessions with the mentee or they might just like provide some suggestions, provide some feedback, provide some learning resources and that would be it. You also need to understand how do the mentors see success because there might be some conflict around it. As a maintainer, you might see success as something while your maintainer might see the other thing. So you need to ensure that you have a shared vision of what the success is so that the mentee doesn't leave around dangling between the two definitions that we have put forward for them. And finally, we need to understand on what is the engagement actually looks like. So all of this is something that has been described in detail over mentorship guide. It's an open source website where you can exactly look of how you can build out your mentorship initiatives. It has some really nice templates and really some really nice resources. So definitely check it out and see what are the things that you can do. And before getting started with any sort of mentorship initiative, maybe just sit down and think about starting out with an experiment. Start with some initial mentoring. Maybe find one or two contributors who are exactly interested to learn from you and just mentor them or maybe ask some of your mentors to do that job for you. And see on how the contributors are exactly going about making your first batch. This is a good learning experience because it can help you retrospect of what sort of guides, what sort of references you have built out and it can further help you iterate on them. So you also need to ensure that the people are able to find the mentors through the initiatives. Over here, I have a very basic example of showing how the projects look like over module global. So every project has an abstract and every project has a category plus a rating. So this project has a medium difficulty. It is a low priority project. JavaScript, JavaScript, design systems, UI, UX are the relevant skills that are needed. This is the one 75 hours project. It is for Google summer of course specifications. A preferred contributor can be a student. They can be proficient and the mentors are Gopi, me and Gabriel, who is one of our other mentors. So every time you are listing down the project ideas, make sure that they have a description and they have an idea. Second, make sure that you direct all the interested contributors to the respective mentors and the expected script that they should possess. And finally, help them understand the takeaways of the mentorship and what they would be learning. All three of these are important for helping the people find mentors through these initiatives because if you don't put out this information out, most of the people might just leave out for days and days without finding the appropriate mentor for that. So, if you have any questions or questions that you would like to share with us, feel free to share them in the community or your mailing list, asking them, like asking you to like basically redirect them to the right mentor for that project. So for the mentor share, they might share a lot of things. They can share the knowledge, the kind of things that they know about. It can be related to the domain. It can be related to something out of the domain. It can be related to something that everyone needs in our day-to-day life, from a junior to a senior, obviously. They can share some advices. These advices can be obviously about their career, about their studies, or maybe something that they're exactly planning out to do further. And finally, they can share them a direction and a goal. A direction is necessary to make sure that the mentee is successful in their project or in whatever initiative that they're working on. So, the first thing that they can do is like, they should be doing their own research, which is like D-Y-O-R. So, every time they should be prepared with essentials and have an understanding of what exactly they're looking for, second, they need to help themselves. And this is a golden code that if you're helping yourself, the others might find easy to help you out. So, understand your needs and requirements because I really understood that this is something that I want to learn and I want to understand. And I found myself an opportunity which I can capitalize upon. Finally, do relevant follow-ups. A lot of the mentors have a lot of busy things going on in their life. They might be busy with the project. They might be busy with their job or they might be busy with their family. So, you don't really need to ask a mentor to follow up with you. You should be like doing relevant follow-ups with your mentor or maybe anyone who is involved in the community so that you can let them know your status and what exactly you are planning on next. It is a good way to share your blockers, share the things that you are planning out and some of the things that is on your mind so that the mentor can basically clear them out before you move on to the next thing. And finally, we have got the best practices while organizing any mentorship initiative. So, the very first is building out the relevant contribution project ideas. This is something that we have already discussed before. So, taking down any sort of a project idea, make sure that you're brainstorming with your maintainers, with your mentors and you have defined a fixed goal for your project. Second, understand the need of your projects, the kind of the skills that are required and the kind of skills that a mentor should be bringing. You can also add a separate note about what kind of things that mentor would also be learning because mentorship, after all, is a learning effort. It is not something that the mentor should be communicating to them. And finally, try to build out a shared ownership for the mentor so that they can discuss how they can brainstorm, they can collaborate, they can do a ton of things after all. So, once you have done all of this, define the mentorship funnel, find out relevant ways so that you can recruit the mentees. A lot of different organizations try to tackle this in a different manner. Some of them try to find mentees within their own community. So, once you have the mentor you can do a presentation on open platforms like LinkedIn or Indeed or something else. You can also put the mentorship initiatives on job board so that it is more accessible to people. Second, you should be discussing with the mentors about what's the most credible way of selecting folks. It can be proposals. This is something that Google Summer of course does. It can be virtually interviews. You should be dealing with the rejection. Come on, not everyone can get selected for the mentorship program. So, you need to understand of what the particular person should be doing after they are rejected out. What are your plans to basically make sure that they feel welcome in the community and you are basically supporting them out. These are some of the questions that you have to basically answer yourself depending upon your needs so that it is setting up regular checkpoints with them so that they can share their project updates with the rest of the community. This is one of the most essential things that most of the projects might miss out. They might just wait for the mentorship initiative to end so that they can get an update on their project. Please don't do that because a lot of the people have a habit of filtering within the whole initiative is going on. Instead, try to set up these regular one-on-one feedbacks between the mentor and the mentor so that they can understand the things that they can improve on and the tasks that they can do the next. A lot of the mentors might miss this out but instead try to set up a chat one-on-one so that every weekend your mentor and the mentor can basically share the feedback about each other and the kind of things that they have been doing over the past sometime. And finally, give the work a shout out at the end. This is something that almost every mentor deserves. It can be in form of blogs. It can be in form of videos or conference talks or something else. It is totally up to you. So with this we are at the closing end of this session. So thanks a lot for everyone for being patient and being a part of this session. If you have any questions please feel free to ask me on Twitter or maybe LinkedIn. You can just find me by my initials or just by my username which is Hersh underscore Casper. And that would be it. Thanks everyone for being a part of this session and I really hope you get to build some really nice mentorship initiatives within your community and I would be happy to hear about them sometime in the future. Have a great day everyone. Bye.