 a technical writer with SUSE and an advisor to Ovesa. But before working in the open source space, I was into the systems engineering side of things within IT. And honestly speaking, my segue into open source was with Kubernetes and not Linux, which is funny because I worked on a lot of Linux systems and was responsible for a lot of Linux administration in my jobs, but my segue like I said was via Kubernetes. And I'm here speaking to you really because I stood on the shoulders of giants and it was because of the mentorship opportunities that I have had personally that I was able to grow in my career and in my journey with an open source. So I'd be remiss if I didn't give them credit, but I also recognize that despite all the mentorship programs, initiatives, whether formal or informal, that we have within the technology space, mentorship opportunities or programs or initiatives, or what do we call them? They suffer from various problems because despite all the good intentions that go behind these initiatives, there are certain factors that we still don't recognize as hindering the progress or capturing the effectiveness of these initiatives. So with this session, hopefully what I aim to do is to walk you all through some of the common breakdowns and hopefully I'm here with some actionable take aways to sort of prevent them in your respective projects or wherever you're implementing these initiatives. So hopefully that sets some context and let's dive right in honestly. Now I know that everybody here knows what mentorship is, but I'll be speeding through this one. And typically in a mentorship effort, what tends to happen is there's a person or a set of people who are newcomers to the whole ecosystem whether it be the technology one or wherever else this initiative is taking place and there's a person who is slightly more experienced in that whole setup. So there is maybe I wouldn't say it's a bi-directional exchange here, but it's more of a initiative where the more experienced person takes on the role of a mentor to hand hold and guide the new entrant to the ecosystem in and help them navigate the ecosystem. Now mentorship in open source isn't really widely different because it's obvious that there is still a mapping between the mentor and the mentee. That's definitely there. However, given the flux that open source is always in, mentors are typically folks within the community who have slightly more experience. This doesn't necessarily translate to someone who's more older than you or who has more years of experience in the industry, but it's literally a person within that ecosystem who is more experienced and who has been around for longer. So they know a little better about how to navigate and how to best position a person within the ecosystem so that they can contribute more effectively. How it is also an additional community aspect factored into this loop. So what does that exactly mean? Typically in traditional mentorship setups, what happens is you have a mentor, you have a mentee and the interaction is pretty much limited to them within the whole program. But unlike in a traditional format, what happens in open source is that there's also the wider community that's factored into this loop. So to draw from a personal reference when I worked with a son on the Google season of docs, I was not expected to just work with the three sets of, not three sets, three mentors that I had and interact with just them. I was expected to seek community feedback from other people who previously worked on the code base, who were working on the code base, who were users of the code base so that I could effectively contribute in that mentorship program. This included previous participants of not just Google season of docs, but other outreach programs as well, other staff within CERN and other academicians who were accessing the documentation. But like I said, due to the inherent voluntary nature of open source, mentorship opportunities within open source aren't effectively able to provide the support and onboard a mentee as effectively as we would want to. Now I'm not saying that it's like a 100% failure rate, that is not what I'm intending to convey. But we could do things better. There's always room for improvement. And what are the reasons behind those failures or those breakdowns that we speak of? So these are the four areas where you see mentorship programs typically failing, whether they are formal or informal in nature because not every mentorship program has like a titular mentor, at least in open source. I went through many mentors who weren't titled as mentors. They just really were hand holding me throughout the process. So I had initially planned for this whole session to be like a curation of research papers, but I realized that that would be no fun because it would be very dry. And honestly speaking, nobody would really gain any benefit. So what I chose to do is to go through each of these breakdowns and draw from personal references again so that it's more real life, as they say. And hopefully that gives you an idea. And I'm also going to then share what actually worked for us, both not just as a community, but as a contributor as well. So hopefully that is able to give you a better picture of how to go about navigating that breakdown. So the first one up is procedural breakdowns. And the owners of this majorly falls in the community or the mentor is what is a common belief. But it's not just that. Honestly speaking, when I say laying out the scope and context, it's not just from the mentor's perspective or from the program's perspective that that should be an initiative. There should be a self assessment from the mentee side as well as to what they are capable of when applying for a mentorship program or while seeking out a mentorship. Because that's something that is grossly undervalued as a thing that goes on during mentorship program. People don't know what they want to be mentored in. People don't understand what are their skill sets. People don't understand where they are standing currently and where they want to be. And of course, there is a whole community aspect to it as well which we shall get into the next couple of slides. But that initial self assessment by the candidate who's seeking out mentorship is absolutely essential. And without that, both the mentor, the mentee and the community in general is setting themselves up for failure really when it comes to this whole program. So when I started out personally, I remember that I wanted to do a bunch of things. I wanted to learn every cloud native technology that was there on that landscape. And that was putting it very mildly. I signed up on a bunch of Slack channels. I reached out to everybody I could find who I could ask for work from but that was a mistake on my part because I should have clearly assessed what was my capability and what I could offer and what I could bring to the table and what I wanted to grow into rather than just taking on a bunch of responsibilities and spreading myself through. But there is this whole concept of also welcoming people into the community. There are not just cloud native tech but outside of cloud native tech wherever these mentorship programs are in place, there is a whole concept of welcoming people into the community and showing them around. It's just plain courtesy when you look at it. But that's an important step and it's a step a lot of us miss out on primarily because who wants to be actually the person who actually hand holds them and shows them hey, this is the place where you start off at, this is what you do. It's just plain courtesy and it sounds like rubbish when I'm actually saying it but it's that important step when you go into a community that you actually tell people that the new engine that this is how stuff works. Now, every community cannot afford to do that in with every contributor. Every single person cannot be mapped to one person which is why within the Kubernetes community which I'm part of, at least that's the only experience I can speak to. So within the Kubernetes community we have a named role for this. This is a new contributor ambassador. Now, it might not seem like much because how does it make a difference when the first person who actually comes and interacts with you is warm but it makes a really, really big difference when that person is actually very welcoming and is offering you help. I can speak from personal experience because had my first interactions not been warm and welcoming and were they all cold and rude, I probably wouldn't have been speaking in front of you all today because it's the people who matter at the end of the day. The community is made up of people, right? So honestly speaking, it's the people who matter and the tech comes second and that's something I always believe in. Again, going back to my efforts, it's my mentors, unofficial and official, they basically pointed me to resources where I could learn more. They urged me to take on more responsibilities and sometimes even nominated me for positions I didn't think myself worthy of. They did that with my consent of course but this is something that I think really helps. Having that human touch, having a face to actually onboard newer members, it need not be a role that is exactly similar to this but there should be someone who does this and whatever name you choose to give it is obviously upon you. It helps the connections build and there is proof, several research papers who go into measuring retention capacity for people who come into open source, new contributors who enter into open source, those folks have confirmed that a positive socialization experience at the start of every new contributor's journey actually does help in retaining them within the community and we all know how difficult it is to actually have voluntary contributors within open source so it's a challenge and this is just one of the ways obviously to address that. Now honestly speaking, that's one aspect of welcoming is one aspect but once you're in, once you have completed your first task, what's next? Because you wouldn't know where to go because you're new and it's like you have to go down a rabbit hole to find your next good issue or good task that you can work on. So having a new contributor ambassador and all of that roles help but also having a signpost maybe in your documentation or somewhere in the avenues where you interact really helps. Now, if I actually take a step back here and go back to my own experience, having within the Kubernetes community, again, there's a contributor ladder. Sorry. So the contributor ladders in general again help the contributors aspire to a higher role or a higher position within the community. That's one side but even when you are talking about different areas within the same community, all these issues wherein you need help and you need, if you tag them appropriately even within the avenue where you're troubleshooting these issues, those are good ways to actually attract contributors. So having a contributor ladder is just one way of gamifying the whole experience for a new contributor because you believe it or not, all of us here, even though I don't personally like playing games on the laptop or wherever, we're all living in a very gamified world. Slaying payments, getting that title, getting a promotion is all setting off the same pathways in our brain. It's like ticking off the checklist and moving on to the next level. So contribution ladder is one of the ways that you can achieve that gamification within your project. But like I said, for all this to happen, that very first step where the new contributor assesses themselves is extremely important because all this comes into play when you are aware of what you are able to do and will be able to do given the appropriate tools and the technology. So context and scope, whether it's on the side of the community or whether it's on the side of the person who's actually seeking mentorship is absolutely important. Now, scope and context in informal pairings is easy because you have that personal channel, you can just reach out and clarify that, hey, this is what I was intending to do and I think I might have gone a bit astray. But when it's like a one to many mentorship, it's going to be a bit more of a problem. And when we talk about formal mentorship programs, I'm sure that the person obviously has responsibilities more than just mentorship. It's going to be being an experienced contributor, their day lives, their day jobs, their normal lives. All of that comes into the picture. So how do you actually help with context setting in that case? And how do you help define the scope of the program? Now, when you talk about setting the context and forming the scope, first understanding the contributor is necessary. So having that first initial conversation with the contributor and understanding where they come from is necessary. Obviously you can only go so far as to trust their words and then go with an actual assessment. When I started out with the Google Season of Dogs program at Sun, they actually just gave me an assessment and told me to write a whole thing about the RUCO system that I was working on. And I had to actually, because I was involved with the Kubernetes community and that's something they saw, they were asking me to describe RUC on K, its installation. And because it was documentation, it was very relevant. But having that first stage of assessment really helped them understand what I could bring to the table, not just with respect to describing the whole system, but in understanding whether I could actually describe it succinctly and make a document out of it. So that's one thing. But there's also the concept of an entry level barrier when we come in, in most technical communities. In, you know, as of now, I think one of the biggest entry level barriers that newcomer faces when joining an open source project in the technical spaces learning it. And that's a common refrain I have heard because they're like, how the hell am I gonna finish learning, you know, get in one day? I was like, it's not gonna be a day, it's gonna be more, you know, it's gonna be an ongoing process. But understanding that that needs to be learned and documenting that somewhere is an onus on the community members, saying that these need to be the prerequisites that you need to have before you come in. I agree that there is, that is a significant entry level barrier to cross. But that needs to be there because otherwise there is going to be a whole, you know, there's going to be a whole influx of contributors who have nothing to do and aren't able to contribute effectively and a whole cohort of maintainers and mentors and experienced contributors who are taking on more than their share of work. So setting the expectations right at the beginning is important and that's why having that initial assessment, self and with your mentor and, you know, documenting your entry level barriers clearly is important. Now I've, you know, stayed quite a long on the procedural part of it. But let's look at a more familiar area of breakdown which is technical. So I have been personally traumatized by the phrase but it works on my machine. That's something that gives me knightness because honestly I've been in production support for way too long. So it's been the bane of my life to listen to people say it works on my machine when, you know, millions of dollars are stuck in payments. But I guess that's a topic for my next CFP. So technical breakdowns are common because, you know, not everybody has the same workstation and workstations really differ in the kind of, you know, specs that they support, whether it be, you know, the computer architecture, the software that can be downloaded, et cetera, et cetera. I mean, I don't need to go too deep into that. But to, again, go back to myself, I had a gaming laptop that could not even install a K8 cluster when I started out. And it significantly impeded the way I actually started out with Kubernetes. So that's where I think stuff like ephemeral dev environments and browser-based IDs come into the picture, right? I know that these are very recent things that have come into existence. And these folks have not paid me to say any of this, but I think it's a very great way to integrate more accessibility into our projects. I don't know if there's a hardware equivalent of this, really, so that's a question I, you know, I have personally for people who are, you know, working on programs, or mentorship programs that involve hardware as well. So I do not have any idea about that. But for software-based stuff, such things are a boon because it helps irrespective of the, you know, slowness of the internet connection or the spec that you have on your laptop. You're able to navigate or set up a cluster or do whatever it is. Now I've gone too deep into Kubernetes, so every time I say something, it's setting up a cluster that first comes to my mind as an example. But in general, that's something that really helps in the software side of things. Now, that was a very brief stop at technical breakdowns. The next one up on the circle was personal breakdowns. And it's an interesting focus point here because we're back to talking about humans again. So it could be both from the mentor as well as the mentee perspective. But I will be focusing on the mentor side of things here because I think it has a slightly more impact as compared to the mentee one. In the first couple of slides, I did say that mentorship and open-source has three broad components which are like the mentor, mentee, and the community. The mentor is a slightly more experienced person and then mentee is actually seeking to gain more experience. Given which the mentor probably has more elevated responsibilities and a day job and a life, whether voluntary or paid, that's a lot of things on one page. And honestly speaking, if the past couple of years is anything, is any indication of the future, all of this is going to be extremely difficult because at least it has taught me the value of time management and context switching. The reason being when you're required to context switch between a day job, between mentorship, initiative that you're a part of, between the open-source, other open-source tasks that you must complete, your personal life on the back burner, all of that comes together and it's very easy for you to spiral down into burnout, especially in remote setups. Now, a lot of us have moved back to offices but with remote setups I feel like that's a very easy to spiral into burnout if you do not have an effective strategy for time management and context switching. I would rather not recommend context switching at all because it's honestly a very ineffective way of dedicating of dedicating time and of blocking our time. But if you're a Jedi-level procrastinator like me, all of this is even more difficult, which is why if you're a mentor or a mentor or you're just like any normal human being if you're just floating around in space, you need to find strategies that work for you with respect to time management. Another thing is that with personal breakdowns, there is this problem which is actually not a problem if there aren't way too many mentees but one to way too many mentorship is a serious problem in general if there's already a lot on your plate. So I know that a lot of mentors don't have a say in how many mentees they take on but that's something that needs to be changed if you do have the power to do that because unless you actually are able to take on that much load you should not be because neither is it going to be good for the people who you are mentoring or for the community for whom this effort is in place. It's not going to be, it's going to be a lose-lose situation for everyone involved. And obviously not for, it's definitely going to be a lose-lose situation for you as well. And I think this is something Nadia Iqbal who wrote the book, Working in Public sort of covered very nicely. It's not aimed at dissing any mentorship programs but coupled with the fact that most of these programs don't actually do a good job of scoping out and that initial context setting how they go about doing it is not really done well. There is an added pressure on experienced contributors and maintainers to course correct and go above and beyond for the mentees which is okay up to a point but after that point it becomes a burden on the experienced contributor or maintainer because they obviously are doing so much more than just the mentoring opportunity. But now that I have covered all of this, this is like the last section of my presentation dealing with interpersonal breakdown. And throughout these past two years, I'm sure some of these are very relevant given that we were all remote for a really long time. It feels like a long time now. Whether it be struggling with time zones and not being able to attend that Zoom meeting at 4 a.m. in my time or struggling with keeping up with the cultural difference, it's difficult because we're all very different here and we're all probably going to identify with different genders, religious preferences, dietary preferences, et cetera. I'm sure it must have been a very tough task even with this conference which in itself is a community gathering to create a safe space for all of us to gather together. And honestly, even with all of this, there's going to be a little bit of slippage because no community or person is perfect. It's going to, you know, something is going to slip through the cracks. But if anything, I'm honestly, you know, here to say that all of those inclusion efforts that you're having, those outreach efforts that you're having for diversity candidates, they matter. Because without those, there are going to be several people in the dark who are deserving of opportunities. And it's on us as community members to actually voice those out and be the change we want to see. And that's a little cliche, but yeah. But when it comes to us, what can we do about it? This is something I've repeatedly heard because, you know, people struggle with meetings all the time. Like I remember when I started out as a contributor in Kubernetes two years back, there were no APAC time zone friendly meetings. I come from India. And it was a real struggle because how am I supposed to sit up till 12 a.m. to just attend one meeting? Eventually because, you know, we didn't seem like we were getting out of a pandemic anytime soon, there was a provision made across, you know, the work, different groups that were there as part of the project to account for APAC friendly meetings. But that was again not enough because what if a person couldn't actually make it to the meeting? What if a person had their daily life come in between? What if they couldn't account for, you know, an in-person meeting? So we had this whole system brought up, at least in the groups that I'm part of, wherein we also, you know, had an asynchronous meeting effort underway. Over and above which we also accounted for asynchronous presence. So suppose if you had to actually attend a meeting and couldn't make it and you wanted to, you know, voice out some points, there would be an agenda documentation ahead of time wherein you actually listed those points and those would be spoken to in the presentation. Sorry, not presentations. Those would be spoken to in the meeting and you could view a recording later. If any clarification was required, you could ask about it on the Slack channel or wherever you feel comfortable. Especially when you're talking about mentorship opportunities, it's not going to be that I'm going to find a mentor who's right next to my house. That's definitely not gonna be possible. So if you are a part of a program and you have the power to make the decision, always, always account for the fact that there are going to be a sync meetings. Always account for the fact that you might need to cancel some of those Zoom and Google Meet invites that you have sent out. Additionally, in open source, we go by consensus seeking rather than consensus driven decisions. There's a difference between the two. The reason being consensus seeking decisions aren't going to be hard and fast on the fact on whether you have given consensus or not. And it is especially important because when you're talking about mentorship opportunities in open source, you are engaging the new entrant into the community. You are embedding him into the community. So it's essential that they be familiarized with the fact that you may have different points of view. You may have a difference of opinion, but there is going to be a collective discussion about this and something that is seeking the consensus rather than a person saying that this is the way forward and that's all, that is not the case. And it's difficult when you come from a setup that is not really the same as open source because this was a paradigm shift for me when I realized that decisions here are consensus seeking rather than driven because in our day jobs, to be honest, that's not the case. And last but not the least, I think having inclusive language mandated as part of your daily interactions is a key. The reason being, it's essential to not use harmful language in general. It's difficult for a lot of people out there and using that language is simply not done because now we're a global community. So standardizing inclusive language and using that language within your communities is exceptionally important. And I think the Inclusion Naming Initiative does a fantastic job of that. I've linked to the website and my resources section so you can have a look later. And some of the ways you can actually do the, you can actually mandate inclusive language is by using bots to regulate inclusive language usage. It's there on the Kubernetes Slack so I know that it is possible. But yeah, that brings me to the resources slide which I was talking about and this whole deck will be up and shared once I get home and it'll also be available on my GitHub repo. And with that I think I've reached the logical end of my presentation and thank you so much for your time everyone. I hope you have a fantastic time at the event. Bye-bye. So also I will be open to taking any questions. I forgot to mention that. Yeah, please. Yeah. Should I start again or did you hear the first part? I could catch it but I think it would be better for the recording if you could start again. Sure. So when it comes to mentorship the mentee usually enters a new technological area that they're not familiar with. What I've found is that there's a challenge of creating a task for them like an initial task that's vague enough for them to allow them to investigate but not too specific to give them some room, you know. How do you or if do you have any methods that you recommend to teach them to, you know, think methodically and break down tasks effectively whilst at the same time you're navigating the challenging world of open source? Yeah, that's a very good question and honestly speaking that's a very subjective case to be honest because like you said it's going to be every entry into the ecosystem is going to have a different level of skills that they bring along with them. So when I'm assigning tasks or when I'm actually recommending people to work on specific areas of the project what I first do is I go and you know have that conversation with them as to what they're comfortable doing because I understand that you know even comfort levels vary with respect to a particular technology and it's not necessary that you know everybody starts at ground, at level zero some people could be starting at level 15 but still be comfortable with doing only level zero tasks because you know they're intimidated. So having that first initial conversation helps that's one thing. The second thing is providing them with the resources that they can actually you know start doing tasks with so based on the conversation that I have with them if there are specific resources that I can provide and there will be because there's a lot of documentation I don't recommend that all the documentation is good but there will be some documentation in your project that can help them get onboarded to the level of the tasks that they choose to actually I mean that you've chosen for them to work on and last but not the least constantly checking in with them and by constantly I don't mean pinging every hour but checking in with them and figuring out if there is you know anything that I can personally do or you know patching them with another resource within the project who probably you know be able to solve their problems better those are like the three steps I majorly follow because I understand that every like I start off I start off my contribution journey in open source with docs but I understand that not everybody wants to contribute to docs so that's that's what helps Thank you very much Thank you Oh I think we just have one minute so I'll be able to take the last question if there's anything or else I'll be at the Suitsa booth for a bit and we can chat there as well