So hopefully I'm audible because this is the first time that the label might, so yeah. Hello, everyone, and I'm Divya. I'm Savita. And we're here to talk about burnout in the context of an open source ecosystem, primarily drawing from our references with the experience of burning out when we've contributed to open source projects and when we've been juggling them alongside our day jobs, the pandemic, and a lot of other stuff going on in our lives. So before we dive deeper into our journey of burnout, we want to get started by introducing ourselves, Divya. Yeah, so as I already said, I'm Divya Mohan. And I'm at SUSA, and that's my day job. But over and about all the documentation work that I do at my day job, I'm also one of the documentation maintainers for the Kubernetes and the LitmusKyos project. So that's like a lot of documentation work, I know. But other than that, I'm also involved in a bunch of community-related initiatives as part of my role of an AWS community builder and a CNCF ambassador. So I'm extremely passionate about community-driven tech and helping people take their first steps in their open source ecosystem. And that's just me.  Sure. My name is Savita Raghunathan, and I am a software engineer at Red Hat working on Kubernetes and OpenShift data prediction. Before that, prior to that, I was working as a platform engineer, and I was creating platform as a service using Kubernetes and other projects that are supported by cloud-native computing foundation. Along the way, I came across an amazing Kubernetes community. I fell in love with the Kubernetes community, and that's how my contributor journey actually started. I started contributing to SIG docs, and then I eventually ended up in SIG release, the release team by SIG release. And I was there for like five releases. That's where I met Divya at 1.18 release, and then we were together for 1.22. I led the 1.22 release. And then right now, I am focusing on the documentation project. So now that you have known a little bit about us and how we got started and what we are passionate about, let's move on to who we are not. So yeah, there is a fair disclaimer that we have to put out because none of us are our medical health professionals. Neither are we starting to be one, because let's face it, we've got a lot on our plate already. So whatever we're speaking about right here is not medical advice. And we request that if you're identifying yourself as someone suffering from the symptoms of burnout, you talk to a medical health professional and get the relevant advice, because that's what we did. So with that PSA out of the way, let's look at why we're speaking about this today. So burnout is not a new concept in the open source world. It's been prevalent since early 2000s and probably even before that. It comes and goes in waves. And why now? It's because we are at the peak of one of those burnout waves along with the pandemic. So this feels like the right time to talk about it and create awareness and create more and more an environment where we could talk without any stigma attached, basically. So that's why we are doing it again. And the whole thing about burnout is it's a very vague, abstract sort of a term. So when I actually went ahead and told a couple of my close friends or people who I'm close to that I'm suffering from burnout, what exactly caused it? Is it like you're too stressed? Is it like you've got too much work on your plate? Or is it like just this whole pandemic thing that's going on?  So it's a very vague term. We actually really want to focus on burnout is because we want to start with those conversations wherein we gain more perspectives. We have this capability to develop a vocabulary around it. And we know that we can't do it alone. Like as I said before, we are not medical health professionals. So even World Health Organization, which is supposed to be the premier health organization in the entire world, ended up defining burnout as a syndrome just in this year. That is 2022. So let's have a look at what the definition is. So the World Health Organization, the WHO categorizes burnout as a chronic stress from workplace. So we are all open source contributors. We don't fall under that category. Most of us. We are not paid to do the open source during our day job. So we love our community. So we do it during our own time. What happens to us? We are not even a part of that definition. Like according to the definition, we don't even fall and even under that. And most of us are like doing our day job and then doing open source work. And we do it day after day, week after week, and we end up being, at least for me, I ended up being like, what am I doing with my life? Like, I don't have anything else. I just open my computer.  I'm not getting my task done anyway. I'm just standing on my computer. And even the shopping therapy is not helping anymore. And at the end of the day, I'm really sad. So that's one of the reasons that we want to reach out and make sure that even the burnout in open source community gets addressed. Right. It's totally OK if you did not listen to the past couple of minutes as both rambling. So the TL-DL version, I modified that a bit. So the TL-DL version is that we want better vocabulary. We want awareness. And we want more perspectives to come in. It's as simple as that. Because the more perspectives that you have, the better conversations that you can have around it. And you are fostering a healthy culture of having communication as a default, rather than just when urgency crops up. So in an open source ecosystem, what tends to happen is, we don't have a lot of these open communication channels. And what is visible from the outside is what is totally different from what is actually happening within the community. And that's what Savita will talk about in this slide. Yeah, so let's see from a consumer perspective. Like the consumer, this can be an employer, ABC, wants to adopt a project. And they have this new project proposal, which uses the open source project X in this case. And then they get approval. They publish their product. And they deliver it and it becomes a success. And that's about it. All they know is they look at the project page, code, binaries, which they can use. And then the documentation website. What they don't know is a lot of things that goes in the backstage. How about the licensing people who are waiting the license there and making sure that it's OK to consume? And there is no legal implication. What about the infrastructure people who are maintaining the project, writing their suites, and making sure the project, every release is stable and reliable for someone else to consume. And same with the collaborators all around the world who are participating in the project. And they don't get recognized. All that the employer would see is like a code. And that is the only valuable contribution so far in most places. Most of places don't recognize the other contributions as contributions at all. And that causes a lot of fatigue for the people who are working on the other side, the backstage in this case. And there is very less pool, very less stable pool of contributors in those areas where folks can step up and go to the next level. That causes a lot of lack of motivation in the first place. And it doesn't just stop there. We were talking to two of our friends the other day at the Contributor Summit, which happened on Monday. And there was this meeting, a SIG release meeting. And where they were talking about a role called a release manager. A release manager, in this case, is responsible for cutting the branches and getting the Kubernetes release out, every single release. And they have more, probably, responsibilities. And this is like the gist of it.  And I'm an engineer. And I want to be a release manager. My manager might question me, asking like, do you want to go in the manager line? Do you want to manage people? Because all they see is the manager word in it. So the commendable thing that the SIG release people are doing is they're going to change the role to a release engineer or something which can resonate more with the employer. More and more things need to happen. And it shouldn't just be the, our own students shouldn't just be on the open source community. It should be on the employers or to encourage like, it's fine, like, oh, you're contributing. Which way are you contributing? And how can we take this? And how can we use it? How can we support you? That should be the ideology behind it.  Is that it's exciting because it's not quite like what we experienced when we start off at, say, a corporate setup, which all of us here are a part of, by the way, and most of us at least if I'm not wrong. So when we, when we, you know, start off on an open source contributor journey, typically what happens is it's a reflection change because you literally get to choose what you want to do given, you know, the stage you are at, given the skill sets that you have. And what tends to happen is there is one thing that is probably as much of a barrier as a skill set that is sort of signing up for way too many things. And you should ask us both about that because we probably might write a PhD or a thesis about signing up for way too many things. It's literally something that we've done over the past couple of years and have regretted deeply because we are enthusiastic and we love the community and we love to contribute. And this particular thing is a double-edged sword. So as freeing as it can be, that is a very big double-edged sword hanging right over her neck and it can possibly lead into burnout. Now, when we thought of this presentation and when we thought of, you know, giving out, giving up the CFP, we thought of how we could approach it because a talk has already been done about this before, but not in the open-source context. And we had to narrow it down to the open-source ecosystem and we wanted for it to be a bit different in the context that we needed, you know, more open-source stuff into the presentation. So we're going to approach this presentation from the perspective of three user personas, which is a contributor, a maintainer and a community evangelist. And I know that there may be, you know, several other personas, but these are the three broad personas that we have started off with. And we are extremely sorry if it's excluding anyone, but it was not our goal. It's just the thing that we are most experienced with. So sorry, right at the onset, if it is exclusionary. And we'll start off first with the contributor stuff. Let's get started with the contributor stuff. So how many of you here are a contributor or wanting to be a contributor or like thinking about it? Yeah, right? So we're all, right? Let's dive into it then. So there have been open-source projects that have lived longer than me. Successful projects, Linux and other projects, right? But the both of the Kubernetes lead to something else totally different. It got adopted by a lot of company and there was a lot of interest and the open-source contributions and open-source became a buzzword. Or at least that's when I came to know. So I'm like, I'm just going to say that. So please pardon me if that is the wrong thing. That created a lot of opportunities because the CNCF came along, adopted the Kubernetes project and then like a lot of many little sandbox more and more projects came on. And which means that you can contribute to any project you want. And even within the project, then you have like multiple roles. Like, oh, we can do the docs. You can do the release. You can do the coding and you can be the PM and whatnot. So a lot of opportunities, right? And when I started the Kubernetes, I faced with that same thing too.  And I was part of that I was doing work with sick documentation as well. And then I also signed up to be a mentee in this working group called competence standard, which is not a part of the ecosystem anymore because they achieved their goal successfully. So they dissolved the working group. And there was also the sick country bikes contributed to experience which had a triage, issue triage group going on. So I signed up for all of these things at the same time. And I also had a day job. So what happened after a while? All right, after a while, like I couldn't just keep up. I'm like, I'm just lagging one way or the other. I'm a perfectionist. So I hated it because I had to be on top of everything and I have to finish it and I have to like make it better. Like I don't like touching, like if I write a piece of code, I don't like going back and touching it again, at least for an year or so because I want it to be so good that I want to focus on something else. Really, so that did not help at all. And I had to pull out of some engagements and that hurt really bad. Why am I talking about this? Is that I want to highlight that there are a lot of opportunities and there are a lot of challenges too, along with that, right? And then comes the contributors located in anywhere in the world. When I want to contribute with Divya, right? It always happens during my lunchtime or her dinner time, cutting into our quality family time and personal downtime, right? You can have it any ways. You can just take an app or like you can just watch TV, you can do anything. But in that, we choose to collaborate. We do things like a synchronous collaboration but doesn't just cut out all the time and we are working on it. This is like one of the additional challenges as a contributor. And this is when you have informal mentoring programs within. But what when you're a new contributor, absolute student or even just a new contributor getting into an open source ecosystem and you see these N number of programs, internship programs like LFX internships and we're not advertising, by the way, just saying. So you have Google season of code, Google season of docs, outreach, LFX internships and I don't even remember the others, sorry. But you have all of that and you have to do your day job and you have to structure it in a way that it doesn't sort of eat into your personal time. It's not possible. Take it from me because I was on the Google season of docs for 2020, I worked with Son. I also was on the release team shadow. I worked with I think Savita at that point in time and I also was helping with sick docs. I was doing minor edits and I was doing a daytime job and that took a toll on me. And I'm not even kidding when I said it took a toll on me, it really did because I thought that everything that I do within the space will be reflected on my resume, but it didn't because I could not even end up completing half of it. And like Savita, I hated doing it, hated pulling back from the opportunities that I was given. And the major thing why that happened, why I got into such a mindset was to actually curate my profile in a particular way, show that I'm a particular person, but that doesn't work. It honestly doesn't work because there's a lot of effort that goes behind every single project, every single community that you build. And if you actually try to curate your life, like with how it happens with Instagram, if you try to turn your GitHub into a tech Instagram, it totally is going to fail majorly. Primarily because you take on a lot of things, you try to curate it in a way that is more apt for employers or potential employers to take a lead from. It is going to fail because you're taking on too much of work for yourself from that side.  So for at least for myself, because I'm gonna speak for myself here, and I realize that it's not a sprint, like nothing in my life is a sprint at this point. It's gonna be a marathon, if anything. And I'm gonna pace myself. And this realization came very late, that was last year, I think mid last year was when I realized that. And it took a lot of, you know, emotional exhaustion, physical exhaustion, and the inability to drive anything, literally anything at work or in open source or at home, really, to completion. I could not do anything virtually properly that I, in the way that I wanted to. And that's what helped me, because it sort of showed me the reality that, you know, you gotta stop here because you're not doing anything well. You're just putting your hands in three different things and doing nothing of them, none of them right.  And then, you know, the reassessing of priorities and stuff came up after. But that was my journey. And for me, like, many of you might have taken flight or some of the other way to come to the Cape Canaanee. I've heard always, like, if you have ever taken a, come, flew through a flight, you will just, I've heard that, like, put on your mask before you help someone else, right? So I had to, like, do that because I started feeling emotionally drained and more than that, I was emotionally unavailable for my loved ones. And that taught me so bad. And all because of the things that I'm doing and that is not right. So I had to, like, pull back from all the engagements that I had. And then I had to, like, make a short list. I'm not good with long-term lists because I can never stick to one thing. I keep changing for good. So I had to, like, make a short list and then, like, figure out what I want. So I, when there was a sick dog's pr-rangler and when they reached out to me, I said, like, I'm sorry, I cannot do it. Can you take me off the list? And they were, like, kind enough to do that. And I said, like, I will start from scratch because whenever I'm ready, I will do it. And they were, like, more kind enough to say that, no, no, when you already let us know, we will put you as a reviewer because you have served that role for a while. Which is amazing to know that stepping down or stepping back is not a step down, right? Like, I took a step back. It doesn't mean that I lost anything. I'm still there. My place is waiting there whenever I'm ready. And the other thing is, like, self-care, which is very important.  Like, I'm very harsh on myself. Like, if I'm one hour late getting up, I'm, like, very mad at myself. So I have to relearn, like, how to be kind to myself so that, like, I can focus on the actual stuff that is happening instead of just being mad at myself. And another thing is, like, communicating. Like, I'm working on it. I'm getting better at communicating. Like, I work with this amazing security folks, right? And I commit to so many things there as well. And I stumble and I cannot do things. I fall and I message them in the Slack saying that, see, I couldn't do this because something happened. And sometimes I don't even have to give a reason and they understand it and they are, like, extending their support all the time by willing to help me, right? And that is what a community is. So if you are in a group that doesn't do it, you're in a wrong group. And if you are not doing it, you should start doing it. And you should advocate or tell your group to do that too. Like, we are all there for each other. It's like, you know, we have to look out for each other. There is no race. Like, it's not a race, to be honest. It's like, all of us help, all of us succeed. And that is what the community is about.  It needs to have good people at the top. And by the top, I don't mean the top of the building. I really mean, like, the hierarchical top of the community. So according to us, at least, in, like, the community, maintainers are typically the people who are able to foster and set, go, foster a healthy environment. Of course, it's aided by contributors and the other people. But maintainers are typically the people who actually help with setting goals, setting expectations for their specific area and, you know, helping the project go in a particular direction. So when you're a maintainer, you have that additional responsibility of not only embodying the expectation and carrying out what you are expected to do, but you also have to actually, you know, set that particular goal and ensure everybody else is living in an environment that can actually aid them to go towards that goal. And what happens when there's no goal? Like, what happens when there are no expectations at all? That's something that Savita will talk about. Yeah, so what happens when there is no goal? It is at least a chaotic environment, right? There would be a lot of features that so many people are working on at the same time or, like, no feature at all. And the project becomes stagnant.  Like, for example, if it is a project that's supporting another project, like, little mini tools that we use, the CLI tools that's supporting a big project we don't update it, keep up with the big project with this moving at a speed of a bullet train. And the project's, like, pretty much dead. So, and you can also ask, like, why should we set expectations? Because the contributors are doing it as a wallet. Most of them are doing it as a voluntary thing, right? How can you set expectations? Like, how can you expect them to do something? But think about it like this. Like, if you set little goals, right? Little themes. Like, come up with themes for your releases. Like, say, reliability. Say, like, a security. Say, like, documentation. Say, like, five features goes in the release. That puts a lot less stress on the maintainer because they know that they have to only block, like, two weeks off their three-month cycle to review, to help the contributors and get the feature in. And the same with the contributors, too. They know, like, they have two features to focus on. They can get the features done in the right way and they can move on to the new one instead of, like, lingering, like, having, like, n number of features lingering and then just keep it going for, like, God knows how long. Like, two, three years or maybe even drop out. So those are the little things that I want to highlight here. And when we talk about, you know, these goals and she spoke about it pretty well in terms of, you know, pacing out your work, you have to be sustainable about it as well because you have to set expectations that are sort of community we don't are not, like, working for your own schedule. And if you, if in any community, you're made to believe that it's, you know, the leadership is just, you know, the first people who are at the helm of it all. It's completely wrong because, you know, community altogether, the people in the community altogether are responsible for the health of the community. And when we speak about sustainability within the community aspect of things, you have to understand that even for a maintainer, like she just said for PR Wrangler reviewing role, stepping down is not a step back because you are still there, you're still within the ecosystem. You're not going away, going away anywhere. And that role will be there. It's not some, it's not going to go away magically because we open source is a voluntary thing and it will always require people. So distribute, distribute your work, help other people get up that ladder as well because who are we in a race with at this point in time? Why are we in a race in the very first place? Because communities don't race against each other. They walk together towards a particular goal. So there is no particular way of approaching burnout from, you know, a maintainer's perspective because, you know, it's an individual effort. But while fostering that healthy environment, it is extremely essential for the maintainer to be cognizant that while setting goals, he, they, he, she or they have to be really cognizant of the fact that those goals are sustainable in the long run and not just catering to their own, you know, cadence and their own comfort. So now that I have actually spoken about this maintainer persona, we also want to, you know, touch upon this single maintainer persona. Yeah. So like there have a lot of project that has like very few handful number of maintainers doing it. One of the such things that I can think of recently is the log4j, if you can all remember about the security issue that happened. And the number of companies that's been using the log4j, like my partner works in medical industry, medical devices, and he knew about it because they were using it in one of the medical devices, like communicating somewhere, like in the software. So what happened there? Like a lot of employers, like they wrote blog post about it, and then like a lot of people were like creating noise on the Twitter, and they're like maintainers who were working hard to fix the problem, in addition to hearing the concerns from everyone around the world, right? That is not sustainable at all. Imagine how much guilty the maintainers would have felt that they are not able to meet the goals. Like guilt is not my friend, your friend, or anyone's for that matter in this case, right? So what the right action is that the employer, we could have all pulled that moment and supported that community so that we could have grown together or we could have solved the issue together, that is one action. And we just wanna call out, it's really important to recognize that sometimes it's just like one or two people doing it for years, and number of years, I don't know. I cannot do it. So I'm hoping that that's not the case in the future. Like we all get very cognizant about it and we create parts that where the new people can go as a bud and mature into a flower and move on, right? So it should just be like a cycle. Now that we've talked enough about the contributor and the maintainers perspective, let's move on to the community advocacy. Right, so this is gonna be fairly brief because both of us are not in the trenches of community advocacy. I'm a technical writer, she's a software engineer and we both do our share of documentation but none of us is a full-fledged advocate here. So with our experience, what we've tended to note, what we've noticed is actually that the technology ecosystem goes by very fast, isn't it? Kubernetes itself has right now three, four releases at this point for you. So before it had even more. And this is just one project that we're talking about. There are many projects here in the ecosystem and they keep having these many releases and it's difficult as a community advocate or even just a particular project's advocate to understand or figure out the number of changes that keep going in for each specific project. And what tends to happen with advocates is that there are broadly three buckets wherein a contributor basically is just doing advocacy on the side, a person who is not actively contributing but is creating educational material or putting out podcast videos related to that project and a person who does both juggles it really well. I know a few people who do it really well so kudos to them. But it takes a toll on them because the ecosystem goes by really fast and it's on an advocate or on that person to assess and take a step back and understand that the kind of content that you put out and the pace at which you put it out, is it worth the cost of your own health? Is it really, really important for you to churn out content week after week or can you pace it maybe a little slower? Would that be okay? And that is an extreme consideration that you have to take because it doesn't make sense if you are building your bridge which a community advocate is on very weak foundations because community advocates are supposed to be the bridges between the project and the wider world, right? At this point in time, that's what we associate community advocacy with. So if you're doing that and you are yourself spreading yourself thin, then there's no point in doing it at all because you are just going to either do it half-heartedly or you're going to just not do it at all or not be able to drive it to completion if you're anything like me. So, Rome wasn't built in a day and it's best that if you take a pause and then press play because otherwise what tends to happen is that you're gonna burn out at the speed of light. If there's a faster speed, I don't know if it was invented but if there was a speed, you're gonna burn out at the speed of light and that might not really be helpful for anyone involved. And with that... Yes, so we hope we have created some awareness. We did set a goal for us that if one of you who's listening to our talk here or virtually or anywhere after that, if you are motivated, inspired to speak about burnout or even educate your family, friends, at your work, at your employer, that means that we have achieved our goal. So that is one thing. And also I want to call out on the community that we as a community should come together and work on solving some of the issues that we have discussed. There are multiple issues that's been already going on. So we should take this as an opportunity to discuss all those. And we have linked some resources already, like familiarize with yourself with the burnout symptom, reach out to your fellow contributor, fellow friend, and if you see them with the symptoms check in. Some people did that for me and really helped me. So do that. And we have some of the CNC resources too. So check that out whenever you have time. And to wrap it all up, to be honest, I know you all have been sitting here pretty long and it must be really taxing for you all to listen to us ramble for that long. So to wrap it all up, we know we haven't presented you all with a solution to a problem. But what we are hoping is the conversations that we have after this lead to that solution. And maybe it's not immediate, but as an ecosystem and as an industry, you know, in the wider sense, we need to have better ways of coping with burnout, better language to seek that support. And obviously that comes with, you know, being more inclusive and being more diverse about the perspectives that we are gaining. So thank you everyone so much for listening to us today. Thank you. We hope you had a good time. Anybody got a question? We're on the internet. This is Celeste, cost contributors. And because my last role with the CNCF was a staff technical writer with them, I wondered if you had any perspective on burnout that is unique to people working in documentation and open source? Tell me the deeds. Okay, I've just been fairly recent and this is not advice, but it's a burnout last year when I was working with dogs before I became the coach. So it was really difficult for me and I had to put a hard stop for myself. It was not as easy as, you know, I said in the presentation, it was not as easy. I had to put a hard stop. I had to take a step back and it is, it sounds easy when I say it right now, but it is, you know, that decision of putting a hard stop for yourself, stopping yourself from consuming all the content because as technical writers, I know that when we have to sort of write about something, we have to do a lot of research. You have to write and review and do a bunch of stuff before we actually put out content or dogs or whatever. So from that side of things, it's very difficult, but it's essential if you're going through burnout or if you're on the brink of burnout, that you take a hard stop, you reflect on what you can consume, what might not be a complete information overload and delegate that work to either audience rather than, you know, taking all the responsibilities on yourself rather than, you know, it's just going to be a lot of burnout at the end of it all. So I think delegating responsibilities and taking that hard stop is what worked for me, but I am no expert on this. Like I said, I'm not a mental health professional. So yeah. I mean, thank you for your help with Stig Docs and with Kubernetes. It's been a wonderful lady. Thank you. Thank you. Another question. Hi. Hi. This talk has been amazing. Thank you for doing it. Thank you. On one of your slides, there was a piece of advice that was, you know, set up structures so that people can ascend into leadership, give people leadership opportunities. And what advice would you have for maintainers who are trying to figure out a way to do that well? So I am going to take example of one of the things that Stig Docs did recently, like one of their co-chairs were like stepping down. So they had a cohort of like a six weeks to something where they train people. And finally they have like three amazing co-chairs right now out of the program. That came out of the program, right? And that is one thing. And sometimes it should, I feel like it should be ongoing. It shouldn't just be like one off and it should always happen. Like there should be always someone who's in the training or like set up a rule, ask like someone might want to be a tech lead, right? But they don't know how to do it. And someone might be just interested in the topic, but they don't have the resources. It takes a lot of effort too. So I wanna like say to the maintainers that you also have to take care of your health. And when you say that I'm gonna like support this group, it's gonna take a lot of effort, which means that you need a lot of people. So like take it bite by bite, you know? Like one thing at a time. So if running mini cohorts works, that works. That's about it. And then try and expand it later to a full-fledged program and you have more contributors. That's one thing that I can think of right now. When I think of more, I know how to reach out to you. Thank you. Thank you. Okay, we got time for one more question. Yeah, hi. Thanks so much for the talk. I feel seen, but you spoke about guilt. What I wanted to ask was, so one really good thing right now is that there's a whole influx of new contributors coming in. So I'm from the Kubernetes community. So my mindset is that I don't speak for like other communities. So there's a huge influx of new contributors coming in and it makes me very happy when they reach out, ask for help, how to get started, right? But at the same time, I'm also experiencing some of the symptoms that you described and there's this guilt of not being able to effectively help them get started in the community. And like I got started because of a workshop that Divya did, so thank you for that. But have you experienced guilt in that manner in the community and if so, what were your experiences with dealing with it? Do you want to go first? Yeah, sure. So basically I had a lot of guilt after that summit, not summit, open Kubernetes community days that we held in Bengaluru because a lot of people reached out to me after that asking for directions on how to get started. And it was physically, mentally and energetically, I guess, impossible for me to do, to cater to all of the requests. So what I did, to be very honest and very frank, is delegate as I wrote in the previous slides. I delegated that to a lot of the older newer contributors. I cannot, I don't have a particular phrase for it, but that's how I see them in my head. So there are people who are in the community who have been around fairly, after fairly new, but they're not exactly entrenched yet and they've just started out their journey. So it's an opportunity for them to pay it forward and they have that confidence because they've just started and they know a bit about how to get started and I'm giving them that opportunity as well to help another person. So that worked very well for me and first off when I started, it was extremely nerve-wracking for me because I don't know if that person would actually, you know, listen to the second person or whatever. So what I did was I initiated a group chat and I would do a check-in if that person was okay and if they or he had found their way and then, you know, if they had any problems, I would ensure that there was some bridge between the two or a communication channel between the two where they could address that until they were comfortable and all set to, you know, navigate themselves in the community. So that's what I did and I gotta tell you, at first it's very, very, you know, you feel a lot of guilt because, oh my God, I'm not helping someone personally but don't take it personally because it's not your fault. It is nobody's fault that you can't help. You have too much on your plate. So if you have that, you should delegate and of course I won't tell you not to help but whenever you have a chance, let others also take up the mantle. Let others take up the opportunity to help others because that's how a community grows. There is no other way a community can grow.


