 Hey everyone and welcome to our talk about cube burned out and how to get things done efficiently within the kubernetes community I'm Sasha. I'm now contributing to kubernetes since five years and I'm mostly working on Seg release and second note topics, but everything around container runtime So if you want to have a chat about this one, then I'm happy to talk to you about it I'm also trying to bring the community forward by acting as cncf ambassador and My three-year-old run told me that I have to find a controllable dump truck at cubecon So if any one of you knows where to get one of those then I'm happy to happy for the help and I'm really excited and really honored to be here today with colors. Hey Hello everyone and thanks for coming here and walking this long distance like kind of hiking stuff that you need to go up And now and find the room. I almost lost the room But my name is Carlos. I also work together with Sasha in the cigarette leaves. I'm one of the tech leads together with Adolfo here in the front I'm also was a former Kubernetes steering member my shift ends this this year that we have the elections I Also work on a six star like if you don't know six star like come after me Then I can explain a little bit more and I work for a chain word Today we're gonna talk about this five five points here And then we're gonna walk through and then I'm gonna start where Where they starting point, right? like when What we're gonna talk here It's gonna be applied for Kubernetes But you can extend this for any cncf project or any open source project that you may or Is contributing for Kubernetes is imagine like okay. I want to contribute to Kubernetes What should I do like I go to the web page? Kubernetes.io I go to the Kubernetes Kubernetes in GitHub and then I start figuring out things like okay What's what's going on here? And then I discovered that's like there's more things to try to discover and learn That is the Twitter account. That is the community forums. That is the slack. There's lack Kubernetes is lack and Kubernetes is cncf. That is the stack overflow and that is also then you find this Contributor course then that's a lot of stuff that is going on then you find that is like a Kubernetes have two GitHub works There's Kubernetes and Kubernetes 6 that is more but let's talk on only this too and Then you try like with that is a bunch of projects that like you like What's going on here like where should I start like real start, right? I would say And that is my experience and Sasha's experience like you find a Seek that you like it like you maybe have like a Good overview in in in documentation. Let's say and then you go and see and check it out that my experience Before Kubernetes, I was learning go and I found like a nice project That I would like to contribute but I didn't know like how to coding go like properly then I start like doing reviewing Documentations and then after that like I feel a little bit more comfortable doing that and then I start doing the Coding but here in Kubernetes, we have several six and several in those things They have a different part of the Kubernetes project that should they take care If you scan the QR code, you're gonna see the full list of the six we have current to the day okay You pick it up see where like even what you want to do now like I like for my experience like you You should try to attend the Seek meeting for that specific Seek Let's let's say let's talk about the Seek release one You start to talk attending that meeting that we have like every week in a we try to put that in a good time for that's gonna be good for everybody and You go there. Maybe in the first time you just Listening and then the next time you start asking questions or clarifying stuff Understand the project and the understand the issues that they have in the current or project that you are looking for and Like see the roadmap of the things during the meeting like you usually the meeting that when it starts like you have a space to introduce yourself and you should do that like and Say What you're doing there and what to go do like to learn if it's not possible to attend a meeting because you have a Company meeting or the time is like terrible for you I like maybe just watch a few recordings from the previous meetings to see how is the meetings and what the people talk about there As well like every Seek should have like most of those things have a like a handbooks That describe the Seek and the work and which the super projects recommend also to read that Check the repositories the issues like in the PR the PR is a good point to see what's going on in the in that project and We're like if you want to put the boot in the code part like read the code that helps you a lot and like educate yourself like let's think like you choose as what you like to do like you need If you like are more comfortable and not changing that much Check what you like to do if you like and want to know more Go to a Seek that maybe you can improve a little bit like yourself and or like I'm I'm gonna be very wide here I'm gonna do try to learn something that I don't know like right and then go and like See that the things that as I was open source project You are not getting paid for that then you might not choose the things you don't like it Like I like for example CI CD and this releasing engineer most of the people I know they hate this part like They sign signs sounds boring and stuff for me. It's very exciting for me the part that the part I don't like it's the signal than the scheduling I said I'm not gonna touch that part and like maybe in the future. Maybe not I think never Okay, then like a fail fast like this there like we doing try to do in CI, right? Fail faster to get feedback when you start contributing like try to work in small chains in small PRs that you like you can Like discovery how the the CI and in our case in Kubernetes is how pro works like there is a lot a lot of stuff to understand on that and Use the PR the feedback review from the maintainers to improve your PR in your code and your skills as well This is good to like establish some routines Like I put some examples here and I did like some stuff of this because I for me was Was good like I start doing like doing my contributions on Kubernetes. I start before working Like maybe one hour two hours before or after working and then I switch this to every Thursday and Friday after my work And then eventually I said I prefer doing though during the weekends I'm talking this if you are not getting paid to do this job, right? If you are just like our open source contributor in doing your let's say in quotes in your free time Why are you contributing like make your work public and transparent like you what you get an issue to work on Put like try to not every day and every time like but the try to put a start was like where you are What we're doing if you are stuck or not let people let the maintainers know like don't like try to get to the issue and just disappear and no not providing status because then You are maybe blocking someone that wants to work on that issue, but they are waiting for that. Okay. Oh, that's Sasha is working when I'm not not gonna touch on that issue, but he's not working at all Like try to be as we do in our paid jobs you need to provide status in open source also is a good practice like provide some a little bit of status and That people can know and if you are stuck that they can help you as well After you do some work like a Celebrate the small achievements for yourself and if you're like if you like it to write a blog post I don't like to write blog posts But if you like it do like this and public the the things you did and try to To celebrate this and also recognize the others like it's a good motivation for everybody Like you do a lot of stuff and most of the things are invisible and if people recognize you It is like it's a good motivation to continue working To try to it's okay like to say us Everything like it's okay to say no like if you start contributing and then someone okay Can you take this issue? Can you take that one? Can you start working these three different issues? If you don't you cannot handle that's okay I'm only gonna take this one don't take that like ten issues at once that maybe you're gonna burn out really fast and It's okay to take breaks and like long shots or whatever you want like just to let people know I'm gonna take a like a month off not gonna do anything here and just Relax a bit because in the end of the thing you need just try to enjoy yourself and make the open source contributions like Good for you and not like a burnout and you start burning Later on Thank you. Thank you. Yeah. Yeah, one thing I'd like to add to the previous slides is that getting Overwhelmed is probably one of the most common reasons for burnout The thing is you can get easily all and well them Kubernetes Even if you're just contributing since ten years because I just have to look into the source code of a different special interest group And then you are already there. I think the main message behind it is that Setting the right focus to be less overwhelmed is probably a good one Yeah, so now we we are contributing and we are contributing since a couple of months Maybe a year and then we would like to become an expert in our problem domain. So how can we do that? It's simple, right? We just write a cap and merge that into Kubernetes There is a great talk from KubeCon and a last year from Ricardo and call us about How to get this done or how to not get this done It kind of summarizes that working on Kubernetes enhancements just takes a lot of time And if you work on a dedicated enhancement or graduation, then you have to meet all the deadlines in the very in the release cycle And all those features have to be graduated and also maintained as well Which also means that they have to be dedicated probably at some time or you have to enhance the tests and stuff like that So the overall more conservative approach in Kubernetes Makes it really hard to get experimental features in and there are some way around that But in general, it is more appreciated by the community to graduate an enhancement other than just creating a new one But why should I even care about enhancements, right? So I'm a contributor. I'm lucky with my life Why should I even work on enhancements on Kubernetes? And we really believe that enhancements are great opportunity to grow into a specific area and Have an expert on main level knowledge Where others can also contribute on so this helps the Helping the community to succeed as personal success. That's always one of the main paradigms of open source development You have something distinct to celebrate So you just don't have to celebrate that you squashed ten bucks to your last week, but you can also say hey We get this alpha feature into the release And you work also more closely together with other maintainers, which is one of the best reasons to be part of this community And you are also learned to understand the project politics, which is important to avoid burnout from my perspective So this means that enhancements are generally great to establish a more permanent footprint in the community and It is really important to avoid being burned out on them So how to start an alpha enhancement without getting burned out? So it's really important to do the necessary pre-work So the special interest group should be a supporter by the overall idea you have probably and You can also you'll have to research the reasons for the current state of the enhancement. So many enhancements which seem obvious Are not obvious at all You have to connect the end users or is to reduce the complexity one example is the first enhancement I was thinking of in Kubernetes was if it was probably five years ago So was to get the image pull progress into The CLI so if you pull a create a workload in Kubernetes Then you get no feedback at all about the image pull progress until the workload is created and This looked sounds good, but it is not important So this use case is not important enough for Kubernetes to get it done This can be this can be a reason for burnout, but there's another use case which is pretty interesting So you can connect the pull progress to the timeout when the pull happens means you can get You can produce feedback for the cubelette that the pull is still in progress But it's low and this will avoid the timeout on image pull and will make everything faster and this use case is more important than the actual CLI use case and A community member kind of picked up this work and now we can probably get it done in one of the next releases Which is great So what do we have to do we have to outline the enhancement draft and Kubernetes slash enhancements and this kind of all already outlines that you are waiting to drive the book until the end but we have to leave enough room for iterations and not everything should be set in stone as an helper enhancement Because it should be always the possibility that the enhancement kind of conflicts with other interests or that The special interest group had a different idea and this can also lead to that the whole enhancement gets stuck in a different In a certain direction and this can also lead into like getting burned out on this topic so the whole idea of Initial enhancement creation should be like decoupled from the release process So there are no deadlines. Nothing at all. You just get a feedback to the pre-work and outline. What is the idea and Now the next goal would be to get the enhancement through the release cycle And it can feel like getting stuck in a traffic jam Because there are so many different parties involved. You have to meet all the deadlines there are other enhancements which want to be merged as well and Resources are kind of busy so there are bottlenecks and resources when it comes to review for example And I think the most important part to not burn out on an enhancement is to make progress over Over time And this is the mental aspect. So if you get stuck in a traffic jam Then it can be really really depressing But if you still if it's still rolling at least a little bit then then it is it's not that bad at all, right? So we have to propose the enhancement for a release cycle means we have to get approval from the special interest group and Also identify possible supporters always good to have another pair of eyes working through the release cycle on the enhancement There's always the risk if you work alone on an enhancement that it slips the release or that you get sick And you can't work on it and it's really not Not nice from that perspective so setting personal goals for the hot deadlines within the release cycle is really important, but Yeah, and then we can basically start stock hacking on it, right? And the main main idea is to serve ahead of the wave of deadlines Which means that being ahead of the deadlines like having the docs early in place having the tests and also the The source code changes as early as possible in place for review And will not necessarily lead into that you get the review But you are prepared for it and that's the the mental model which actually helps to get enhancements done and Yeah, then there's the most challenging part like not not getting bound to external dependencies This is really hard and tough because there are always external dependencies If you need API review, then you basically have a bunch of people like three or two right now Which do actually that so this is a hard external dependency you have to get like as early as possible and It's really important to leave enough time to celebrate. I mean if you Just matched at that line This is also a reason to celebrate and you can also say okay I just want to lean back one or two days to live with that celebration effect in my mind other than just continuing and working on because it's really daunting to Not to celebrate something, but then Instantly start working on the next thing Now we have an enhancement merged. It's great, but we also have to graduate it Like there are different policies in place when to create an enhancement and what it actually means but if we want to create an enhancement, which is Not written by yourself, then it's really important to understand why an enhancement has not been created yet So there can be different aspects of that like There are conflicts or the previous maintainer burned out on the enhancement Or the sick is not really interested in the use case anymore or the use case is not important for the company anymore But maybe some other people are interested in it So we can then start great proposing the gratifying to the special interest group to understand the background of it So this also is just a standard We demonstrate the will to drive the airport and we always we also reworked the cap ahead of time And it is really important before graduating enhancement to considering to step back if the complexity is too large otherwise, it is really likely that the enhancement will just Not create it at all over time it changes ownership and the more ownership change we have in enhancements The less likely is that that it will get done It is at a certain point But in general, this is more work than actually Implementing an enhancement from my perspective. So graduating features is definitely more appreciated by the compared community I'm compared to introducing new ones So I think the goal for Kubernetes should be to have all features and kind of a stable state at some point Then we can probably release Kubernetes 2.0 so So and then next thing to level up, which really is really important for my from our point of view is like mentoring new contributors onboarding new folks in the community is Extremely essential for for having a sustainable community and the thing is You can also start mentoring others by not not not on a one-to-one Basis, but you can also start by leaving the right breadcrumbs in the GitHub project. So connecting issues Outlining problems so and connecting issues and enhancements is really one of the little tricks to connect issues together In a way that others can follow the path to the root cause of the problem So many issues are caused by others and you can say, okay If I link them together Then you have a like a mental a mental line to follow if you want to find out why this is the case And why this issue still exists, you know all those issues where people ask Why is it still an issue and why does it exist every maintainer who has to answer this question have to Grape through or crap through all the issues which are available in the project to find out the root cause and having the breadcrumbs The breadcrumbs in place really helps with that The other thing is you can also offer people to Help them directly and discuss more complex topics This also leads into you can help undecided people to fight around that right areas for possible contributions So this is more on a one-to-one basis and also On the next step of that, which is also probably a success story. I'm not sure. Let's let's find it out in the future but like the Linux Foundation mentorship program many special interest groups participated in that and It needs an isolated piece of work for the mentee Dedicated mentors so it's really like a one-to-one or one-to-two mentoring So it's definitely a chance for everyone to get new men new contributors on board in the community Yeah, so and then we have You can yourself also look for more advanced roles within the community like demonstrating commitment To your personal areas of interest that I think it's really important to speak about the personal areas of interest If someone says, okay, I would like I could see you as Chair for this in this special interest group or as technical lead then you have to ask yourself Does it really make sense for me or what would it change if I would be a chair would it change anything at all? Do I have more possibilities to? To help the community when I have this role and this if this is not the case Then it's probably not the right role for you, right? But on the other hand there are smaller things available like you can Propose yourself to be owner of some parts of the source code and Some people really try not to do that because I think they They may think it is unwanted, but I'm pretty sure that every special interest group would be happy if they have more owners on code for certain areas You can also participate in the CNC f-tex and they are pretty new but they provide a more general overview about the Project itself and they are like not only coconut is related, but also kind of have the general overview about it complete CNC f-lenscape and You can always consider running for the yearly steering committee election But really you have to ask yourself. What would it change for you? What if it's just more work to fulfill a role and if it's not like exciting But it just looks like more work than it's probably a slight indicator that you can burn out in this role, but if you have a Great vision for what steering should do and what they would should achieve in the future then just run for the election I'm happy to to elect you So speaking about politics, I think this is an One of the most important Topics when it comes to burnout Many companies so there are not that many companies contributing to Kubernetes in a really Broadway, but all those companies have interest in moving the project into various directions and they want to have their own special footprint in certain areas of the project and and if there's a Not I'm not talking about features But slight changes to the project and you wanted to implement it and nothing happens in six months And then from one day to the other it magically happens somehow So how could that was that possible? This is probably driven by company politics. So there are many people involved who can yeah Who already have ownership over the code and they are able to get things done more efficiently than a single contributor like me And but if it's not your company and even if it's in your company and You're not not part of your department or something like this Then it's probably outside of your circle of influence and then you probably don't have to take don't have to care about it like I Think the the most important reason is here to avoiding being tracked into other companies problems Because if you make them to your problems, then it's really hard to get to get anything done if it's just Driven by company politics So I think the best way to work with this is just being aware that it exists in large projects like this and It is really important to balance the importance of topics, right? So if it's really important for a company To get something done in a different direction Then I should ask myself with probably my direction is not the right one or if I should just step back from the topic itself and This brings us to the next topic stepping back And it's really important. It's I think it's a strong skill to be able to step back But if you are not able to move a topic forward because of external dependencies, for example Or if a topic does not add any value to your work anymore I mean this can happen just from one day to the other if priorities change or if something just basically feels draining Because you worked for too long on it and that does not really make good progress from your perspective All priorities have changed not only on work But also personal life for example if you can't contribute anymore This many times to drive a feature for example during a release cycle then this is Always a good sign. You can also step back But it is really important to communicate that commitment to the community Continuously so you can just reach out to them and say hey, I don't have Inter I don't have basically don't have interest anymore and working on this so I will not do it right now So being able to step back is really a strong skill and helps to maintain also the bigger picture of the overall Of the overall project Yeah, you can't know everything but the community can so Experts from all over the world on work on Kubernetes like we heard today and the keynote So you can just utilize them to resolve your problems faster than you can do alone so understanding the project structure is really essential for this kind of knowledge that change and As colors already mentioned self educating yourself to ask the right questions to the right audience is really a skill But you will also get to know people and they're working domains for example Sometimes it's not enough to raise a question in the select chat of the special interest group But if you definitely know who knows the answer to the question then you can reach out to them to slack apart the thing is Finding the right questions Nobody has really asked before on the project moves the project forward and finding the solutions to those questions Will possibly lead into innovation in the project itself But this also means that we have to find the right timing for the most access and Timing those enhancements into the release cycle makes people work more efficiently together So the release team is from my perspective one of the highest efficient teams in the Kubernetes community And but it also means that proposing enhancements at the right point of time will make people listen If an enhancement is probably too early or too experimental then people will probably not listen But if technology changes like everything moves into the AI direction, then we can have probably more And reason to talk about topics like that and then we can also propose enhancements into that direction and people will listen then and Also raising the questions at a at the right time and proofs the chance to find the right answer So I think the key to success here, especially who is not working in US time zones is establishing an asynchronous work style and this will also make people more likely to work together with you so one example for that is If you chat with someone on slack and pull him into like Being available before asking the actual question Well, it's like and makes the asynchronous work style synchronous and this is really not recommended from our perspective so you can also Make the question as specific as possible Then shut off your computer if you for example in the US on a pack time zone And then you probably if the question is good enough you will get a great answer on the next day and you can start working on it But this is just one example, right? So we have all those different ways of working and many maintainers work and different have different work styles They prefer for example I don't I don't really prefer to get pinged about github pull requests because I three are all my github issues per day And but there are other other folks which which are kind of happy with that work style And there are also special interest groups which are kind of happy when you Put pull requests or review for pull requests into task like channels So it's really it really depends on the working area and I think finding the right way to Provide the information to the contributor or to the group of contributors is really a key to success here so our final thoughts on that are I Think we should just follow the main principle of helping others to succeed And this is the way how to contribute to any open-source community and without Actually expecting to get anything back You will get automatically something back when everything everything's went well and avoiding burnout from the beginning ones absolutely not simple This also means that for example your routines you have established over over the last years May be training now it is so re-establishing or re-evaluating those routines is really the key to Not burnout over time right so there are indicators which are pretty obvious like feeling constantly overwhelmed is probably a key indicator for burnout But there are also some other indicators which come over a longer period of time and those are the most critical ones from my perspective So this means that those habits which we write today may be training over months or years and You always have the possibility to step back. I mean there could be consequences like if it's work-related But in the end you can always Say I can't work on this anymore because it's just too training. I've blown out so I just have to step back and Yeah, I think making constant progress is on the personal high priority topics is the most important part because if it's not high priority for me even if it's high priority for my employer if it's not high priority for me and I don't and it's but it is high priority for the employer Then I will probably burn out on this topic if I don't make any progress at all and Also, this is one of the hardest parts avoid being tracked into the problems of others so This is comes placed directly into the company politics role But I think all in all we can say that that the mental health of us And of course our physical health is the most important part of us in our professional career because we have to do it for a couple of Years more probably so we should invest in it continues to re-evaluate what we would we have achieved and what we will do in the future And that's it. Thank you We have two minutes left. Do we have one or two questions? Maybe How close do you feel you've come to burn out yourselves? Sorry, how close do you think you've come to burn out yourselves? Just I think it's quite a personal talk Does that make sense? I think I think Being aware that burnout is one of the biggest problems of our industry is one of the key point here And I think nobody is really Free from burnout so it doesn't go from from zero to 100 But I think nobody is free from it and we should work and Identifying what burnout means and how to work against it is really really the key So for example as I had no kids and I was working like five years in the industry I had no issue with working after hours or on weekends. So the time was still was just available So it's still easy, but changing that to for example Not working on weekends anymore. Just trimming down the working time to Let's say up to up to 6 p.m. Or something like this totally works Because but it also means that you have pre-invest in it and find a good asynchronous work style And you also have to communicate that works that with others that you that you don't that you're not available in the evening anymore But that doesn't make us low because I can start with a fresh mind if you have something to ask, right? Do you want do you want to add something? Yeah Okay, cool, then thank you and enjoy the rest of CubeCon