 Right, you're still on mute Karen. Yes. Sorry. All right. Um, All right. I'm going to start. Hi everyone. I'm Karen. I'm the community manager for Helm and I'd like to welcome everyone to the Helm contributor summit 2021. Um we're really excited for you all to be here today. You know, Helm as a project has really grown over the years and um we know at the end of the day that it's the people and the community that help push it forward and upwards. So um we're really honored that so many of you are here to learn with us on how to give back to um the project by contributing and so the Helm maintainers will be going over the different ways you can contribute to Helm and how to do so effectively. So for those of you who are curious about what it's like to be a maintainer um we'll spend the first half of the day going over the um sorry for those of you who are interested in becoming a maintainer we'll spend um the second half of the day going over the maintainer structure and um before we get started though just a few housekeeping items. Um first this event is going to be recorded so um as you can see we are recording and the recording will be made available um on the CNCF YouTube channel um later this week hopefully um so you'll be able to catch up on everything if you don't um catch up the first time and then for Q&A we will not be using the Q&A function on Bevy um instead uh we have a channel on the CNCF Slack it's going to be the Helm contributor summit 2021 um Slack channel so it's pretty obvious on the CNCF Slack and I will share a link to that later if you are already if you are not already on the CNCF Slack but again we'll be using this Slack for Q&A um and this will just help us preserve the conversations for after the event so people can go back and look at things and please make sure to thread your conversations to help stay organized and our maintainers will be monitoring the chat to help answer questions and next um please make sure to keep your mic unmuted or sorry muted which I think you all will be um to avoid any interruptions if anyone wants to speak um just you know you can say so in the chat on Bevy and um one of the hosts can promote you to speaking and lastly um I'd like to just ask everyone to adhere to the CNCF code of conduct basically just be respectful to our presenters and our fellow participants and with that I will hand it over to Matt you ready? All right thank you all for joining us today this is our first ever Helm contributor summit we've done Helm summits in the past that have been more organized around uh the the run in and around the community on Helm itself and this time we wanted to take the opportunity to talk more about the whole process of contributing governance and things like that so I am going to go through a very quick slide deck to give you an overview of what you'd like to learn about today and then I will pass it on to many of the different Helm core maintainers along many different parts of the org and you'll learn a lot from them about how each one kind of does their particular thing and how you can get involved and begin contributing to Helm so I'm going to kick off with kind of a big overview to just clear up some of the terminology we use about how Helm is governed so Helm is a CNCF project cloud native computing foundation is a nonprofit that's part of the Linux foundation that basically serves as sort of a central body where we can all donate open source software and have it sort of governed under a central model so underneath the CNCF Helm has an organization and the Helm org has many different projects but they're all tightly related to Helm itself and so to keep all of those projects working well together we have one central org and the Helm community of repo is where you can find out more about this org underneath the org there are a whole bunch of different projects one of which is the Helm project and that's the project that works on the piece of software that we call Helm but there are several other different projects in the Helm org too including documentation some of the github actions registry and repository tools and several more that you'll hear about throughout the day but a lot of the focus today is going to be on both the Helm core project the Helm Helm project and the Helm documentation project we will however cover a number of these other things so I wanted to lay out a couple of terms because you're going to hear us talk about them throughout the day so we talk about project maintainers every Helm repository every piece of the Helm organization has some people who act as core maintainers and core maintainers are responsible for taking care of that project you'll hear us go into more detail about that over the day but a project maintainer is really related to just one of those projects you might also hear us talk about the security team the security team is a cross project team so we've got some core maintainers from many different Helm projects that we all work together to triage security issues when a new thing comes in and we're the ones who try and roll out the security updates when necessary you'll also hear us talk about org maintainers so all the projects are grouped together under the big Helm org the Helm org itself has some people that are nominated from projects to represent those projects to the org itself and we'll talk about that in particular I'll be talking about that later on today in the second half of today's presentations and then the last term that you may hear today that I wanted you to be aware of is emeritus maintainers so in academia you hear about a professor who retires they become an emeritus professor which means they no longer have teaching or committee responsibilities at the university right we wanted to borrow that same concept and when people retire their maintainerships whether their project or org maintainers we then refer to them as emeritus maintainers just as a way of showing respect for people who have contributed many hours of work to the project okay so now we're going to dive in a little bit to sort of an overview of how Helm itself changes all of development of Helm takes place on github okay we do chat in Slack and in other other places we you know we do some live dev updates but the development itself happens on github so when I use these terms this is kind of what we're all we all use the same terms together issues right an issue is a github issue that is a bug or request for help or something like that when we talk about changing the Helm repo we talk about pull requests or PRs PRs are ways using giths API to submit patches to a project in a sort of controlled way where we can review them so if you head over to github and you interact with pretty much any of the open source projects you'll see some combination of issues and pull requests use but one thing that's more Helm specific is Helm improvement proposals or hips that's actually borrowed from Python improvement of improvement proposals which are pips but a hip is a way for us to track a formal definition of a feature that we want to add in to Helm and it gives us an extra review milestone for adding features and we'll talk about that I'll talk about it briefly once more now but you'll hear about it in more detail later on today and and while I do say that hips are to track features every once in a while we do put in small small features in Helm without having them go through the hip proposal process and I wanted to say that upfront lest anybody panic at what I'm saying so the last kind of big thing I wanted to go through before handing it over to to my co presenters is I wanted to talk through some of the workflows that you can hear a lot about today so GitHub again is our central place of doing development and there are particular established workflows in GitHub that we use and some of them are the way you've seen them on other projects and others are a little different so I wanted to start out with the documentation workflow so we have github.com and that's where documentation is if you want to change the documentation that you see on Helm.sh you go to this repo and you file an issue saying hey here's a problem with the documentation somebody writes the text to address that change a new PR is open a pull request that has just those changes and then we discuss those changes and make sure that you know it's organized it's clear it's grammatically correct it's helpful to the end user and on occasion we go back and forth and the person who submits the PR has to make a couple changes then we review it again and say okay everything looks good and we approve it then that PR gets merged into the mainline repository and at some point that mainline gets republished and your documentation changes will show up on the site so that's sort of the typical workflow right start with an issue do a little bit of discussion go to a pull request do a little bit of discussion on whether the pull request satisfies the issue and then if it does we approve it and it goes on to get published a very similar workflow exists for bugs and I think it's Adam Reese will be talking about this in a couple hours from now somebody files an issue and says this doesn't seem to be right about help and there's some discussion well how do we reproduce it can we identify the cause what are some possible solutions and we discussed there in the issue queue many of you I know have participated in this process for which I'm very thankful and at some point someone says okay I will I will try and fix this and they write some code open a pull request and and and we start to discuss that pull request and we say okay are there unit tests to make sure this works does the code pass all of our quality metrics is it functioning properly are there any security issues inadvertently caused by this particular change and again we might go back and forth a little bit with the author and the reviewers and often the community as well but the goal is to get that patch all all shaped up and then merged into the main line again so two maintainers have to sign off and say okay this looks good to me and and then at that point it gets merged on to the main branch and we wait for a little while and when we cut our releases which are all done on a timeline then that patch will go in there we will cover the coding part a little bit later this morning I believe Martin Hickey is going to take care of that and talk about that in more detail I'm just trying to give a quick overview of it now so here's the last thing I wanted to give a quick overview of and this is the feature workflow so this is slightly different and for a reason we value helm stability very very highly right now we know that there are we got five plus million downloads of helm per month and so we know there are a lot of people relying on helm to function properly introducing a feature can be dangerous because it might break something inadvertently or it might modify the way people do work in an unexpected way so we are very careful when we introduce new features that's why we have helm improvement proposals which is a written description of what your feature is going to do and how it's going to work so a hip is created in the community repository not in the helm helm repository and can refer to any of the projects under helm and again Matt Fisher will go over this in detail later but the idea is it's a written explanation of the feature we discuss that feature a little more carefully than we discuss a bug fix and we say okay does it is it addressing the problem is it consistent with the rest of the way helm works does it break anything does it introduce any new security issues are there other things we need to consider would it be better to wait until helm 4 to do this kind of change and things like that. A successful hip will get approved and then merged into the community repository and then oftentimes the PR will start during the course of the hip but at that point once the hip is approved then we will the maintainers will officially consider whether we are going to merge the PR as well and the PR review turns over to are the mechanics of the code correct is it are there unit tests are there functional tests is the hip properly implemented in this PR and things like that and again will iterate a little bit back and forth but before the two main two or more maintainers approve of that and it gets merged in now features don't go out in every release they only go out in minor or major releases so they're far less frequent in the code base then patch and security fixes which will go in every single release so that should give you a big overview again we're going to come back later and cover each of those things in more detail but I wanted to give a sort of bird's eye view of how we look at maintaining health so next up Scott Rigby is going to jump in here and talk about repositories I haven't talked really much about those at all I'm waiting to pass everything on to him and he'll give an introduction of that and the changes in the last year and how we do that kind of thing but here's kind of an overview of the rest of the day after Scott Bridges going to talk about documentation in more detail a documentation is an excellent place to jump in and get started Ronin is going to take it from Bridget and talk about the mechanics of the website so if you want to improve the Helm.sh website with CSS changes or HTML changes or things of that nature Ronin will kind of give a high level of overview on how to change those kinds of things after that Martin is going to talk about coding and coding guidelines in Helm when you're ready to open that first PR the stuff that Martin says first code PR against Helm Helm the stuff that Martin tells you about will be very very important for you I'm really looking forward to that one we'll have a short break there and then we will come back and I will cover governance in more detail I'll go back to that earlier CNCF slide and explain what each of those things mean and what the security team actually does and what core maintainers responsibilities are and things of that nature Matt Fisher is going to deep dive into the Helm improvement proposal process and explain how to do one of those starting some major features or jumping into a hip proposal and helping people refine those major feature changes everything Matt Fisher has will be helpful there and then Adam will walk us through the process of reviewing PRs, cutting PRs and explain how we as maintainers really go about that process and how you can streamline that process for yourself as you issue PRs and how if you become a core maintainer you can help out in those returns then finally not on here and I will return here and close the session down I think we can tip our hand now and say there will be some awards and things like that at the end so it's going to be an exciting day here I'm going to hand over now to Scott I'm going to try and stop my screen sharing so that he can try starting his and we'll make this first transition from speaker to speaker and see how this goes but thank you all again for being here today I'd like to introduce Scott Rigby one of the core maintainers of okay can you hear me can see me wow okay this was going to be a complete surprise for me how it worked fantastic hi everyone so yes I yeah Scott Rigby I work in developer experience at WeaveWorks now I have been involved in the Helm project for some years I've worked yeah I'm one of the core maintainers I help I'm on the organization maintainer group which will be covered later it sounds like and I think the primary focus that I've had within the Helm project apart from that has been the ways that users interact with charts so I had worked as a co-maintainer of the stable and incubator central charts repositories before those got decentralized worked a lot in helping to decentralize those and I can just I can only I can briefly mention what that is when when looking over the the repo so that you have a good sense of what if you're as a new maintainer as a potential new maintainer contributor rather as you're looking over the repos you'll see various past projects and one of them is that and also I help with I'm with the team that helps with tooling Helm that excuse me that charts maintainers use to do what they need to do including hosting help repose and testing their charts and so on and automating them so I have not I have actually asked if you can hear me well still yeah you're doing great here you're clear okay awesome okay great and then I'm going to try screen sharing for the first time so bear with me for a second and just for everyone here please ask questions or really just feel free to interact I each presenter might be different but for me it's very informal interactive here I simply just want to hear to give it overview so here is the screen share I think I can do this here yes can you see my screen sorry can you see my screen okay I'm having trouble knowing if this is working or not I mean we can see a black screen and a mouse pointer but nothing else right now oh really okay well hopefully it'll just fast forward quickly what browser are you using I am using chrome hmm I wasn't sure if that was a mistake or not actually like the awesome browser because I think the back end of this is Hangouts right yeah okay well are we still on I can try stopping and restarting or connecting and disconnecting yeah it looks still black okay well okay so I haven't planned it back exactly except I could what I could do is talk through them that might not be as engaging but why don't I try stopping and starting my screen share again just once and see if that helps okay another suggestion if you out and jump in back here so sometimes this can solve the okay you mean jumping out of bevy and back in yeah okay I'll try that and we'll you know we'll see we'll see how it goes okay thank you you're right back yeah so well he's doing that do we have a the times for the schedule are they posted somewhere Karen for when we have a break and I forgot to share that at the beginning I'm sorry I added it to the description and the home computers on it slash channel I will also drop it in the chat here as well all right I dropped it in chat I can't really format my text looks a little messy but that is all in the specific time with that schedule there I can go so so Scott will come back and finish up the introduction section then we'll talk about how things change in helm and that whole section which will have multiple speakers will cover sort of the day to day how you submit changes and things like that then after the break we'll come back and really take more of the maintainer view of things and talk about how things are changed and how core maintainers interoperate with and what our different processes are and things like that so the first part will be very practical about how to get started and the second part will be oriented more toward how core maintainers work and what the inner mechanisms are again with an eye for helping people who might want to be maintainers to understand what that involves all right Scott looks like you're back I'm going to hand it back over to you and let you give it a shot with the screen share okay great that sounds that sounds good all right fingers crossed one more time you know what again a worst case I can just I can just speak to them briefly and will be will be everyone else's presentation will be at some point referring back to these repositories so you won't miss it entirely but if that's the case okay can you see can you see anything besides the blank screen though unfortunately it's a mouse screen oh no there's got to be one at least one right one in every conference okay well what do you think should I at this point go ahead and just speak to some of these repos briefly I think that might be a good idea or would you rather just go ahead okay okay well in that case I'll stop sharing that doesn't really help you okay great well so we only have a few minutes now sorry about the technical difficulties but what I'll do is I'll paste these into I'll paste these into the chat so you I'm sure you know the very first repo that you want to be looking at that Matt mentioned is the client in SDK and the website those are here and here it's important to note that the repositories are they're not strictly categorized at the moment but they have different functions so so those two you're probably most everyone here hopefully is most aware of and if you're interested in becoming aware definitely focus your attention primarily on the Helm client in SDK website or excuse me repo for code the website for documentation and so on to get an overview I guess you're going to go over this Matt so I won't get too into what's in the community repo we find things about governance the process the processes for everything related to the project Helm as a project itself and not only to its primary core client or its other sub projects or tools and I'll fly a little more quickly here there are other sub projects so several of them are longer term projects that are expected to continue one for example is chart museum that's one that is listed often because it's used by many people it is supported there are also several projects I just want to mention you can not ignore but just keep your eyes peeled for their deprecation at some point there is a project called monocular which is getting into that category Helm Hub it is something that is going to be deprecated the repo hasn't officially been made obsolete the tool that it ran is deprecated it now points to artifacthub.io the CNCF aggregator for all CNCF and cloud native packages and then the other things I just want to mention really briefly I don't want to go over time really but thanks Bridget we have a chart helper and automation tools and so just there's three of them and it would be nicer if I could show you but the one that you probably are using the most now if you have any automation round charts whatsoever is charts testing oh excuse me I actually did not type for correct you know the last link but the charts testing project is a project written in go it doesn't use Helms SDK if you're interested in contributing that could really use some additional people it doesn't use Helms SDK it uses Helms binary on purpose so that we can test multiple versions because the point of it is not to test Helm Helm has its own tests but it's for chart maintainers to test charts so it's a very very helpful project it allows you for example to install basically everything you could do as a manual user with the client dry runs but what it also does is automate it allows you to put in tests and automate those and also integrate with other great tools around testing so it's very helpful for keeping things stable there's a tool called chart releaser and that I'm just going to briefly mention it it is a different way of hosting Helm repose than chart museum rather than running in cluster and running as a separate application it really just leverages at this point GitHub it could integrate with GitLab but it uses GitHub pages in order to host Helm repose which is exactly what the stable and incubator repose package history are doing now thanks to GitHub there are other helper tools those two are for chart maintainers those two are for people who are using let's say end users using charts releasers for chart maintainers and then the Helm 2-3 Helm 2-3 plugin I don't know if this is a good category for it but I believe it's a good helper tool for practitioners human operators as well when they're upgrading from the former version of Helm Helm 2 to the current version of Helm 3 so the last thing I think I should say because it's now at 9.32 I don't want to be too too go too over is oh thanks Pritchett there are several Helm actions and this is important for for knowing that excuse me for being able to get up to speed quickly and automate the above tools that I mentioned so the releaser that allows you to post your own Helm repose without having to pay for other tooling and the testing so I have one demo link that I'm going to paste and I think I'm just going to leave it at that for this section for the actions because this page has a the read me has very good documentation well simple and clear documentation about what the other actions are in short there's an action for the kind the Kubernetes kind project just so that you can we can do we can test charts inside of clusters that are quickly spun up within automation and then it wraps around the other two products I mentioned chart testing testing and chart releasing so it allows it allows you to basically get up to speed and running without really knowing a whole lot to start but with good practices good and safe practices that can be supported and then you can dive in deeper from there there's no real magic under the hood so there are several others that for example there's a homebrew tap that helps with our homebrew packages because we have several other binaries that are not in in the homebrew core yet but the rest are really just there are some Docker images you might see in there that some of them are being used but others will be made obsolete relatively in the not too distant future there are and I think the last thing probably is just when you see the helm slash charts repository that's one of the most contributed to repositories within the Helmorg I should say one only because I'm not sure if it is the but it is not the place to put effort into anymore but you can still use that repository to for a history of what has happened with charts that you're using that around the wild now that have moved to separate repositories it's the source code for many many for charts that install many different cloud native applications up to a certain point up ultimately till last fall so I hope that helps I'm five minutes over were there any questions that anybody had or should I just go ahead and pass them a ton cool thanks Karina great yeah I'll stay on Slack too and I'm glad I got to be the guinea pig I hope others have better luck with their video good morning so I'm going to take over from Scott here and move on to the next section okay so I'm going to do a screen share can everyone hear my voice okay just making sure before we go I can hear you, you're good I'm going to do a screen share this works nothing seems to be happening sorry bear with me a second I think I need to do what Scott did I'm going to very quickly leave and come back apologies for this I will be about hopefully just a few seconds this is where we would put on the whole music alright so we're heading into that second section the three big topics we're going to discuss in this section will be Ronin leading off with with sort of the mechanics of the website followed by I believe Bridget is following Ronin and we'll talk about documentation and then Martin is following Bridget and we'll be talking about the process of coding alright Ronin welcome back hopefully everyone can see my desktop okay okay sorry about that okay thank you for your patience everyone so I'm going to go through this section which is the how things changed in helm section so hopefully everyone can see these slides so this is going to be I'm going to move pretty quickly there's three different kind of subsections in this because a lot of things change in helm so I'm going to take the first segment which is just kind of like an overview of the website some of the tools that we use for running and making changes to that and Bridget then is going to look at the documentation section of the website which is probably the area that sees the most activity we have a lot of docs a lot of different languages and then Martin will pick it up to talk about the coding processes around working and contributing to the helm core so without further ado just introduce myself I'm Ronin I've been kind of doing things contributing to some of the helm assets for a few years the helm website really has been around since about 2017 maybe earlier maybe 2016 and it's as the project has moved into the CNCF and we have a lot of like extra resources through them they help us to host, run, maintain some of the tools that we use here the site is pretty busy we get about 50 to 60k visitors every month so there's a lot of traffic as you can imagine a lot of it is looking at docs trying to figure out how to use helm in different situations which Bridget will cover so I just want to give a quick kind of run through of what's involved in that see if anyone is kind of interested in helping you know make edits commit changes and code to the helm www.repo so you know hopefully most people here are a little bit familiar with this this is just like the landing page explains the project and this is like where you arrive at the site and this is how most people I guess would have their gateway into helm if they're not already looking at the give out repo the site really is composed of three distinct sections we have the home page we have the docs section which Bridget will talk about which is a lot more article focused rather than explaining what helm is it's explaining how to use helm localization has been a big push for us over the last probably a year and a half to allow people in different languages in different parts of the world to understand helm in their own local language and then the blog which acts as kind of again like our account announcements deep dives into some of the recent events around security audits and CNCF milestones project birthdays and so forth so I'm going to show you kind of like what's behind the website all these sections which are kind of very different in their purpose and their kind of layout they all work off the same code base which is the helm www.project and you know as Matt was talking about with our GitHub workflow as an open source project in the CNCF we try to use GitHub for everything so we have community repo where we kind of put things like brand assets any different kind of presentation slides fonts things you might look for if you're interacting with the project that can be a useful place to check out Scott gave a nice run through some of the other repos that are out there really we try and keep everything published and accessible via GitHub so the website code base is I think as mentioned earlier it's the helm www repo it's built on Ugo which is a static site generator it is basically it's what they call part of the jam stack there's no database it just generates markdown files into a website and puts it on a server that people can use it's pretty low frills and easy to maintain so I'll give a look through some of those tools in a moment the Ugo site is then pushed up to Netlify through the GitHub workflow which I'll show a little bit more of in a moment and it really allows us to keep things synced up and deployed pretty quickly it's a nice light kind of chain of things so the main repo here with something like this you'll see you'll see the readme is pretty kind of thorough around how you run the site how you develop it and interact with Ugo the deployment you can actually see all the different logs and so forth through Netlify every time there's a push to the project it gets deployed as a feature branch that you can kind of test and preview your changes before they get merged and allows you to kind of test things like design changes or to see how blog posts or even documentation changes look before they're added to the session so let's see so looking to that a little bit more we're going to talk about how that looks from a pull request point of view Matt Butcher kind of explained the project's GitHub workflow process and it's a similar process for making changes to the website whether you're making changes to the landing page to the documentation to the blog everything goes through Git commit and pull request review process so the project maintainers would review pull request before it's eligible for merging before it's merging you will see this section down here which is the checks we have a DCO which is our commit signing process which I think Martin will be discussing in a bit more depth and the second one you see here is this netify check and that's where it renders a deploy preview so it's nice it allows you to see if anything's going to break before before it's deployed to the site and we have an example of that ready to go over here so I'm going to show you what that currently looks like here's a PR from Bridget who she made this yesterday Helm updated from its 3.5.2 release to its 3.5.3 release just about a day or two ago the website doesn't reflect it it's out of date so I'm going to very quickly review the pull request I'm going to give it a thumbs up and I'm going to merge it so you can see here in files changed the version got bumped here it's a very small pull request I'm going to review and approve and as in one of the administrators on this repo once I have given approval to this the buck turns green my checks are all green so I'm going to merge and what's going to happen is this is very quickly going to build and deploy the site to go from from that version to the new one so we can see in the this is the Netlify interface which is running the site this is an account that is run with the CNCF we do all our builds and deploys through this also DNS configuration is here and very quickly it's going to build and deploy that website and while that's happening I'm just going to switch over to the site here and show you what's currently up there go to the docs we'll see it's showing the old version 3.5.2 as the stable version within about a minute or two that will be pushed up to the new okay so that's kind of like the a quick example of how it works Bridget will get into some of the more details around making changes to the docs how versioning works how localization is set up the reading here really is pretty thorough we have a lot of good processes and things defined within the Helm project you have contribution guides release checklists and so forth the doc site really is a great starting point for any questions you have and if you're curious about the Helm project and the website we try and use issues like for tracking any bugs or anything we want to make as an enhancement and we have a special label called good first issue which is a nice starting point if you're curious about how can I be of use to this project I've been looking at this codebase I'm trying to figure out what small things can I do to get familiar with the tooling the good first issue label is a nice resource for that here's some small things that are on my list of tasks to fix up we always welcome contributions if anyone wants to look at this stuff and if there's any questions around how you interact with this tooling how do you install Ugo how do you resolve maybe a broken build in Netlify the Slack channel is a great place to come and ping one of us but hopefully our documentation and our readme are pretty thorough that's the bulk of things I wanted to cover there's a lot of different parts of the site I've been working on this for a couple years and we always appreciate new people coming in with fresh eyes to look at this and notice things that we don't notice if you have questions the Slack channel that's been set up for this event is a great place to go with your questions you can ping me if you have any specific stuff around the website at the front end the design, I'd love to help without further ado I'll pass it on to Bridget because that's coming up I think on about 10 minutes and Bridget's going to go next in the last talk to Merck thank you so much Ronan but before you share your screen do you want to show us that finished build yes let's do that that's a good point let's go back to that character change yes it's a big deal thank you for that commitment it's awesome okay so yeah it's published green everything looks magical it took one minute and 38 seconds to deploy that which is why we love static sites because there's not a lot of extra stuff to do it's pretty swift it's a doc's homepage here yeah so there we go 353 and that's it it's pretty quick so thank you for your PR thank you for contributing to help no PR is too small yeah okay so now I get to try the very exciting screen share process oh boy it has so many choices I'm going to attempt fate and try the chrome tab even though it might be a betrayal of all how did that work I think it worked yeah I see your slide fantastic okay so what we're looking at here is the docs and I think if we start by just looking at helm.sh slash docs and we see that it's kind of a lot exciting okay now I see the difference I'm just going to stop sharing and restart because I have a bunch of tabs and it really only shared the one tab how exciting we're going to try that's a little bit better because now I can actually change to other tabs all right so if we take a look at the helm docs that we were just on and I can reload that and see we're at 353 now free and we take a look at the helm docs we actually have this front page that says how it's organized and it's probably a good idea to take a look through that because the various types of docs are pretty different from each other the tutorials are a really good place to start if you're new to helm and you want to try something and if you want to PR in something that says yeah you're making a giant leap of logic here with this tutorial open an issue or make a PR to the docs repo or make a tutorial missed out on explaining something the topic guides again like they're more detailed explanations but more high level so key topics, concepts, etc if we take a look at some of these oh charts library charts how are those different from charts wait chart repositories there's a lot of chart stuff going on here so you can see there's a lot of detail again like it goes into enough detail that depending on what high level concept you're trying to learn the topic guides might be useful the community guides highly relevant to people who might want to actually contribute to something this has the developer guide we are constantly updating our release checklist because it turns out there are a lot of steps like for example updating that 353 it was on a checklist but it was step 10 of 11 what are you going to do and then we'll talk a little bit about the localizing too the how to guides are worth taking a look at specifically because they are in more depth so these are not necessarily simple topics but they're pretty complex topics like say developing your own charts okay so there's a lot there and you might be like okay what's next where should I look let's take a look actually at the docs site itself very meta because if you're going to you know help with the docs you probably want to know about the docs so where the docs actually are this is that repo that Ronan was in before he was showing us the read me of and the docs themselves are in content and then their language specific and so not every language is going to have every single thing in it because some of them are like for example there are some languages people have actually translated blog posts for and other languages they have not and the actual docs themselves again are organized somewhat like what you saw earlier but you know there's let's talk a little bit about the what you see here versus what you see on helm.sh again you can see all of these top level things versus what actually shows up on the website this we mentioned before is Hugo and if we take a look at there's front matter that needs to be on each kind of page so again if you try to start instantiating say a new language just take a look at what exists there already because it makes it easier to scaffold it and I do want to talk a little bit about that that idea of translating the docs into an additional language and we have a recent example that's pretty awesome of French and so this is all community you know contributed stuff people come along and they start translating there are you know there's the localization guide that is the translation guide that says exactly what you should translate or what you should configure when you're translating but there's like this config.toml that Ronan mentioned briefly you have to have a section in there and then you have to have like you're at the bare minimum probably like the index page and then whatever other pages that you want to translate can be in a pull request you can kind of see and how some of us like you should have a part of French you should have a part of French so in some cases we may not have reviewers who speak a language so we'll just take a look and see oh did they do anything obvious like leave some English in there I don't want to do that or capitalization could be a problem because past your case instead of that sort of thing so if you're thinking well how do I help here you can review pull request either if they're in your language or in a different language you know just depending on what you speak and then um this I you know got merged in and we go and we look at the docs and we think fantastic we have French now you know oh look we have a CSS issue that we need to fix but we have French now right so one other thing to note before I pass it over to talk for Martin to talk more about code is there's an interesting corner case or in translation there are um these helm commands the CLI commands to give you like information that you can get from the helm uh binary itself this stuff is compiled into the binary in English and then people might translate it and we just PR those translations into the website because we don't have a way to have the binary the helm binary itself output other languages so that's an interesting corner case that just keep in mind like this kind of thing is evolving all the time perhaps hey you'll come in with a contribution to find an even better way to do that um but anyways that's the docs for the most part are in uh the uh and oh one other thing about translation uh it's wonderful if multiple members of the same language family want to review each other's translations because in this case for example um we get a whole bunch of people you know commenting on and um contributing to a specific pull request you know saying oh what about this what about this and iterating on it and making it better and so if you're thinking I want to contribute to helm but I'm not you know a helm expert or I don't know enough go and so I don't know if I can you probably can just by contributing this sort of contribution so all right um but I did mention that a couple of those things are in the actual code base because Ronan and I have been talking about helm helm dub dub dub but there's a lot going on over in helm helm as well so let's talk about actual code like actually getting the PR's merged uh we have Martin Hickey joining us today to talk about that I'm gonna stop sharing my screen and let Martin share thank you Bridget can you hear me folks loud and clear fantastic let's try and share here let's keep this uh this lucky uh sharing going on let me see here okay can you see um Safari I don't see any screen share from you yet okay what was the trick come on go out and come back again kind of thing or what's gonna work here um okay let me stop sharing for a second try again okay