 It's really shadowy but before I go ahead, it would be completely reminiscent of me not introduce myself, let's just bring that screen up. So as I mentioned before, I approach beauty and social projects, a few social projects to under the CNCF band is also how this presentation came to be experience with the Kubernetes project and the release team. So a good fortune of being a contributor in the Kubernetes as well as the Limpus Kiosk project since last year. Also I am a CNCF capacitor and a co-organiser of the CNCF student user being said important to talk about our subject from the standpoint of what it is. The reason being a lot of information is already available as to what it is and we also will be covering it so don't worry too much about that. But a lot of stuff or whatever you search for doesn't really detail as to what it is. So not according or a documentation internship program with the Kubernetes project. Sure Kubernetes project is involved with the LFX, Outreach, Google season of dogs, Google season of gore previously. It has been sorry and we have had successful participation in those particular programs but the Kubernetes release shadow program is not related to that. And just as a reminder, it is not the only way to get started or contribute to Kubernetes or open source in general. So even if you don't get it and even if you don't make it in the very first attempt, please don't be demotivated because this is not the tool and beyond of your open source journey or your journey another Kubernetes project. The last line is something that I felt needed an explicit shout out there. It is a great line on your resume. It definitely is when you go ahead and put the experience on your resume or your CV saying that you worked or coordinated with the various stakeholders towards putting out the Kubernetes version. It definitely makes for great viewership but it is not just that. And with this presentation and the next couple of slides, I hope I'm able to convince you of that. So now that we've looked at what it is not, let's look at what it is. So I apologize for the video shifting a bit here and there but coming to the very first one. So typical Kubernetes release spans three to four and sometimes even five months and given the release cadence that has been introduced at starting 1.19, the voluntary time commitment is approximately three to four months. So ensure that you have the time to actually contribute and sort of put in the effort when you sign up for the program because as with everything in life, what you put in is what you get out of the experience. The second thing is it's obviously a very great opportunity to learn more about the Kubernetes ecosystem as well as the open source ecosystem in general. So as part of the release team, you get the opportunity to interact with various stakeholders, special interest groups and some of the best and kindest folks in the tech community and I'm not exaggerating. So as part of those interactions, you not only understand more about the release process but you also gain a better understanding of the ongoings in the open source community in general. And like I said before, it's because you are involved in a release of an open source tool, you are going to have exposure to how it works. In my day job, for example, I did not have that standpoint from where I could understand what a typical release process looked like. But being a part of the open source community rather helped me gain more understanding and also gave me pretty good exposure to how a release looks like in an open source ecosystem. Last but not the least, I did mention that it is not an internship program but it is definitely a mentorship opportunity. So you are going to shadow or work under a role lead and that can be obviously basis the application form that you fill and the choice that you make while you fill that application form. And irrespective of the role that you are shadowing, it primarily encompasses coordination and facilitation of the various artifacts that go into a Kubernetes range. So there is no actual coding or writing documentation required as part of being in the release team but you will be doing a lot more than that. So it's a very great learning experience if I may say so and honestly it also is as much of an effort from your side as much as it is getting into the release team. So getting into the release team is a competitive effort. I know that because this release cycle rather we received 185 plus applications alone. So it is obviously a very competitive program but again like I said before what you get out of the experience is what you put into it. So unless you are ready to make that time commitment and unless you are ready to make that effort commitment for the time frame, I would highly recommend you to assess your skills assess your strengths and then go ahead with the application. This is not to deter anyone but is just giving a realistic picture of how it is. So now that we've spoken about all of this who organizes this whole effort because at the end of it somebody needs to be organizing this particular program. So within the Kubernetes project itself we have various groups and in the Kubernetes project like with every other large organization we have specific nomenclature. So the governance aspects are managed by the committees, user groups are folks who have similar interest areas and do not have any ownership of the code base. Working groups and SIGs are so SIGs are special interest groups before anybody gets confused. So special interest groups like the name suggests is dedicated towards special interests and furthering those interests into an actual artifact for each Kubernetes release and maybe not even that at some time. So there are special interest groups that do not have anything to do with the release but have like a meta role to play within the project. So just as you know brief, there are various groups within the Kubernetes project would be a short summary of how our project is organized but it is the SIG release that organizes the release you know the release shadow program and the release team is one of the sub projects within the special interest group release. So who is actually eligible because I've said a lot about you know who's organizing it, what it is, what it is not but who actually is eligible. So like I mentioned before, anyone really because as a prerequisite you do not need a lot of things but it but let me remind you once again that it's a highly competitive program. So the narrowing down or the selection depends on a lot of factors. So you can apply if you are really interested and you do not need any experience being part of a release team. You do not need coding expertise and you do not need to have knowledge or you know expertise on Kubernetes. Having it however is not a disadvantage, I will definitely help you but fun fact, I did not start off having Kubernetes knowledge when I joined the release team last year. My whole idea of joining Kubernetes as a project was to learn more about Kubernetes as a tool of technology. So honestly, if you are interested you definitely should consider signing up and genuinely there are no specific prerequisites except for the time and effort commitment from your end. So I've spoken at length about the release team and you know I've reiterated the release team so many times you must want to see a pictorial depiction of how you know the release team looks like. I mean I cannot put the faces because we are we don't have like a consistent what do you say membership every cycle. So the release team as a whole basically looks like this. So as you can see there are a lot of verticals in the release team. There's an enhancement's vertical, there's a CI signal vertical, there's a bug triage vertical, there's a docs vertical, release nodes and a comms vertical. Now each of these verticals will be responsible for delivering the artifacts that are assigned for their verdict. For example, because I have led the comms for 1.2, 1.21, I can speak at length about it. So the comms vertical basically deals with the communication aspect of the release. Now that involves all the you know webinars or blogs that you see going out after the release. It also deals with the blog that actually gets released on the release day and you know all the coordination with CNC and all of that comes under the comms vertical. Now if you go to the docs bit it's a no brainer right you need documentation for every release artifact. So the docs vertical is responsible for ensuring that there are documentation available for every release artifact or enhancement that goes in. And speaking of enhancements obviously you know we are you know targeting specific artifacts to go into each release right and within the Kubernetes project we even have a special name for them. So the way this is put in is via Kubernetes enhancement proposal. So the enhancements lead enhancements vertical is responsible for sort of tracking and ensuring that all the enhancements are in within a particular date and you know understanding if there are any barriers with respect to reviewing and approving the enhancements and you know stuff that basically would be you know responsible would be the responsibility of an enhancement's lead is basically just the tracking of enhancements as an overall you know gist. So now you may ask what does the release lead to and what is the emeritus advisor in Greek. So as with everything you require a chief and command chief or chief and command I'm sorry I forget the term here but you require someone at the helm to sort of bring everyone together and shepherd them towards driving the release to the completion right. So the release lead actually does that job along with his or their shadows and the emeritus advisor is a previous release lead who actually ends up functioning as an advisor of sorts to the release lead, release lead shadows and literally every everybody in the team based based on his or their experience in the release team. So where do you come and that is where I would like to show you. So if you can see here there are a lot of shadows written across each vertical right. So you as applicants for the release shadow program would tend to file an application for one or more of these roles and so you possibly can select for one or more. So that is completely dependent upon you but as I am probably going to cover in the next couple of slides I would highly recommend that you apply for one specifically because it helps in narrowing down your intent and your skill set as well. But the shadowing aspect is where you will be working along with your vertical role and ensuring that the artifact or the deliverables assigned to you are completed by the specific time. Now even in this whole image there are specific times in the release when each of these are more active. For example, comms is a more end of the release heavy role which doesn't mean that comms doesn't do anything in the start of the release. We are more often prepping towards the end of the release so that a lot of the work doesn't bulk up towards the end as opposed to which enhancements is a start of the release heavy role because only once you start tracking the enhancements will you be able to actually get the release out right and the relevant talks out and the relevant release notes out. So different roles have different time commitments and different areas in the release not different areas, different times in the release when they are more active. But as an overall time commitment like I mentioned in a couple of slides before it should be around three to four months. Now coming to how do you work? So at the end of every release this was the shadow selection for Kubernetes 1.22. This was sent out after the Kubernetes after towards the end of Kubernetes 1.21. And this is sent to the Kubernetes dev and Kubernetes dev group groups and a couple of other avenues within the Kubernetes project. We also try to amplify it via our Twitter handle. So those are good avenues where you can keep track of this particular email or notification. So the emeritus advisor for that current release would be the one who will be sending it out in case you have signed up for the release. And obviously there will be communication sent out in Slack as well. So those are three or four places where you should keep your eyes peeled if you are interested in joining the release. Now some of the things that I would like to reinstate before we close off for the day. It is not the only way to get started in Kubernetes or open source. It does seem like it because of the lower entry level barrier where you don't require any prior experience in a lot of avenues. But it's not the only way to get started. For example, there are a lot of folks who have tried applying for a release team and as a result have gotten introduced to other avenues within the project where they are now contributing. So it's just a matter of you understanding where you can contribute best. And trying to find that out is one of the major things that you'll be doing when you're in an open source ecosystem because there is no set pathway for any of us to grow as a contributor. So if this doesn't work out, you definitely can pick and choose from other opportunities that are available, not necessary mentorship or internship programs. But there are tons of other opportunities like documentation and non-court contributions that are available not only within Kubernetes but with other open source projects. So please, please don't be demotivated if you don't get in at the very first attempt. And that also ties in with my last point because it's a very, very competitive program. Like I mentioned for the 1.23 cycle that has recently commenced, we received around 185 applications for around 40-ish positions. So you need to imagine the scale that we are scale of applications that we are receiving and the amount of rejections that have to be sent out. So it's an extremely competitive program and as a result, it is also very easy for rejection to come by given the competitiveness. So don't get demotivated and as always, there are other avenues you just need to ask for help. And the last thing that I believe I already spoke about is what you put in is what you get out of the experience. So if you're trying to become a contributor and sustain your contributions to Kubernetes as a project, it is extremely essential to be able to make that time commitment and effort commitment without which it's not going to work out for any of you. Like neither for the project and obviously not for you. This personally took a little while for me to understand. I won't say long. A little while for me to understand because as with everything else and as with everybody else, I was expecting quick results. But sustainability of the contributions is the key here because doing high impact work matters, but also be able to sustain that high impact work is also of equal importance. So if you are putting in efforts and if you are trying to make a difference, you definitely will be able to get more out of the experience and you definitely will be able to plan the contributor ladder faster as opposed to someone who is just doing it for the sake of having a tagline on the resume. And there's nothing wrong with the ladder. I'm not discrediting the efforts of the person who's doing it for the line on the resume. But it is extremely important to understand that there is an equal effort and time commitment that's required from your end to see the benefits that can be reaped out of this experience. So that being said, thank you. And it was a great day or not to be presenting to you all on the first ever student track. If there are any questions, please let me know. I shall be available to take them after the talk is done. Thank you so much and have a great time. Bye-bye.