 Thank you for speaking around after lunch. It's very rare to see a crowd after t-shirts have been given and food has been distributed. So it's a real pleasure, and I think it's a testament to what a successful day this is. We're now going to kick off a panel of what I deem an interesting kind. So we put this panel together with the intent of explaining to a lot of folks what the contributor experience is like. And we wanted to do it through a couple of lenses. So one of the things was to focus on people who have experience contributing to open source through their organizations. Experienced people, people who are new in the workforce, so new talent. And we also wanted to do a panel in response to some of the comments that we've seen in earlier sessions in the focus areas and the spotlight that was shined on the number of contributors in India rising and also a large fraction of these contributors being women contributors. And so we put together an all women panel. Of course, I am the open source sort of moderator voice, so I guess we made an exception. But that's our panel today for you. In terms of introductions, the world has known many women to come forward and be leaders at times of crisis. We know of stories globally. We know of stories from home about queens coming forward and taking the reins at times of crisis for their kingdoms. And closer to home in the technology realm, a lot of the first programming languages were developed by a lady named Ada Lovelace. A lot of other technologies like spread spectrum technology came from women innovators. And so it's not very common to have women at the helm of technology. And I guess with this whole wave of containerization and Kubernetes and things like that, it's all the more apparent recently. And so welcome everybody to today's panel. I will shut my mouth for a while now and allow our esteemed panelists to introduce themselves. Priyanka, you want to go first? Hey, everyone. My name is Priyanka Sagu. I work at SUSE as a Kubernetes integration engineer. And I do a few things in upstream Kubernetes project as well. Currently, I am the release lead for Kubernetes 1.29 cycle. And we are planning to release it on December 13 after a bit of delay. I'm also the technical lead for special interest group contributor experience. I'm also a GitHub admin for Kubernetes and sub-project organizations. And thank you for inviting me to the panel. Amruta? Hey, everyone. I am Amruta. I am a product engineer at InfraCloud Technologies. What I usually do is write custom controllers for different Kubernetes resources and play around with Kubernetes in that way. Apart from that, I've been contributing to a few open source projects, especially in the data protection space and storage. Hi, Ika. Yeah, hi, everyone. First of all, thanks a lot, Ram, for inviting me to this panel. And I'm Faiqan Sari. I'm currently a third year undergraduate student. I'm graduating in 2024. And I am a contributor to Kubernetes, apart from which I am a part of the release V1.29 of Kubernetes. I'm also a CNCF intern at Istio. And I am also one of the contributors for ETCD. And I contribute in various areas of Kubernetes, from being one of the summit staff lead for Kubernetes contributor summit to also being one of the maintainers for last week in Kubernetes development publications. So yeah, there are several areas that I contribute into Kubernetes. So as you can tell, there's people from different areas of contributions and things like that. And what I'd love to do for the next 20 odd minutes is dig into various aspects of what the contributor experience is like, what it has been like for you individually, and finally end with some takeaways for the folks that are here about how to get on board as a contributor in future. So Priyanka, talk to us a little bit about what exactly it means to be part of the Kubernetes 1.29 release in the capacity that you're in. So again, I'm the release lead for Kubernetes 129. But before I say anything else, nothing is possible in any release cycle without the amazing release team we have. So I have a team of 40 people, which in my capacity, I lead them. And apart from those 40 people, we have thousands and thousands of contributors who actually work on the actual release. So great shout out to every one of them. What I do is make sure we release on time or make sure we hit all the milestones. And this is my first time being in a leadership position of this kind, where I'm doing both project management and people management role. So that's what I do in my role. So when you say you have a team of 40, is this a team of 40 in SUSE that you manage, or is this like a Kubernetes? When I say I'm a Kubernetes release lead, that means the Kubernetes upstream release. So what do people, one of them is already on the stage, one of them is in the audience. I think I have a few more here. So 40 people are from around the globe. The team is divided into me as a release lead. I have four lead shadows. One of them was supposed to be a member of this panel as well. I have five role leads who in turn have shadows under them. So that's how we make this 40 people team. And all are from different parts of Kubernetes project itself. So Fahika, you want to add your perspective to this process? Yeah, definitely. So basically, like Priyanka is a release lead for the program that we are talking about. And my perspective to this is that this is a program which is your go-to point if you are looking forward to become a part of Kubernetes and looking for mentorship to contribute into Kubernetes. Since release shadow program is an itself a program that is made in order to let new contributors come in and learn the process of contributing. So like Priyanka is a lead, she also have been a shadow at some point like I am. And that is how you climb the ladder to becoming a core part of the Kubernetes releases. And so is there something specific that you contribute to the release process? Yeah, so Kubernetes release, there are several areas. I contributed to the nodes areas that is creating release nodes. But that's not the only area that we focus on. Since every release has lots of responsibility from doing code, release nodes, managing enhancements, and managing the communication between these different teams. So all of these areas comes up with their own responsibility. And there are mentors in all these areas and their mentees. These mentees are basically the shadows who work for the team. And the mentors guide them also to work towards a successful release. Speaking of consuming the work that you do, Amrita, you consume Kubernetes releases. But you also have contributions to your name. But to other projects, could you explain a little bit about what areas do you work on and what contributions do you? So I have been contributing to projects that are related to data protection. One of them is Canister. I've given a few talks on that as well. So it's a backup and restore solution for Kubernetes resources. So we deal with writing custom resources in Kubernetes, write controllers around it, how to do backup of these resources, and restore it. So we started off with a team of a couple of engineers which built it at the starting firm. They were one of the few engineers who started contributing to that project. And then later on, it's a big project that recently turned into a CNCF Sandbox project. So that is one of it. Other projects that I have contributed in my early stages of when I was onboarded to Kubernetes was Open Policy Agent, which is in security area for Kubernetes. So we write rego policies, which is a different language, again, to write different types of security policies on the different Kubernetes resources. So I contributed there as well. I played around with it first, that how it works and how I can try to find out issues over there. And then once I kind of hold off what it does, I look for some issues to start contributing to it, and then I picked up. So in terms of contributions itself, I'm sure that there's a lot of people who come forward, who start, but sort of fall off suddenly. And I'm not saying there's some magic special secret source somewhere, or it could be just personal hard work and dedication levels that you have. But could you share a little insight about what it is that helped you sustain, I mean helped you start and sustain as a contributor? And I'll start with you, Priyanka. So I also have my failure story. I started with Kubernetes. I think in 2020, late, I tried, did not work out, and I went back to whatever I was doing that time, because it was very overwhelming. I think it was a time when I was working on the project with people who were contributing to Kubernetes in all different capacities, like node, storage. And I, as a consumer of Kubernetes at that point of time, could not understand how storage worked outside of Kubernetes cluster. For me, it was a black box. This is a Kubernetes cluster, and that's it. I don't know how to take out node and work on it separately or storage. So when all these people used to talk about all these things in the room where I was sitting, well, it was extremely overwhelming, and I just gave up that time. But I realized that it's not just Kubernetes project, any open source project of this size. There is always a learning curve, and when you realize that is there, I think that's an enlightening moment. You know that it's not going to work out in day one or week one, or maybe month one as well, but spending that time is actually one of the requirements. You have to do some hard homework to even start reaching out to people in the project on what do you exactly want out of them. So that's what I did after six months. I think what helped me to come back to the Kubernetes project was my job. I switched to a company which was working more closer on Kubernetes kind of flavor of code. I would read those code, and then I came back to the project. I think, and I would give a shout out to Dems. I went to him and I shared my interest, okay, I have worked on this, this, this thing. Do you think I can help you in some way? That was good. So I gave him exactly what I knew at that point of time, and he had some problems that he wanted help on, and I picked those things, and that's how I started. I can give another example. I was, I think one of the few things, first few things I did in Kubernetes project was contributing to the Python Kubernetes client. I joined one of their meeting for the very first time. I introduced myself as somebody who is sitting there trying to learn what the group is talking about, and I'm like, okay, I can pick up some beginner issue, and they gave me one issue which I could not understand, even though they had marked it as easy to understand or beginners. Okay, what I did, I think, I started looking at the documentation of the project and the examples they have in their repo. I started playing around what is working, what is not working, and I myself in that process realized there is so many other things that are not working, maybe I can start from there. So I took like a back turn, maybe a few steps back, just did minor documentation updates, minor example fixes of usage of Python client, and then went back to maybe retrying what I was actually assigned in the first place, and that's how I started. So there's always a learning curve to anything we are starting new with. Realizing that is the first thing that I would maybe share with anyone, just give some time. It is, if it is hard, or if it is looking like hard, actually maybe, not maybe, most times that is the case that it is hard. So, and that is hard for everyone, not just for that one person. So just understanding the technical perspective, for some people it might be like maybe few weeks, for some it might be a month, you have to understand the background from where they are coming. We really can't compare ourselves with people in the same room, because somebody maybe they are working on so many other things that right away helps them to get started with this other new project. So it really matters the background from where you are coming from, and also doing some homework before reaching out to people, because it helps you to narrow down your questions, what exactly you are looking for. One of the things I as a person who have spent some time in the Kubernetes project, I see people reach out to me with questions like, I want to start with Kubernetes project, can you help me? I really want to help them, but honestly speaking I don't know what are they really looking for. So it ends up being my work to actually talk to them and narrow down the scope of what exactly they are looking for, or sometimes it ends up me putting my opinions on them. So I really don't want to do that, most times I want people to find out what do they really want, because sometimes if I am working on something, maybe they do not like it, and they ask the blanket question and I really pointed them to that side and that was not the thing for them. So it's okay to try error and fail, but yeah, just doing some homework helps to narrow down those questions, and then you can reach out to anyone for help. Open source projects is the places where you will definitely find out these helps in many different ways. There's a lot to unpack in that answer. I'll come back to you about some specific questions. If you don't mind me interrupting. Amrita, do you want to share your first contribution story as well? Yeah. So when I started off, I had around six years of experience in different domain. So when I started off in Kubernetes, I was already, I already had a mindset, I already had an expertise in different domain. So to shift that mindset to how Kubernetes works. So when I started off Kubernetes, okay, I have to learn Cloud. Okay, then what do I have to learn more? Okay, I have to learn Docker. So it was like starting from scratch, like I'm a, like fresh out of college that I have to start on the things. So that was a difficult, I would say transition, that initially, okay, I need to start learning and there are younger people than me who know more about it. So that was a different, you can say fear, okay, they know more. I need to study, I need to be at a pace that I can converse with them as well. So I initially struggled, but later on when I got hold of things, when I started things, then yeah, I was a bit confident over there. Fika, your first contribution story might be somewhat different from theirs. Could you share that with us, please? Yeah, unlike Priyanka and Amrita, I started as a student. That was the most fun part of it because I was not liable to contribute to Kubernetes. I was not asked by my employers that you need to learn Kubernetes or anything. It was just a fun thing because I've already been a part of a lot of upstream community programs and initiatives like GitHub Campus Export, which are pretty exclusive. So I was a part of similar programs and that is where I knew the importance of contributing to open source and the visibility that it gets to you. So I always wanted to contribute to open source but starting into an open source project which took years to build is super overwhelming and for students though it is more overwhelming and anyone can sense that. So I started particularly, I had a lot of noise about Kubernetes and so I just started with a simple SIG which did not require a lot of technical skills. That was how I started. Now anyone when someone comes to me and asks how to contribute to Kubernetes, that is the answer that I give. Nobody has already figured it out or anything. You start doing things and that is how you figure out stuff. So in my case as well, I started contributing to non-technical aspects of thing that not like localization or anything, it was simply documentations and also contributing to the meetings. When people are discussing something, put your views in it. Ask people what is happening, simply ask them out. So that is what I used to do. I used to join regular calls at Contributor, Experience, Com, Steam and I used to take up the issues and areas that I know I can work or at least I can ask them or even if I think it is a little difficult for me to figure out, I know I will figure out a way by asking them. So that is how I was a little confident in myself that even if I'm giving a challenge, I'll take it up. So that was the confidence I held in myself. As a woman, if you speak, contributing to an area where there are lots of people and generally you see women in tech is a little low, the number is a little low. So that is one thing even I was having when I was contributing to kites but I had to keep my voice held high so that I am heard. That was one thing I always kept in my mind and I'm not below anyone. Even though I am a beginner, everyone was a beginner at some point. So that's how I started with kites. I started contributing to the weekly meetings. I joined the Slack channel. I used to read all the chats. I used to read all the documentation. I used to read a lot. So if you want to get started with contributing, read a lot, get a habit of reading. Read the Slack chat, read the keynotes from the meetings. So every open source project have their own weekly meetings decided. So all these weekly meetings have their own documents as well that they maintain, like weekly meeting notes. You just go through those notes, read what discussions are happening in these notes and if you find some area which is very confusing, ask that to one of the sub-project lead or something. That's what I did. So I went into those things. I read a lot of weekly meeting notes. I read the Slack chats. I read what the GitHub read me issues. Like Kubernetes, the best part of Kubernetes is the documentation. This is also one thing I highlighted at KubeCon Talk that though Kubernetes is overwhelming, but it has the best documentation any open source project can ever have. So documentation, reading the documents on GitHub of Kubernetes 6 is very important. So just go on GitHub, check Kubernetes, GitHub organization, read the documentation. You'll also figure out that it is very simple to contribute. But reading is important. You can't just go to someone on DM and say how to contribute. Don't do that. First, read yourself. Figure out a thing. If something is very, very specific, then you can definitely put it out to DMs. And if a question is good, you will definitely get your answer. But that's what happened with me. I got my answers after I figured out things. And that's how I became a regular contributor. Wonderful. So in everybody's contributor story, there's a lot of work done through self-initiative. Is there also a mentorship or a sponsorship angle to your story? Is there somebody who really helped you along this path, either at the beginning or in the middle or throughout, et cetera? Would you like to highlight some of that? It's very lucky if you find a mentor in the very initial phase, like someone who just gives you the path. But in general, if I say you find mentors, in my case, I found a mentor after becoming a very core part of the team. I contributed and that is where my mentors realized, oh, this is the person I should guide because I know this person is going very high. And that's how I found my mentor. So that was not a mentor initially, but with time, I did find lots of mentors who are so ready to guide me. And what kind of difference did that make to your contributor? Yeah, so when I have a mentor, now I am taking more structured approach to what I'm doing. Initially, things were not very clear for me. I was contributing to almost all the projects or all the issues that I came along with. I'm like, okay, I'll take up this, I'll take up this, I'll take up everything that I can do. She didn't a candy store. Yeah. But now I'm like, no, I'll only take up the, I'll only contribute in areas which I know I'm going to contribute to the larger aspects as well in the future. So now I pick up things which I know is going to help me and that is how mentors help me. That's nice. Priyanka, I know you've expressed a lot of interest in this topic too and you alluded to some mentorship experience before in your answer. Can you speak to that please? I, well yes, I had a lot of mentors along my journey and I actually want to add a bit, one more step to it, mentors and sponsors. So like FICA said, when you get mentors, they can help you structure, provide you a structured path to what you really, or maybe they can show you path and you can do whatever you want to do with that mentorship. I had mentors, I think very early on, I have a mentor sitting in the audience who have helped me even before. I was part of Kubernetes project before, I was part of any open source project and thank you, Maru, Jason, for that. What actually helped me beyond mentorship was sponsorship. So when people mentor, that's good, they are mentoring you, they are giving you guidelines to this, to that, and they are also giving you opportunities, but when people sponsor you, like when people vouch for you, when there is a requirement, vouch for you where you can grow, I think that is also a very big requirement and that happens a lot in Kubernetes project nowadays, especially in India. I don't know if Nikita is here, but Nikita Raghunath, I'm talking about one of the ex-staring person, current TOC, she has been a sponsor to me in many stages of my journey at Kubernetes. Which helped me to take a lot of leadership position. So I was working, I was contributing on a lot of things, like any other contributor, but she actually looked at that work and she vouched for me where there were opportunities to lead as well, where I can pass that on. So as a mentor, she also opened the path for me to pay it forward as a lead, as a person who has this capability or this platform where I can share what I have learned. So mentorship and sponsorship work like very much hand in hand. Priyanka, can you help us make the distinction a little more clear as to what exactly you mean by mentorship and what exactly you mean by sponsorship? Mentorship could mean one-on-one, like I am talking to you right now and I can give you like a documentation, follow this, but if, when sponsorship enters, that means when you are sitting with somebody else and now you know that is this opportunity opening up, I can vouch for them or I can sponsor them. That's where like sponsorship comes in the picture. So if, for example, let's say Fika is a lead somewhere and she knows she has to maybe take on two more people under her who could be next leads. So if she knows I have been working with her or she knows somebody who has been working with her and she wants to now sponsor them and take her role, that's sponsorship. So mentorship is important and sponsorship is important, but if they are together both in the same place, I think that works wonders. Got it. Amrita, I'm going to take a slightly different approach in your case in that from your story, I heard that there's a different kind of balance that you had to strike between work that you were doing and starting on open source stuff. So what was that like? Can you share that with the audience? Yeah. So when I started off contributing to open source, I didn't know that it is going to take more time than the working hours, but later on, after a couple of weeks, I realized that okay, I'm not able to contribute to it much even though I am a lot interested because of project work, then then there was a push from my side that okay, I need to work overtime, I need to maybe, if I'm interested, I'm passionate about it, I have to contribute on the weekends as well. So that is how I prepared my mind that okay, I have to give more hours if I want to do both of the tasks together, which one of them is of course, you're going to get recognition and a different type of profile that you're going to build and others, of course, your project work. Also, the organization I'm working is all supportive. They always encourage people to contribute to open source. So there's a lot of support from them as well. So yeah, that is how I feel. Nice. Again, I'm going to switch tracks once more and now I'd love to focus on some actionable answers and insights for the audience. Now there might be people who are very experienced with certain projects. There might be people who are just starting out fresh out of college and there might be students watching this or in the audience or who might have questions about how to get started becoming an open source contributor. So any word of advice about here's a way to get started based on your experience and based on the context that you have. I'll start with you Priyanka. So there are projects which offer structured mentorship or structured paths for on-boarding. I would not say Kubernetes is the best test there. But we have... So we have things to say on Cube Day, India, but okay. Yeah, like I am part of Contributex and that particular sake is responsible for improving the contributor experience and we take feedback whenever somebody comes to us. For example, I think two days back only I read this comment somewhere. We have this onboarding course, a text-based onboarding course on kubernetes.io and somebody gave a feedback. Yes, this was not helpful because they were looking for something specific and now we know that part is missing. So what I want to say is look, if there are structured onboarding process, look for those. Those are always the best opportunities. If somebody's in the audience is looking to start with Kubernetes, yes, we have a lot of mentorship opportunities. Even I actually become a technical leader as part of one of the mentorship cohorts. There was a mentorship cohort for SIG Contributex leads. I think there is a mentorship cohort for other projects like being reviewers for that project, being maintainers for that project. We have entire SIG, which is very much focused on documentation. They have different roles where they invite or they welcome a lot of people who can help them triage issues. So our SIG Contributex, sorry, SIG documentation repositories, they have issues like 700 open issues at this time. So we need help to triage them. We need help from people to actually add labels so that somebody who is interested can come and see them. So those kind of roles, named roles, named mentorship opportunities, if you find them, best way to get started with them. Another thing, like if you already have figured out this is one part of the project that you want to start with, the best thing you can do is look for the documentation. There is always a documentation. Maybe it's not the best piece of documentation and you can right away start with contributing to the documentation itself. For example, you are looking for something specific. I think your first contribution could be go back to the channel and tell them, oh, this piece is missing, and maybe create an issue or maybe create a PR right away, add that information. So look for documentation, go through those follow and try to understand the process, like Fika said, get involved, start involving talk. Maybe if I was one of the people who, when I started joining these meetings, I had nothing to contribute back. Like the people were talking about all these big things that I was not able to understand. Maybe that's okay, still okay. If you can't contribute anything, just join, sit in those meetings, be a silent listener. That is also part of your learning process, but don't leave it at that, start talking. When, if you are not okay talking, maybe we are talking about meetings, like Zoom meetings or this virtual meetings, turn off your camera. Say hello, just introduce yourself so that people know. Why are you there? And tell them in maybe one or two lines, this is what you are looking out. Why are you sitting there? Maybe you are just sitting there to understand anything about this thing. So when they actually know that this is why you are sitting in that room, and if they come across those opportunities, they will give you those opportunities. So I think just osmosis is also a very big thing. Being surrounding yourself with the people where you want to be in at some point, or surrounding yourself with the processes or project that you want to contribute to, I think that is also a big learning in itself. You will start, if not the exact thing that you are trying to do right away, maybe you will start grasping terminologies, maybe you will start grasping processes that people follow to do a certain thing, and you will have, definitely you will have some questions to ask and ask them. So yeah, getting involved, making use of the structured programs, if there are any documentation reading, Fika. Yeah, Fika, I'm going to throw this question to you with a slightly different flavor. Any word of advice on doing non-tech contributions? And what's a good way to get started on that? Because I believe open source contributions do not necessarily have to be about code only. And so anything that you can quickly share about that area. Yeah, every contribution in open source is huge. We've seen people like Divya Mohan who is particularly contributing to the non-technical side of things, but still leading so many aspects and so many people know about her. So talking about how to start with non-technical contributions, any of us can do, even people who are in the first year of their college can start with it. So if you want to begin with it, it's very simple, I guess, just join a Slack chat and Contributor Experience is particularly a channel in Kubernetes, and several other projects have similar channels where you can contribute into. Documentation is one of the way to contribute non-technically. Plus there are also programs like Kubernetes Contributor Summit or B8 Community Initiatives, these are the programs and ways in which you can contribute to the non-code expects to things. And in release teams, particularly we have is enhancements, communications, and release nodes which are a little non-technical aspects of things. They do involve a little bit tech, but it's not very technical. So any folk can just come and contribute. Amrita, your take on advice for people who want to get started. Yeah. So there are different programs as well, which is one of them is Outreachy, if you know about it. It is more specifically for underrepresented people. So if someone can go and ask for a mentorship over there, people can just, they look out for your story and how passionate you are, and you can start contributing to open source over there and also it's paid. So that's also a good thing over there. Apart from that, of course, you have to first figure out what area or expertise do you want to get into in any open source project. Okay, I want to target this area. I have interest in this area. Look out for projects in that area for open source. Start with small issues or just playing around with that project and then you can get started. Awesome. I'm going to end right now with a bunch of different people that I want to thank. So first of all, thank you Divya Mohan. Hopefully you watch this recording. She helped put this panel together and identify these wonderful speakers. Thank you Nikita and Dimms. It's impossible to have a conversation about contributors and contributor experience without having your names come up. So if you do watch this, we're all rooting for you. Thanks for all the awesome work that you've done. Big thanks to the CNCF and the Linux Foundation for their focus on diversity and inclusion. A lot of this is possible, especially the focus on underrepresented groups and things like that. It's phenomenal the amount of work that they're doing and the amount of focus that they do. I work with them personally on a lot of different events and things and I know the kind of focus that they bring into all this. Thank you all for taking the time to come here and share all of these insights and thank you all for listening to us. I hope you have a great day. Thank you.