 fostering a diamond in the rough, being a good mentor in open source. Hello everyone, I am Nikita Jukkate. I'm a senior software engineer at Bloomberg London. I work mostly with back-insides of applications and have an immense passion for scaling distributed systems. I am involved with open source for over six years now. Started as Google Summer of Code student, developer with Sigma organization and later on, volunteered as a mentor and contributed to organizations including Sigma, Sisters and Fosatia. For different programs like GSOC, Google Codein, Girls Summer of Code and more. I actively collaborate for various different communities like IEEE Women in Tech. Coursera's open source community had been an organizer for fourth edition of Learn IT Girl program and also serve on the Speaker Proposal Review Committee for Grace Hopper Conference. Apart from this, I enjoy singing and reading novels or trying some unknown adventures in my free time. If you would like to get in touch with me regarding the stock, open source or anything in general, reach out to me on LinkedIn or Twitter or you can write an email to me. Alright, let's get started. I would like to start by quoting Bob Proctor. A mentor is someone who sees more talent and ability within you than you see in yourself and helps bring it out of you. Reflecting on this, it wouldn't be off the mark to say the mentor fosters a diamond in the rough. Coming to open source mentor, well, the impact of open source technology is very well known. Contributing to open source can provide students, aspiring programmers and even experienced professionals with great hands-on experience working on real life projects and technologies. The review process and community guidelines and the interactions with the community members can generally accelerate the learning curve of any contributor. However, it may seem daunting to start contributing to it. That's where a mentor can play an important role. Let's understand the equation between open source and mentorship. Getting started with something new is generally hard and open source contribution is no exception to that. So any help with getting onboarded is always appreciated by a newcomer, which is why we emphasize on writing helpful contributing guidelines, tagging good first issues, etc. Let me share the story of how my open source journey started. Back in 2016 when I was a sophomore in college, I started contributing to open source. I initially felt lost in the project's huge code basis. There was a lot of documentation and guidelines to sort through, but the plethora of information was not very helpful. I found it overwhelming to navigate, plus some of it was not very comprehensible. Later that summer, I was accepted as a participant in Google Summer Off-Code program, which is popularly known as GSOC for Sigma Organization. And as part of it, I was paired with a mentor for the next three months. This had a massive impact on me. As my mentor helped me overcome the initial barriers in open source contribution, I was able to contribute significantly towards achieving Sigma's roadmap, and my mentor played a key role in making this possible. I remain deeply thankful to all my mentors who have continued to help me throughout my ongoing open source journey. The following year, I mentored another student for the same organization, Sigma, and later did so for sisters and other organizations. After having been both a mentee and a mentor myself, I believe mentoring is a critical element in diversifying the authorship and impact of open source technologies. Open source is about both technology and people. It matters who develops our technology and for whom it is made. Mentors are the bridge to creating open source communities that represent all of us, both the consumer and the creator sides of it. Need for precise mentors. Well, this talk is about being good, more specifically precise mentors in open source. The main goal here is to establish the need for precise mentors. And in other section of it, we will discuss the ways of being one. So what do we mean by precise mentors? These are not just mentors, but people who understand the unique dynamics of open source and can guide new contributors towards the right ways of participating in the community. Currently, the general sentiment across open source communities is that one who has already contributed to a project can serve as a mentor to a newbie for that project. This is possibly the reason why there are contributing guidelines for almost all the open source projects. Nonetheless, mentoring guidelines are lacking for even well-known open source organizations, which brings me to the point of the current state of the discussion around mentoring guidelines. In open source ecosystem, well, many well-known open source projects do not have mentoring guidelines. Some of it have some specific program related guidelines like for GSOC or something else that they participate in. But a customized mentoring guideline that highlights the ways to impart the communities and organizations vision and the ways of participating in their community is lacking. And another thing that I want to add over here is about addressing diversity and inclusion goals. Mentoring relationships are typically unavailable to members of historically marginalized groups. This shows that the lack of discussion around the subject of how to mentor with an inclusive mindset is one of the main reasons. There is a shocking absence of marginalized people in open source communities. Consider how an open source survey by GitHub in 2017 showcased that the gender imbalance in open source remains profound. 95% of the survey respondents were men, just 3% were women and 1% were non-binary. Interestingly, women were about as likely as men to say they were very interested in making future contributions. The percentage is being 68% versus 73%. But less likely to say they are very likely to actually do so, 45% versus 61%. Clearly, there's a burning need to consciously grow mentors and allies for people from underrepresented backgrounds in order to promote a more inclusive culture in open source development. So, why should one be a mentor? Why should one consider of taking up this role? First of all, as we just discussed, there's a need of mentor and mentorship as a framework as an instrument has a potential to make open source communities better for everyone involved in it. Secondly, there are various benefits of being a mentor. A lot of mentors say that mentoring has made them better developers and emphatic leaders. Mentoring help them acquire unique blend of skills and knowledge, gain confidence and self-esteem and also broaden their network. Yes, it requires energy and time investment, but it definitely feels worth it when you see your mentees thriving. Before doing it for the first time, you might feel, am I ready to be a mentor? As well as they say, every expert was once a beginner. There are no obvious indicators to measure accurately if you are ready to take up this role, but your willingness, ability to learn, adapt and grow will make you better at it over the journey. Characteristics of a good mentor. We have utilized results of various formal interviews and informal chats with open source mentors and contributors and some research studies on this topic to highlight the factors that they think are important in a mentor. Sharing these pointers is an attempt to nurture the precise mindset. So here is an exhaustive list of expected characteristics of a mentor. This is curated from the overlap between characteristics that mentors think are important in a mentor versus what mentees look for in their mentor. This list can be used as the foundational groundwork, which I would like to present to all of you for your consideration. Every mentee will appreciate the qualities like trust and respect in your interactions, honesty in your feedback, commitment to finishing up the contribution goal that you have agreed and so on. Now let's see some rudiments of open source mentorship. Open source contributions are often driven by a geographically dispersed volunteering network. It's highly collaborative yet decentralized nature means there are a lot of unknowns for the contributor. Open source mentorship is distinct from more generalized tech mentorships. The communities are very complex where the contributors are often volunteering their time across different geographies. As a result, mentoring in collaborative open source communities comes with an altogether different and diverse set of challenges. The success factors that make mentoring relationships most effective are similar values, demographic proximity, trust and respect. There are many examples where mentoring sessions flourish thanks to human factors, effect detection and metacognitive support helping lead to lifelong connections being formed between the mentor and mentee. Still I suggest once in a while we should deliberately mentor someone across social and demographic lines putting in simplest words someone who is not like us. It helps develop emotional intelligence. Be sure to do this only after you understand the dynamics of mentorship more comfortably. Official versus unofficial rules of a mentor. One can mentor as part of some formal programs like GSOC, Rails Girls Summer of Code, Outreach, etc. These programs have different goals and different structures. Some of these programs are related and limited to college students only but some open their doors to anyone who wants to contribute. Others like Outreach support diversity while there are some like European Space Agency Summer of Code in Space promotes space-related open source software. Some pay the participants while others don't and then there's Digital Oceans Hector Buffest, a month-long event pretty much like a festival to encourage contributors of all skill levels to donate their time to support open source projects with many often making their very first contributions and submitting their very first VRs. So one can mentor as part of these formal programs all of which has defined structure and defined goal and defined period or one can volunteer to be a mentor in projects they are active in and help potentially any contributor who is interested. In the latter you have flexibility to drive it in a way that suits best for you and your mentee. Barriers and mitigations there are various hurdles related to technical, social and personal barriers that might come in the way and as a mentor you will need to learn how to mitigate or overcome them in order to be a successful open source mentor. Let's discuss this in the do's and don'ts format. Starting with the do's. Having an end goal set before diving deeper into anything is something that I have seen works for most people. It reduces the ambiguity and saves time rather than wondering every time about what's next. Planning with priority, time constraint and purpose as the considerations has always been an integral part of making an individual successful. The second is initially at the very start of it the mentee will be full of energy and excitement and it's important to channelize that energy and excitement in the right way and in the right direction. So recommend a doable good first task for them to start with. It will add up the sense of accomplishment and make them eager for the next task. The first task should be based on their level of expertise. Keep in mind they are unaware of the complexities of the task in general. Have empathy while setting up the expectations. Try to know about their backgrounds and their commitment to this. But still there will be some or the other factors which are unknown and might be affecting their pace. Also regarding a particular task they may not be conveying the issue accurately. I used to face problems when sharing technical issues with my mentor during the initial period due to the lack of the right technical vocabulary to express it. Then be generous and credible over time you will get questions that you don't have exact answers for which is okay. In that case point them to resources or introduce them to someone else or someone who can better answer the question rather than you filling up the space with incorrect information. So always be credible. Then comes the feedback. That's an important ingredient in this whole mentoring relationship. Handle it well. Your mentee will treasure the feedback, the appreciation and suggestions for improvement highly. Also do not miss receiving it for yourself. Reflect on the feedback that you receive and it will make you better in future. Moving on to the don'ts. First and foremost is confidentiality. It is non-negotiable. Never share the details of the interactions with your mentee in any form. You may not know how it may affect them if they are not ready for it. Be cautious even if you are thinking of sharing it without revealing the identity of the mentee. So always respect confidentiality. Next is do not make decisions on behalf of them. You can provide examples, suggestions, but leave the decision making to them. Especially in the case of students I have seen they will take your suggestion as the standard solution without even questioning it. That way they won't develop the skill of analyzing the options and deciding the best suitable one for the case at hand. Then do not judge or make assumptions. It is very easy to fall into this trap when you don't know things in their entirety. Along with that from time to time challenge your bias. It's hard to get rid of it completely because it is implicit. However, always try your best to base your suggestions and assessments on the information that is provided to you. Be cautious that the bias is not limiting your cognitive capability. Last is about the network and community engagement. Open source contributions opened up various avenues for me. A lot of my engineering career, the software engineering career is something I owe highly to open source and my mentors along the way. I am reached out for many opportunities which I am very grateful for because of the network that I was able to build up through numerous kinds of interactions with people from several kinds of professional backgrounds. As a mentor, you will be the go to person for any kind of issue for your mentee but encourage them to leverage the wonderful and diverse communities that makes open source what it is. Non-coding elements of open source contributions and mentorship. Submitting code patches is not the only way of contributing. So mentorship as well can be offered for these non-coding elements of open source. I am listing a few here. For example, your mentee can shadow you when you are reviewing a PR. It can be a valuable skill to know how to review a pull request, how the review is done when you have complete domain knowledge about a particular contribution versus when you don't and you are viewing just with technicalities in mind. Then UI, UX, documentation, translations, community management, testing, every contribution, every kind of contribution matters and every aspect can be polished with mentorship. Then if you have experience in organizing meetups, your guidance can be very helpful for someone who is arranging it for the first time. And last but not least is you can mentor your mentee to be a mentor that sounded quite like a tongue twister is in it. But yes, it's a skill that can be developed with some practice and guidance. A mentor is an important building block in creating an environment of diversity and inclusion. Just saying that diversity matters won't change much. It should show up through the actions and you will unknowingly act right if the values are ingrained in you deeply. Sometimes it is okay to say that specifically. However, if your words and actions contradict, it can be worse, leaving an impression beyond just unawareness about the topic, especially being a mentor, your conduct and everything about you unconsciously and even consciously imparts it to the mentee. So a mentor must be mindful of it. Small things can have larger impact. For example, trying to pronounce a name correctly, understanding the learning cultural nuances. If they are sharing something and the words and pronouns that you use while telling a story about a person or some event, all these things substantiates the values in the listener. A series of small things, such small things will make a profound impact. Stephanie Pace Marshall has beautifully expressed transformation in this quote. Adding wings to caterpillar does not create butterflies. It creates awkward and dysfunctional caterpillars. Butterflies are created through transformation. Dynamic mentorships will play a vital role in the global empowerment of underrepresented communities in STEM fields. And the same applies to open source is what I believe. Understanding the mentorship responsibility, the sensibility of the role and the people involved in it, being curious and open to new perspectives and embracing each one's point of view and ideas, all these taken together one step at a time will surely lead us to a better state than the one that we are currently in. So we saw the benefits of mentorship to open source ecosystem and how we can transform communities by becoming precise mentors. Then we looked up why one should consider to be a mentor and what are the characteristics of a good mentor. Further, we saw the basics of open source mentorships and the barriers that would come along the way, how to mitigate those and mentoring for non-core elements of open source contributions. Finally, we emphasized the creation of inclusive spaces in open source through mentorship. I hope this has provided you with insights into how mentorship can shape the future of open source, how you can become a mentor and what does this role entails in terms of benefits, struggles and impact. In a nutshell, a role of a mentor can be difficult and can feel like a burdening responsibility. Yet it is very fulfilling and empowering to see your mentees move from aspiration to realization. I'll leave you all with that note. Thank you very much for joining.