 and welcome everyone both on YouTube and here on Zoom for joining us today, it's Thursday evening thanks for making time for this. So how this sort of like a bit of pretext on how this meetup came to be is that like all three of us like me you know Ashwin and Nabaran we keep meeting each other across different meetups and you know different you know small scenarios of conferences and stuff and we have this really good banter over you know like a cup of coffee and something and a lot of valuable lessons are you know a lot of valuable concepts are discussed on those conversations and we had this idea we were discussing something like this and we have decided that why don't we sort of formalize this and why don't we make it easy for practitioners to reach out to contributors and you know like reduce the barrier make it seem like a very next-door thing to be done right and Nabaran was gladly on board on probably my first pitch to him about doing this and here we are sort of so I get this to be a short intro about myself I am Joy slash Ashfa I have been practicing DevOps across various organizations in Bangalore namely you know Rezapay, Zoomcard, Hotstar to name a few and I've been on practicing on Kubernetes for the better part of the last five years and that's why I keep you know running into contributors often when I you know there's an issue and I try to help the community in my own possible way and now to introduce my co-host Ashwin, Ashwin has been a mentor to me for again like the last three four years I have walked with him across another organization Zoomcard and I think over and out to you Ashwin if you could just give us a brief intro about yourself. Hey everyone thanks for joining in so I'm Ashwin I'm Cruz Maniac on the internet I work as the infrastructure lead at Balu we make chatbots and so Kubernetes is something as part of my infra game something that we've been working with for quite a while and well welcome Navarune so let's you know instead of wasting any more time give the floor to the man and can you talk about yourself or say hi to everyone. So hi everyone first of all thanks to Hasgeek and Zainab, Joy, Ashwin to have actually thought about this and pulling it off when Joy actually asked me about this that hey we are trying to do something like this I was like we needed this for some time and this is a nice initiative and it was it was not a question to be answered actually it was a answer by itself that yes but contributors would need to do this there needs to be some something done from both sides to this the guy about myself I work as an infrastructure engineer at Clarissites we are I work out of Mangalore right now and so there's a interesting bit of how I got to know Joy and Ashwin but I guess I would delegate it to them later on so yeah so Navarune's workplace Clarissites used to organize this meetup pre-covid of course called failure moods where a bunch of us practitioners would basically gather together and discussed about how badly our systems feel right and we would basically share the worst nightmarish stories about infras that we had encountered and that we have personally lived through and there was so much so much to learn about that and I remember having a great post meetup conversation like we wouldn't imagine the number of ways like and we would but really it's so interesting to think about the number of ways we can burn down intro in so many interesting possible ways right so yeah I mean we had a number and I then had a very very nice conversation post factor you know after the meetup about how the Kubernetes community has grown in the last couple of years what we can actually sort of do to bring it closer down to earth and make sure that you know the community people are more reachable increase apac representation how do we get practitioners to also start contributing you know like we battle test Kubernetes day in day out but somehow we do not most of us do not leap into the contributor side of things and we were discussing and yeah that is how you know this one of the seeds of one of the seed ideas of what we are doing right now and like apart from that like let's let's talk about your experience how long you have been practicing Kubernetes other than contributing so I have been practicing Kubernetes for around two years now probably started during Kubernetes one dot one zero we were just trying out one of the hosted providers and waiting if Kubernetes is the right solution to our workloads so that started my journey of using Kubernetes and I started contributing fairly recently compared to the community I started around one and a half years ago starting with the Python plant but we'll come to that later so I so I you started out as a practitioner but how did you like by what how much time did it take you to grow into a contributor like what is the well so you have to decide where do you start contributing and why do you start contributing so being a Python engineer since the start of my career I've been writing by the last five years probably now and so that one piece I thought that I should contribute to because I'm using it the Kubernetes Python plant in a small project of ours so that's where I started out that hey I saw some why is this why is this done this way planted we done in a better way so that's how a contributor journey may start so this is just my situation there and after that I so Kubernetes community is very welcoming to anyone who is like forthcoming to say hi I want to take up some roles so I started with the release team shadow program and the contributor experience special interest group probably going to a bit of detail later on in the session about the shadow programs and the various mental initiatives I think I think we should we should have that hook on Chris that how did you end up how do you know Chris two because I we talked about how we got to you know talk about the tough how what did you and Chris talk about how did you folks who's do you want to go ahead now in the floor is yours now please please you have explained that so bunch of bunch of things right but the common denominator turned out to be the huge detail conversation about which switches to use and which key caps to use on the mechanical keyboards and it turns out both of us wanted to study mechanical keyboard to vent out frustrations you know so to speak yeah very much keep bonding going on there you want to go you know why isn't you detail deploying right what happened to my part why is there a crash loop and then you need a keyboard to vent that out you can't do that on a MacBook Pro very true very true in my case I think that sorry for the plug yeah so moving on let's actually get to the actual conversations yeah I mean go ahead never so let's talk about what are you what are you currently up to with the given it is ecosystem as a contributor where are you where are your guns train what are you contributing in so depending on what the action that I need to take I have like several hats that I can wear at times so in the last really cycle I was the enhancements team lead so this is basically a sub team of the Kubernetes release team itself and this is a rolling team which goes on and this really cycle I am shadowing for the release lead itself on top of that I help in maintaining the Kubernetes Python client and help out contributed experience sick in a few roles like putting out more activities in the app act region or how do you think about increasing contributions in the app act region so that's all I've been doing in the I think I there was one our priority submitted community question that you come from along Python background right from your colleges right like you've been part of the icon also right so what's the state of you know the Python client when you compare this to the go client as of now so there are several client standards bronze silver and stick gold so depending depending on those years you actually have to incorporate features right now the Python client is in a state where you can do majority of the API calls you can watch for resources right now there is an active PR on some someone is actually we are patching in support for port forward through the Python client so the Python client is certainly a bit less feature what is a feature proof like it does not have many features as compared to the go client but we are constantly working on like increasing the coverage of features that you can do with the go plant great and I think the reason I asked this question is that a lot of current practitioners in DevOps their familiarity with Python is they have a strong familiarity with Python and this way pops up in my multiple conversations is that can I can I do the same level of coding on top of the Python client as someone can do on top of the go plant now I'm a go for myself but I'm a converted go for I mean you we go for but yeah it's good to know cool I think so never like you know like give us a bit of idea of you know you did you work for a subpart of the enhancement stream called the release team right and just as an introduction to the folks here who haven't looked into how the communities community is structured there are multiple special interest groups and they each have their own responsibilities so I think I'll yield the full float on up around here will you know like can you just walk us through how this whole community is structured because I think that's that's one of the very important points to get into the community to understand the topology right hmm so I'd like to share something to everyone I guess I'm sharing yes so this is this is part of our Kubernetes new contributor workshop slides this is what we explained to the new contributors I just shamelessly took it from there to show here so the whole project is divided into several kinds of groups you can see there is a thing called special interest groups so special interest groups are a cluster of people where who contribute who focus on a particular part of the project so they take something and then focus on that for example if you see the diagram you can see that there is sick apps so they focus on things like stateful sets from jobs you have auto scaling special interest group who take care of the auto scalers you have network who form a very crucial part of the pipeline specifically the C9 yes networking landscape going forward so there are instances where you need collaboration between the six so there are there is a thing called working group or work groups who actually which actually is a cross sick collaboration to achieve a certain project so if you see in the diagram you would see that there is a synth or there is work group LTS long-term solution so we the community is actually trying really hard to achieve that goal of maintaining a specific release for a longer period of time rather than what is the cadence right now and on top of that there are specific committees like code of conduct product security and steering who actually take some decisions as in take part in resolving conflicts or look after the project's governance right and lastly there are user groups who are actually entrusted with gathering information from the community or users for example we have a big data user and that's a particular sort of deployments who cater to that if you are doing ML on top of Kubernetes it goes all right right also the ML workloads are you know possible it's possible to run them correctly accurately on top of Kubernetes so goes for big data then you have Kafka Cassandra etc on those parts right so one question here you mentioned the difference between six and WGs now I was fortunate last year to be a very very small part of one of the six which was a very short-lived sick you know sick doc security we were helping with security documentation we did not achieve much because one of the reasons was that the WG concept back then did not exist right and there was a lot of the other thing to be done between the six security and the big dogs right to different sort of organization within organizations to different teams so how do you think about so I guess it's been there for something I I think it predates even before me getting started contributing to the project but these are basically ideas where let's say testing and release need to collaborate on something testing and release are specific special interest groups who actually focus on specific parts of the project but then there may be something where you require collaborative efforts obviously you can have a collaboration even without forming a working group but when there are like long-standing work let's say you need to manage the infrastructure of the Kubernetes domains you have kts.io you have several services running your code search you have several other redirect services running those are all handled by the world groups right so that's where the concept came in so now that you've shown us an overview of the screen this actually is going to end up confusing a lot of other you know the people here right so what would be a few areas where you know new contributors would start heading out so is there a place is there a SIG or a working group where we say you know what easy entry can we get in lower barrier to being able to contribute do we have data around that so we don't have metrics around it as in like which is easy or which is not but there are several mentoring programs being run by special interest groups or work groups or specific part of the project which actually mentor folks into getting started in the project so those are the best possible aspects where someone can join so can you name a few SIGs that would have mentorship I mean I think I think I can note that down and have have that pass to you know folks that are listening because in addition to the creeping required edits it also makes sense to have links that people can look up to and directly start reading up yeah yeah so the most prominent one is so there is a mentoring sub-project of the special interest group contributor experience they have some initiatives inside themselves like there are some community initiatives from their side as well as if you see specific parts of the project where you can get some mentorship is one one thing which comes to my mind readily is the release team shadow program so you don't need to know anything to go to to go and contribute to the release team you can just file for a shadow role and so the only thing that you would need is intent and time so you need to be really enthusiastic about contributing to the project and have time to do that and yeah so these are all structured programs but all I would say is like if you if you are in UB and want to contribute to the project it's very like you can just go into the SIG meetings or just say hi on Slack say let's say you have a certain part so I would give you a pretty neat example here so when I started contributing to the Python client there was no program as such to get started that used to be a bio-clean meeting and I just hopped into the meeting and said that hey this is one field that I feel that can be an improvement can I own it can I own that patch nobody's told me no I just went ahead find a patch then people the the reviewers the approvers just came in and put in some reviews I so the cycle went on basically a patch when you file a patch what goes on and yes that's how I like started with a particular project right so so I think we will come to the detailed part of how it as a new you know first-time contributor how do you go about dropping the process of contributing to Kubernetes we will actually to our audience we will actually have a full section on that process where Navran would be you know answering very step-by-step question of how to go from being you know an outsider to an independent contributor to an odd member and so on and so forth but but let's get back to where where some part of community is like you know as I was talking like bunch of us here on the call also are practitioners you know I see some of my close friends like Akash is here a bunch of other people probably is here we are practitioners there was practice right and when we started a similar early times 1.1 x 2x those times of Kubernetes and initially things were sort of simple stateful set was on their pet set was there and so on and so forth right we had a couple of resources and kinds as the community and you know the ecosystem grew however we and we saw this in the growth of the CNC of landscape itself we saw the complexity of operating Kubernetes itself sort of pile up and so proportionately the complexity of contribution done and getting a patch done also because you know initially it was a skew proxy for network and the NIS came in right initially it was a simple stateful sets with volume mounts and CSI came in so the layers of instruction sort of just keep coming in do you think like well of course like Kubernetes solves a very very complex problem and is a complex piece of software but do you think for a new independent contributor this inherently poses a barrier? Yes I would not deny there is no barrier or there is no stop like there is no roadblock while contributing to Kubernetes there are roadblocks but you have to see it in taking the hats of both parts of the puzzle right so although like having no barriers makes it really easy to contribute but then having no barriers also increases the chance of spam so if let's say I'll tell you of a situation where if there are random PRs on the project and they do nothing maybe add a space or remove a space somewhere or add a new line the CI would get triggered if there are no barriers and that would exhaust resources but although there are ways to do it like it's not like every everyone who files a PR needs to have someone act their change so as to run it in the CI once you become an organization member of the Kubernetes GitHub organization then all of your PRs are basically they're tested by default. So I remember you mentioning this in a chat with me that initially it's an uphill task but as you like to grow into the role it becomes easier after the first few patches it sort of platters down the difficulty basically. You do have to take the lead by yourself. Yes so one thing in the last point was like the community is actually trying to make it seamless the process of contribution for a first-timer and then coming on to your question like when does it become a downhill task because initially it is a bit harder to start. Right. I would say like when you know the ecosystem well when you know how things work how does how does a review process work then it becomes more easier and then you can just go in and ask someone whoever is assigned to the issue that hey can you review this. Right so I mean a lot of lot of other open source projects do this to a level of good first issue. Is there any plan we know both that currently Kubernetes do not have the bandwidth to you know to be honestly mark both all the issues currently that are there and mark good first issues but is there a plan on you know in future release cycles and bugs that to you know start marking issues as good first issues is there a conversation around this. So hold on to the question that Joy asked is there a way you can have a good first issue on Kubernetes. Very very aptly asked. Is there a first issue because I would like to look at what's happening because my CNA is broken which basically takes me down about four years of engineering and about six seven books to understand what Kubernetes does. Well and I'm not yet. Then you have to look at the label itself right good first issue first is a first like it's an adjective right so it's very qualitative it also depends on who is actually seeing the issue or so let's say for someone who is setting up the Kubernetes project for the first time even even a trivial lint fix may be a good first issue but for someone who has built Kubernetes from scratch maybe you come in there right with the CNA issue so let's say if you have any problem with any specific component then you can probably build the software and actually see where the error comes up. So I know a couple of folks who are on this call right now who I have seen this when it is from scratch and the amount of resources and the number of hours they take to compile is insane. That was specifically the reason why I asked that question because first becomes absolutely relative from where you're looking at it and as far as Kubernetes the technology scope is concerned it becomes a very high pedestal to jump on. I think that is why it is also very I know like as a community we would ask for something like that but for maintainers it's also a very uphill and difficult task to actually figure out what to level as good first issue while I know folks who have said why this is not there and this is actually a good and clear explanation through this conversation that why Kubernetes it's difficult to have a good first issue list on Kubernetes because it's not a single piece of software it's a whole stack and it manages an insane amount of complexity to be honest. So one of the things that you discussed is that for you personally like getting to know the topology of getting to know the people around Kubernetes the mentors the contributors you know the maintainers of individual things this helps a lot right. So what's your opinion and how much does you know knowing the maintainer ecosystem So I would say it helps a lot. So it's basically if you see any open source project right what do you need to know when you contribute to a project any project as a matter of fact you need to know the code. Well I would not go that far but so if you if you see like one part is the code base the second part is the community who is actually maintaining the project right. So if you have an idea so let's say as Ashwin said he wants to contribute to CNI right he wants to file in a patch to CNI and we need to know who actually owns CNI because without that if you randomly ping people that hey can you review it it's not possible right you need to know who actually owns the code. So there the Kubernetes CI bot actually comes into a big role. So Kubernetes has something called owners and owners analysis. So if you file patch to a particular so it sees the chain set to particular codes and then matches to the owner's files and then assigns reviewers and approvers based on your patch. So in that sense the bots help you but then even after that you have to keep in mind that if not everyone is free all the time right they bandwidth may be limited for someone. So if you see that there are like there is probably less activity you can go ahead and ping in the SIG if someone else can come up and review your PR then that's also good right. So that's how I think you should tackle it. I think this is important that if you are going behind a bug if there is a bug or a patch that you it's a feature patch or whatever like which is affecting your day to day operations right. The owners is on the reporter to keep following up because in any community in any ecosystem it's not possible for everyone to be online all the time across all time zones right and your time zone would not you know align up with the maintenance time zone. So it's very very important to follow up and just to this end like I have some statistics from the Kubernetes repo itself and this is common knowledge between you know all three of us but the community should know about this that what happens when you don't follow up right. So as of now Kubernetes has this CI system of closing down old issues and it categorizes in three ways. One is first one is a stale issue and currently we have seen 155 open stale issues and 984 close which means all the reporters of those around thousand plus issues have forgotten to follow up and eventually the CI bot could not find any conversation and close the issue right and there is there is a significant number way significant number which has progressed to the next stage of staleness which is rotten that currently we have 108 open rotten issues and 6148 closed issues which went rotten which means which is a significant number if you think of the scale of Kubernetes and the number of bugs if if the reporters are followed up so many of those would have gotten taken up right and the community actually tries in figuring this out that which fits old issues to actually not close down by applying a flag called frozen right and we currently have 734 such frozen issues where reporters are not following up but community maintainers have figured out that this should not be closed down because it's P1 priority and they keep this open so we have 734 of that open and 291 which unfortunately you know got closed so Navran you have something to add there I guess right yes so if you see it's a big project and several parties own part of the code base parties here I mean by six or work groups or specific user user groups don't own code but it's six mostly who own code so if you see there can be different kinds of issues github issues so it can be a bug or it can be a product question basically how to use Kubernetes so there is a very good resource actually for this discuss.kubernetes.io I'll also put in the link so that is that is basically a chat forum where anyone can actually put in their questions and get them answered by the community so those those kinds of questions are actually not supposed to be put into the upstream repo upstream repo has so there also if and and there is one more caveat like if people don't put in a correct label as in which seek does it belong to so many of the six actually do triage they triage through the issues and see for themselves whether this issue is relevant to them or not this may go like unnoticed if there is no correct label so there are certain aspects it comes back to the our older topic is that to correctly even report an issue as a practical that I should know which component is one by which six so that when I file I go through the right process and also to get it even noticed by the right set of people right the right set of maintainers yeah so yeah I mean I'll yield the photo to Chris I think he has a couple of questions that he would like to ask you yeah so I have Zena we had a few audience questions you want to line them up so that Navarone can answer them and then we'll move on yeah absolutely that would be great actually yeah actually Sumanth has a question Sumanth why don't you unmute yourself ask the question also introduce yourself uh hey can you can you hear me yeah we can hear you okay hi I'm Sumanth and I'm a devops engineer and I work at Qualcomm so yeah my question was after like coming to the history I previously was working with PHP and Drupal it's a open source CMS and I used to do a lot of code contributions in that there are something called modules wherein the core part is the CMS and we used to contribute modules which are like extensions or something which adds the functionality so it was pretty easy to you know develop or do the contributions then I shifted to Python on Kubernetes now what happens is I mean Kubernetes most of the functionalities are inside Kubernetes I guess so when I tried to code right so I was asked to sign a you know sign a license or something whatever with the CNCNF or Linux foundation so then I stalled over there because I'm not sure what does that mean because the I don't understand what that mean like whatever the code I contribute right Sumanth just to answer so we will actually have a full section later on almost at the tail end of our conversation where as I said like you know Navran will actually walk us through the entire process which would mean what CLA is how did it evolve and will come to the licensing parts what all other things as a new contributor you must do in order to contribute your first patch you will walk us through that so I think just wait up for a bit I think that section will answer your questions but if it does not feel free to rephrase your question and ask it once again at the end of this is that okay yeah sure no problem thank you thanks man thanks for hanging out Zainab do you have another question from community do you have anything else no not really but I thought Sumanth's question was quite useful we will have a whole section on that we will talk about the whole process of how this how this the whole first patch actually happens right so yeah Chris I guess like over and out to you you know you have a couple of questions so Navran the next question is what are the different groups that you know contribute to Kubernetes you have you have organizations you have individual contributors people that are employed specifically by the Kubernetes ecosystem the project itself now while we have that we have students as well but my question as a practitioner right is why do we not see a huge bunch of DevOps people who are with the first level highest order consumers of Kubernetes not pushing back into the ecosystem saying you know what so I'd actually generalize the question a bit I would not say it's just the practitioners it's about anyone like I think the one of one of the better ways can be like why doesn't why doesn't anyone contribute to Kubernetes like first thing I would say like what is the what is your intent of contributing to Kubernetes so there are like different kinds of people that actually contribute some people actually want to drive a product some people want to fix bugs that they have encountered while using Kubernetes some people just go by the open source philosophy and they want to create a better project at like at the overall scale so I would say like while contributing you should take into consideration like how much time does a person wants to want to put into the project and what is the intent of contributing then there is a like it is a it is a specific thing I would say to any project who is like distributed worldwide Kubernetes is a very big very distributed very highly distributed project contributors from all around the world are there so there comes a problem time zones and time zones are hard and they can't be mitigated so you have personally laid once as distributed team in the past right in the last couple of months yes so so there I need to give you a very short context on what Jai is talking about so since I told earlier that I led the Kubernetes enhancements team for Kubernetes 1.19 so we have shadows in the team and the distribution was like that we had two folks from India including me there was one person from Central European time and there were two folks from the Pacific time so it so the enhancements team actually worked very async so one team so basically basically it's like Sun goes around right and then people wake up and they take care of the responsibilities no it's basically sre is 24 seven call center like yes this is the sun going around handing over of you know like responsibilities on an on-call well yeah why ate us a ton there you go now you're on well there are conferences these days where the conference is held while the sun is up so yeah so time zones are hard and that creates one of the big issues but most of the processes in the Kubernetes ecosystem are going async even the even we're trying to reduce meetings as much as possible and so there is a specific effort going on in the release team to make release team async and there has been like lots of brainstorming done by amazing people to actually make things more better for people who can't be be in the meetings where it's like night for them or not a suitable time for them let us practitioners know if that actually ever works it's it's it's all there out in the open like we have a mailing list you can just go into kubernetes-dev at the redgooglegroups.com i'm just typing that down yeah don't take me on the names i or it is kubernetes.io i'm very bad at remembering that i i just have it configured so there let's let's think that up after the future links on the AMF page after the fall most of the most of these decisions are actually communicated there so that people are cognizant of what is happening around so yeah so i think you mentioned like that the other enhancements team a lot of work is actually not coding but more which means strategy of issues and features product management work tracking progress of existing features their graduation criterias managing deadlines of the developers who have owned up to you know solving a particular issue or a feature and then reach out to them and talk like are you done like it's a constant feedback loop right but here is a question right like who decides on a grand level in a grand scheme of things who decides or what decides is that a process that says okay this is how a feature is going to make the cut for a certain release right how do you arrive at the division and what goes in for into a release and what does not so in the kubernetes world features are called caps or kubernetes enhancement proposals they're just similar to rfcs or python enhancement proposals right so there are two aspects to it so any sig who actually owns the code for that cap actually decide whether they want to make it part of this release cycle or not and the really there is a sub team in the release team which is the enhancements team who actually validate all those requirements of graduation whether the cap satisfy that a graduation criteria if they satisfy we have no problem so there are two parts to the puzzle here one who actually implements the feature the other team actually shepherds the whole process basically coordinates for the whole team for the whole project what thing goes into the uh right so at this point at this point we've got a few more questions regarding the release engineering process at kubernetes right and i'm just going to say that we'll park those questions because we'll have a dedicated AMA we're going to do one more in a lot more granular detail a lot of tech where you know where we talk about and most of it how kubernetes actually releases software right so we'll park those questions for that now coming back to our topic right our batter so all three of us we've got a bunch of extensive experience working with startups working you know deploying kubernetes in their high-speed ecosystems and we also a few minutes back talked about how the intent is needed to to be able to contribute into the ecosystem as a practitioner now as an indian startup as the indian startup ecosystem should we be thinking about incentivizing contributions to force kubernetes is one of the projects that you can talk of because the moment you say kubernetes there are going to be other libraries underneath which then evolve into the bigger force landscape right yes so i would say like this answer is probably something which holds true for all projects and not just kubernetes so when you see it open source contributions and the motivating factor of like contributing to a specific project what drives those factors there has to be value addition on both sides of the puzzle there has to be value addition on the project there has to be value addition on whoever is contributing to the project there has to be a value addition on part of the organization who is at who are actually driving the like what driving the people who are contributing to the project so there are several aspects to it and i would say like if you if i if i have to give an example in the kubernetes ecosystem so let's say there are some kinds of resources called crown jobs which basically schedule things but crown jobs are in beta for some time and have been for some time yeah has been for some time now issues issues so if if you are if you are an organization who use crown jobs like very widely why not just contribute back to the community make it a stable feature if there is any just talk to sick apps and just show up to the meetings and say that hey hi i want to work ahead with this can someone say what so go to the cap there is a cap for crown jobs so you go to the feature and then see what all is left and how does the graduation criteria pan out so yeah that's that's all on part of that motivation in addition to the take part i know nabbaran you spoke about the what people what all the stakeholders of that patch gets out of it but there is another aspect i would personally like to add is that getting your you know your team to contribute back to force also sets the cultural tone of the organization and the team itself and which is which invites a lot of great engineers back into your team it's like birds of a feather feather flock together right so once you start incentivizing that sort of contribution other contributors will be interested in joining your other people who would actually join your org so that they get an opportunity to learn be mentored by an existing contributor to osmosis learning or any other means direct mentoring and slowly grow into that sort of you know a role right and that incentivizes a lot of young folks also to join such an organization and i mean right yeah i mean nabbaran actually you want to talk about how your org is currently doing the current the same thing so we we use a lot of open source projects whenever we find something to patch and if the patch is trivial and we see that hey we have the bandwidth since we're a startup we usually like most of the times don't have the bandwidth to actually put in resources but when we can we do that so we try to patch things up to the upstream just a small example of how things are going i mean no patches i guess like because small as long as yeah keep trying it sets the whole cultural donality that hey we tried and i think it's also the bandwidth type of organization also right like in initial days of a seeded startup or early state startup right people are excited it's a small team coordination is tight and it's easy to you know pick up a patch and you know get it done but then as a meat that all your focus is on your own product and your own users and catering to their needs bugs and features and everything right but again as you grow into a much larger organization a lot of those people who grew out inside that you know grew up in that particular org to become seniors a lot of the bandwidth fees up because then now you have actually people who pick up daily stuff but you get the free bandwidth to contribute back on something that you have been using for the last four or five years right so it depends on the time and place of what stays that organization in also to incentivize you know uh contribution back so um yeah on on the topic of of contributions right what is the process involved with uh contributing to Kubernetes what is the uh you know give us a high level uh read on it i mean we don't have to dig into the nitty gritties like i like i mentioned a few minutes back we'll have a much more detailed technical discussion with the release engineering process alone right so we'll sort of pick in choose later right now what is the bird's-eye view of how stuff gets done at Kubernetes okay so i i'll explain this with an example so let's say aashwin found a cni bug and uh let let's say a uh you you you found a bug in the in a component in any of the Kubernetes project so what you do is you fix that you set up that project on your local machine then you try to replicate the bug then you fix the bug then you write tests for it then comes one of the more important processes in the whole lifecycle of a patch then you file a pull request there are certain uh criteria that you need to satisfy so all of the Kubernetes code base is Apache 2.0 uh and is governed by uh so any contribution is governed by the CNC of CLA uh what it essentially means this was the question uh uh that was asked a few minutes back by suman so this is the answer that you uh you were expecting go ahead double up so this is very legal document in a sense but uh as as suman pointed out that uh apprehensions about reading the whole document but i would say to anyone out there in the world before signing for anything please read it uh not not just contributor licensing agreements about anything in life where you want to sign something off but what it basically says that you own the code uh what you contributed but you license the community to use it as as well and this is very standard across projects you would see you have to sign the i i think it's called google CLA for golang uh so you have to say that the code that you write is actually yours and yours own you have not copied it from somewhere or it's a plagiarized code uh see all those are legal integrities uh so once you sign the CLA there are certain other small parameters like you need to have github you need to have 2FA on your github account these are some there's some security primitives that are enforced uh to ensure smooth functioning of the project uh so once you file a patch uh ideally your patch is tested uh against the test suite but uh if you're not a org member someone who is an org member needs to come in and put an okay to test label uh on the PR uh so usually you just ping someone whom you know are in the SIG that the SIG that owns the code that you are patching in you're just saying that hey this is this is a PR and I feel this is important can you can someone please uh okay to test this right but once you become an org member this requirement does not come uh like uh any of your PRs are tested uh by default so a small note on how to become an org member some uh some people might find it a bit dreadful but it's actually a beautiful process of ensuring that uh we don't encounter contributions which are spamming uh so in order to contribute in order to become a github organization member of kubernetes or any of the sub organizations like kubernetes 6 or kubernetes client uh you need to show a bit of previous uh patch experience to the project you need to file some uh patches to the project you need to be involved with the project and then what happens is uh when you are involved with the project then people know you uh people notice you then you can ask uh people who are reviewers already in the organization to actually sponsor your application uh to the github organization to the kubernetes github organization so yes that's uh i think all as it said like it's a meritocratic ladder and that that's true for an open source organization that's true for a closed loop organization anywhere you go that you need to slowly pick up to greater things so it's like the reverse of the spiderman quote right uh that if you accept greater responsibility is you give in great powers i guess like that's how you group uh so like and it's also the thing that contribution is always i think welcome because contributors themselves are a very rare resource uh uh not everybody in the ecosystem contributes and even even though like when it has around 2.8k uh contributors and around 1.1k org members uh at any point of time given the complexity and scale of the project they always need more the community always need more and it's not only just textbooks right it's about outreach it's about communication product management there are a lot of avenues uh you know docs where people are walking towards you know making this thing happen and it's it's a very very uh it's white scenario and white set of rules in a way that you can contribute i guess right by the way uh just plug here uh the number that you mentioned is just the people who have sorry contributed contributed to the code uh there are a lot more avenues where people contribute which are which may not be on github uh so people do outreach people do presentations uh for the Kubernetes upstream uh as as a marketing for the Kubernetes upstream so like they're doing great work uh that actually spreads the word about the project and we can't we can't really count their contributions anyway so kudos to those kudos to and shout outs also right it's not only the folks who commit code that make a product happen but it's also everyone around who actually take that product out into the world curate it uh you know uh talk to the users everything right community and battery testing yeah yes yes so there are there are people who actually test the release candidates and they they do a very very important work in the whole pipeline to actually see even before it release if there are any bugs right so on behalf of suman right i'm going to ask this question sort of uh uh because he asked a very valid question right about the clas and uh he he also mentioned that he backed off when he saw that documentation and the terms and conditions and so on so uh there are multiple people there are going to be so many thousands more like suman out there we're going to be on the fence about yeah the joy yes uh so am i right i asked you about the cni issue uh so we're all folks on the fence uh thinking about whether to go in uh take the dive start contributing fight that initial battle but we've not been able to make that jump so what is going to be your pitch for folks like us i would say don't get scared just read the document if i if i tell you that just go sign the document that's a pretty wrong answer if someone gives you that answer don't listen to that person like listen to someone who says that read legal documents uh so you have to be you have to be clear with the organization that you belong to that uh whether you can contribute whether you can contribute in your free time or not whether you can contribute as part of the job or not uh so i think these are all superficial considerations but these are necessary you will in a sense like you have to think about it like right uh since this is a product as well as an open source project who is contributing that also needs to be seen right so uh i i would say like cement also asked you like question that will you face any issues with your company's legal rules i would suggest consult them i can't comment about the specific any specific companies legal rules uh it's on every individual to actually verify that fact whether they can contribute absolutely absolutely you should have a talk with your org before you say yes yeah i'll sign that yes yes before before even signing the cl a just have a talk uh but i think there is a way to sign the cl a as an independent contributor but also as through your organization itself but the organization gets the credit for it on the dev stats dashboard right uh well it's just an annotation okay right so every every contribution is an annotation like who contributed and what affiliation does the person belong to right so i think there is a great incentive for there for an organization also and we we have seen how very large organizations have turned around into and you know by initial uh being on the fence for adoption of kubernetes to being one of the major contributors and actual maintainers of bigger projects inside the whole science of ecosystem right i've seen that happen in the last decade also yep so that is so true uh so right so now let's take it one step further right uh uh the the us and european ecosystems the devops ecosystems have kubernetes uh uh contributor workshops you've got kubernetes happening where where these workshops are specifically held for people who want to contribute into the kubernetes project uh is is that so is that something that you would be interested in you know jump starting in india because i've seen that in the uh eastern time zones in china i've seen that in the western time zones in european us but india doesn't seem to have something like that right i'll give you a nice fact so we have this uh asia pacific coordinators meeting every biweekly on thursday uh today itself but today we had a meeting and there was an agenda point of can we do ncw for a pack not just india and uh you would be happy we will have it something awesome here uh one plug here though is the content is already online anybody can actually go in and see previous sessions and actually get a feel of what is happening in the contributor workshop that's the beauty of uh recording meetings and recording uh events right so even even if you're not physically present you can actually go ahead and uh view what was being done so i would suggest anyone who is actually that's not from your all perspective but as a friend right you know if i try to pitch this idea to you say that hey uh let's be all online like the five six people together on a particular time of uh preference and would you be willing to shift word you know like a couple of people uh mentor couple of people just you know kick start the whole idea that yes there is a mentor next door there is a maintainer next door uh to whom you know like you can quickly reach out and you know bump up ideas or just reach out and say hey i would like to contribute i know you live right down the street can i just reach out to you can you mentor you know to you know uh as i as i as i said earlier nobody will send no to you and it holds true for me too i there are many folks who ask me like how to get started into contributing to xyz it's not just kubernetes uh since i have had uh experience in the python ecosystem too it will do ask me like how do you get started into so-and-so project back in the days i used to work for numfocus for a small period of time who basically handled the pie data stack the scientific computing stack of python and nobody says no frankly like if if someone comes up and asks hey nabarun can you show me how to set up kubernetes slash kubernetes on my machine right why not why do i say no uh sorry i i think i think i think actually let let's let's figure out a way i think i will we will all pick offline after this let's figure out a way that if we can actually make those workshops happen right you know unfortunately i would have loved to have that in in a real space but then i i don't think like that's a barrier for doing it right like if you are interested like or is there other people in the indef channel who are interested and yeah a good plug about the indef channel i think for folks here joining is that kubernetes have dedicated uh slack channels for people uh who indian users channel uh indian devs channel where a lot of mentorship is just a lot of mentors are just hanging around and even if you love i am a lurker i know this even if you love through osmosis you learn a lot of things that actually go on behind the scenes uh right and that helps a lot just to be there on the slack and hang out and understand people spanter what they're going through what are their plans uh how they see the product that helps a lot i guess to understand what's going on right you know what that's that's async right and then if you if you have some block of time just hop into any of the meetings hop into any of the sig meetings that you are very much interested in you will get a lot of context about what is happening and one beautiful thing is many of the uh sig meetings actually have a section for new contributor intro so if someone is new you can introduce yourself there's a specific slot uh but yeah these are just special provisions you can any time go ahead and say hi to anyone it's a free information world so one more than one last thing i guess like before we close this convo is that uh you want to talk about the 1.20 uh you know shadow program oh yes uh so right now uh we are beginning the kubernetes 1.20 recycle and as usual we have a shadow program uh the shadow applications are open until tomorrow end of the day specific time so it's like uh Saturday morning for us kind of uh i'll share the link in the comments uh to the form uh where you can just go ahead and look at the roll handbooks about what role a release team has and then uh whichever role you are interested in just with the form out just speak your mind out that i know this personally because uh nabron has put me up to this and i've been like really scratching my head about okay do i fit in here or do i fit in there for the last two days release team but oh no no no you should go and uh see that is why nabron is very pertinent on one point read before you do so he has given me enough documentation for like it is worth of reading apart from i spent i spent i spent my homework on that so it's like it's like uh there's a pro word right and apple a day keeps the doctor away i would say reading the manual keeps doubts away absolutely absolutely absolutely it was impromptu pardon all right so uh i think i think uh uh the set of places i bring to a conversation to a close yeah i guess like i had one last amazing question uh you know that i thought of asking nabron is that why do people hate yamal and kubernetes is not yamal well you can write your manifest in jason by the way uh come on come on dynamic saying we have a couple of community questions sorry that i just wanted to instigate a real a good flame word online about yamal versus jason and how everyone like the whole practitioner ecosystem is split on yamal so as rauli's saying that's the best answer yeah i i should someday ask him to write in jason but you know what if you want to if you are uh if you are into the infrastructure as a code paradigm use telephone but wrong answer this was a wrong answer only answer there is a complicated there is case on net which got deprecated now dal is coming up so yeah like we got options on dss uh no matter but it's always a battle going on there how to template correctly why do you need to template yamal that's so beautiful yeah just just just don't just make sure you have the one tab equal to two spaces configured in your dot editor config configured that's all so if you don't template uh what bad will happen it would be staging dot yamal production dot yamal beta dot yamal alpha dot yamal for the same resource so it's a very new question so what exactly is this shadow program like uh first of all great question our cars uh i have i want to elaborate it a bit more uh so shadow program just take it as an example of an apprentice program or an internship so there are there are leads who actually uh take uh responsibility of a specific vertical and then uh each lead selects a set of shadows for training them in order to be the next lead and the shadows also take part into the day-to-day activities of the role itself so i hope i'm able to express it clearly it's like a jedi master and padawan system right i don't know if it is star trek star wars or whatever because i did not see anyone people may kill me because of their stats the war cool i think do we have any more questions as i know from the audience someone has a few questions someone's why don't you go ahead sure yeah so my question was yeah i mean uh thanks paul for answering the question uh on shadow program but can you just elaborate more because when you said like they'll be doing like some tasks which lead perform right so can you give an simple example which we can understand i mean what will we do like for example if we are into a shadow program for example for particular sick guys right so there will be for example there is a really sick or something and i am shorting the lead of sick will i be releasing the latest kubernetes version i don't think so right i mean what like what are the tasks which will be and what is the time commitment if we are doing a shadow program uh yeah great great question by the way that's that's like a very valid doubt uh so all of that is actually documented in the handbooks but i'd give you a brief primer uh so the shadow program the the roles of shadows uh vary by role which you are shadowing some roles may be more hands on some roles may be less hands on but the ultimate goal to be a shadow is to learn about what the lead does if that involves doing something uh that's uh i would say it's an added benefit so uh to give to give you an example of the enhancements team uh the shadows as well as the lead the triage enhancements uh ask the owners if they want to be part of this release cycle they want to graduate the cap uh for that release cycle uh sorry it might be a bit jargon-ish like lots of jargon here and there but as i said uh the shadow the handbooks actually pretty much define the work uh but to give you a brief uh context on that you will majorly do what the lead does but the lead actually distributes work amongst the whole team yeah so also i would disturb did you do a shadow program before yes can you uh share your experience oh it was what did you do and how it how did you enroll or whatever yes so before being the enhancements lead i shadowed for the enhancements team for two cycles uh basically so we were four people four shadows and one lead in each cycle and we basically uh took like distributed the work as i said amongst all of us so let's say if there are 200 outstanding enhancements right now uh for Kubernetes we distributed amongst us into party party party party and then reached out to the owners uh hey do you want to uh do you want to make it part of the release now based on learnings i would say you learn a lot of communication skills uh people who are shy may break that cocoon and you also learn so one important thing that i learned as part of the enhancements team was actually reading the featured proposals and then understanding why those features came into existence and what they're trying to achieve so this gives a very uh big insight uh into the next release even before the release happens so you know what is actually coming into the next release all those added perks but it gives you a lot of knowledge into how a Kubernetes uh feature is structured yeah so how much time did you commit to the shadow program like every week how many hours were you logging into i would say it depends on the role and also how much you want to get involved uh there is no specific rule there is no universal time which holds true for everyone uh there is a minimum time which is uh denoted uh for shadows like you have to put in some like x amount of hours every week uh in order to fulfill your role but again nobody would say uh don't do if if you do more and it's also dependent on which role you are shadowing if it's a release team shadow role which part of the release it's is it so enhancements is more front loaded most of the work is on the beginning part of the cycle and later part of the cycle since features are frozen hey we all we have this feature there is not much to do okay so one last question yeah one of the other things is that there is a website that is coming up with all of these uh docs which are currently there in a repo they will be actually propagated to a particular website where it's much more and easily understandable right number one yes so a team is working on something called contributor website kubernetes contributor website uh kubernetes.dev uh which ultimately would hold information like it's a universal uh guide for uh every contributor right it's currently in progress and it was launched uh i think a few weeks back i think one or two weeks back uh but it has it also right now has a lot of uh getting started to kubernetes information i would share all of the links uh to the hasgic uh like page uh comments so that everyone can put in like everyone can see their uh see the links right and on top of that if anyone wants to contact me feel free to do over email or twitter very much slack also works i mean yeah slack works do you want slack yeah yeah the kubernetes slack works so yeah so suman does that answer your questions yeah the last question was uh why enhancement uh sig uh for the shadow program why not other six what made you actually select that enhancement sig so enhancements is not a sig it's a sub team of the release team it's also a sub project of the sig architecture but both are separate entities uh so enhancements team is actually licensed for the enhancement sub project but again all jargon uh enhancements uh interested me because of the learnings i'll get uh about the features that i'm actually using in my workplace that's the short answer to basically curiosity curiosity drove me to contribute to the enhancements team i think this difference like it everyone's like you said earlier right everyone's domain differs and they have to figure out their own vice right where they want to contribute right what is suited for them if that's a release for you if it's cni for cruise if it is probably on the ci cd part of uh you know because again i'm a practitioner that's ci cd i would like to help with that right maintaining the ci cd in for itself in future right so we're going to figure out our pathway towards you know growing into those rules right so i think every most six have a shadow program right as of now uh most sigs have some kind of mentoring initiatives it may not call a shadow program uh there are specific mentorship programs like uh the component standard work group has a mentorship program uh to bring up new contributors uh i know that some people are doing uh specific mentorship which are uh like driving up people into a specific sig where there is like dearth of bandwidth okay so it differs so shadow program is just a term it's i would say you should look for mentoring or people who would actually uh review your code right or whatever effort you are doing it's just not just code