 So today I wanted to tell you a little bit about the year I spent doing some open source. So I was fortunate enough to spend a year and a half doing open source development for a major internet hosting provider. I'm not going to name any names, but those are the gems that I worked on. So when I first started off, I did a little bit of analysis. I kind of dug into the gems and I looked to see what was missing, where there were some rough spots in the code that needed to be refactored, where there were some issues or some PRs that needed to be addressed, and basically just some holes in the test coverage. And I basically came out with this huge list of to-dos that I wanted to do. And then basically I was off encoding. And when I got an issue, I basically just dropped everything and I worked on it. And then about a span of three to four months, I became very overloaded with people reporting issues. I'd actually take care of one and then three more would replace it the next day. So I was kind of being overwhelmed by the popularity, the upswing of my support. So and then one day I actually had a revelation and that revelation is that open source development is not the same thing as close source development. And I thought I knew what this meant, but I really didn't get it until that moment. And that kind of leads me to my first lesson and that's don't do mentor. So instead of actually dropping everything and working on the issues that were being reported, I started responding, thank you very much for reporting this issue. I'll definitely add this to my list of to-dos. But is there a chance you want to take a look at kind of solving this in the interim? And usually within about a minute or two, they'd reply back and say, well, I'm really busy or I can't do it and then wouldn't you know it sometimes? Like as short as 15 minutes, I'd actually have a PR up. So by just by following this lesson, I saw my workload actually greatly decrease. But I actually developed another problem and that problem was basically people were submitting code without tests. And I know what you're all thinking, what kind of subhuman would do that? So I adopted what I like to call the gentle nudge. And that's basically where instead of like braiding people for not including their tests, I would kind of flip the value proposition on its head. And I would tell people, thank you very much for this contribution. Is there a chance that you can write some tests so that I can make sure that this continues to work? And nine times out of 10 people actually followed up with the subsequent push containing the tests. Lesson three, be responsive. And this is actually something that Wesley Bleary, the gentleman who's the owner of the fog gym, taught me. And if you notice in very successful open source communities, whenever you submit a PR or an issue, you'll typically see a response within 24 hours. That response doesn't have to be like a solution. You don't necessarily have to review the code. You just have to let somebody know that you acknowledged their issue or their pull request. And I think this makes actually a huge difference. Like I said, if you if you dig into certain open source communities, you'll notice that the people that are responsive will typically have a lot more community interaction. Lesson four, be positive and emoji on. So this kind of follows on the two tips that I showed previously. Just be very positive. People that are contributing to open source are doing it out of the kindness of their hearts. And I think everybody here agrees that you want to be in a community that really supports and wants what you're working on. So I think that this really contributes to kind of building a much bigger community and also like just throwing a lot of emojis. People love them. They're kind of like the scratch and stiff snicker of scratch and stiff. I can't say that word of the of the Internet generation. Lesson five, some people cannot be helped. This this was actually a very difficult lesson for me. I've actually worked at a couple of companies that are very customer service based and it's very difficult to say no. And so I found that if you can't typically interact with somebody in a pull request or an issue report and get to the bottom, get some actual information within like three responses. It's you're better off just leaving that issue open and hoping that somebody else in the community. Well, is having that same problem and are able to kind of jump in and provide you that additional information. So lesson six seems like a little bit kind of contrary to the previous lesson. But the one thing that I noticed was that if you're having trouble getting people to respond to issues or pull requests that you're better off just to actually kind of closing them. So if I asked people for some follow up information and I didn't get that within two weeks, I would basically just close it with a nice note saying it sounds like this issue has been resolved and you're no longer interested in it. And I got a much, much better response from people that way than actually just trying to kind of ping them. They would jump in and say, no, no, please don't close this issue. You know, I've been real busy. I've been meaning to work on it. And then also to add to this, you'll see that the community will actually chime in. Other people say, no, please don't close this. This is a this is something that I'm watching. This is something that I need. Lesson seven, you should always view issues as opportunities. I know it's really kind of hard whenever somebody submits an issue or tells you that you have some bug in your code. But particularly in the open source world, this this is actually a good thing. People care enough about the work that you're doing to report to you that something's not working. It's also very good feedback. Maybe your API is not as good as it could be. Maybe there's some confusion around that. Maybe you need to add some additional documentation. Maybe you need to have some more examples. So please, please view issues as as opportunities as a good thing. Lesson eight, I think this is something that everybody who's been on a agile team will hear. It's not your code. It's our code. And I think this goes doubly, it's doubly true for for open source. Because if I submit something or I want to start a discussion about changing some software and you're not receptive to it. Guess what? I'm going to fork your code. I'm going to take your ball and split the split the community. So please, as much as possible, try to kind of come come together. Lesson nine. So this is this is another one that kind of goes contrary to the last lesson that I gave. I was actually very worried that somebody was going to submit a pull request that was going to do something drastically different to one of my projects. And how do you how do you deal with that? And I kind of mentioned this to one of my coworkers. And I think she gave me the absolute best answer that you can ever hear. We are not quite ready for your awesome and then just close the close the pull request. I think that's the nicest way to shut the door to possibly can can do. And then lesson 10. Don't act entitled open source is a gift that you should be giving freely. And conversely, if you're a consumer of open source and something's not working, you should really jump in and try to help the community out and kind of develop that out. So I want to leave you actually with one last thought from one of my favorite presidents be on the road to awesome. Thanks.