Dear graduating class of 2020, my name is Peter Chen, and I'm the Interim Chair of the Computer Science and Engineering Division at U of M And I want to congratulate you on earning your degree from University of Michigan Computer Science, Computer Engineering, or Data Science. So you all have a lot to be proud of. You've mastered challenging concepts about computing You've built systems that someday, maybe even someday soon, will benefit humankind You've conducted research that will shape the field for years to come And you've grown not just in technical skills, but as people you've learned to work in teams You've made lifelong friends You've probably experienced some setbacks and grown through those and you stretch yourself to reach goals that you didn't know you could attain So this is the time to celebrate and even though we're not able to gather as we usually do I hope you take time this week to look back on your years at U of M and celebrate Even virtually with your classmates, friends, and loved ones And I hope you use your U of M degree as an opportunity to make the world a better place Congratulations and go blue. Congratulations and go blue. Congratulations class of 2020. Go blue. Congratulations. Congratulations. Go blue. Congratulations graduates. Go blue. Congratulations to all the CS grads at Michigan. Best of luck in the future. Just want to wish you all the very best Congratulations on graduation. I'm in virtual beister or outside of virtual beister Good luck to the computer scientist computer engineers. Everybody else who graduated this term. You did it.  Congratulations and good luck.  Congratulations. It's been great knowing you and getting a chance to work with you Best of luck in the future and happy trails. Hello. This is professor Tulk Prakash You may recall me from database course or from undergraduate advising for data science Congratulations class of 2020 and wish you a very bright future ahead Congratulations made it through this weird semester and you've put in so much work to get here all the best as you Continue on elsewhere in the world Hey graduates, Rocky and I want to congratulate you on all your hard work and successes over the years Especially if you made it through one of my classes because those are no joke. Gaboo From our family to yours. Congratulations grads grads This professor Wes Weimer from software engineering EECS 481 You may have seen me in a few other places and I'd like to congratulate all of our students who graduated this year Out of you and your accomplishments everything you've been able to get across during your classes And I wish you the best going forward in life Those who stay was interrupted by COVID will still be champions go blue Hi 2020 grads on behalf of the CSE undergrad advising office. I just wanted to say Congratulations. We are so proud of you and we can't wait to see what you do next Congratulations on this major accomplishment and keep pursuing your dreams Hey Congratulations I'm so very proud of what you have achieved and I'm so excited to see what the future holds for you I wish you the very best for your next steps and I hope you'll come back to see us