 My name is Courtney Irvin, I am a platform engineer with Code Montage and that's an open source project so I'm also an open source maintainer. Two years ago though I was not a platform engineer, I was an administrator at a non-profit and when I say administrator I don't mean like systems administration, like IT stuff, I mean I managed volunteers, I planned events, I occasionally used Excel spreadsheets, it was a terrible time. So I've moved on and I'm writing code now and I can honestly say that there's no way that I would have my current position and my current knowledge and skills without having written open source code and contributions. I'm a self-taught developer by which I mean that I didn't pay anyone to teach me, people taught me, I just, they didn't get paid for it, I'm so sorry, but and some of that free learning that I got, free learning that I got was through writing open source code. So I think that it's incredibly beneficial to your career, to your learning, to your growth and so that's kind of why I'm really interested in getting people to write more open source code. Also there are a ton of maintainers out there that just don't have the manpower to maintain projects at the level that they'd like and you can be the change that they deserve. So the first thing you want to think about when you are getting ready to make some open source contributions, pick a project or what your goals are, right? And there are lots of different reasons to get into open source. I would recommend you have two different kinds of goals, a personal goal, something for yourself that has nothing to do or very little to do with your career, right? And then a professional goal that is maybe related to your job, your current job, a future job, something like that. And those goals are going to guide some of the decisions that you make and sort of the projects that you choose and what you're willing to put up with and what you're not willing to put up with. So some of the goals are listed here, new technologies like getting to know a new technology, getting to know how to link up rails with an angular front end or what have you, version control, getting really good at Git and GitHub, getting really good at different processes. Working with a distributed team is a skill, that's a skill. Being able to communicate from a distance and get your point across. Code reviews, maybe you just want someone really experienced to look at your code, a really good way to do that is to give them code that helps them, right? Not just like give them a link to something that you're working on. Visibility, so making sure that other people know that you write code, getting to know people in the community and also helping out the community, right? Giving back to a project that you've already worked with, that you depend on. Giving back to some nonprofit projects, we'll talk about that in a second. And just in general, your goals should be about you and your needs, right? So your goals aren't my goals. One of my goals was getting to know rails because I didn't know it when I started contributing to rails projects. So I learned a lot. And what I want us to do now is just say to yourself, yes. You can do open source code. If you've been holding back because you're afraid, if you've been holding back because you don't think you know enough, you do, okay? I'm going to talk about this in a second. But what I'd like you to do right now is just look around and find someone else's eyes in the crowd. Just look around. It's going to be a little bit like Catholic mass, peace be with you. Make the awkward eye contact. And give that person a thumbs up and be like, you got this. Just now with it. You don't have to say it out loud. You got this, right? Okay, so you have permission to write open source code now. All right? Do it. If you haven't done it before, I've just, someone has given you permission. Take that permission. All right? All right. And we're going to talk about, I'm going to go through, this is, I spent a couple minutes, just a couple, thinking about all the ways that you can contribute to open source. A lot of these don't involve code, right? Bug reports. A lot of times people will put up an issue and they're like, okay, this thing doesn't work. So that's not really helpful to the maintainers, to the people writing code, right? So find an issue. If you come across a bug on your own, do a little research. Share some links, right? Do something to push it forward. Take a video of the bug happening. That's super helpful. Take a pic. Documentation details. A lot of times people assume, or, you know, I have it set up on my computer and it works on my computer, right? Well, that's not really helpful to everyone. So if you come across an issue with documentation, making sure that there is documentation, sometimes people assume that coders know more than they do, right? Maybe they don't mention that, hey, this is in a different version of Ruby than maybe most code is right now or it's in an older version and you might want to use a Ruby version manager. Translations, if you know multiple languages, get someone else's website to work on multiple languages. Creating seed data so that there's a lot of data for other, for new developers to work with so that they can kind of see examples of the code base as they exist in real time as opposed to, for example, if you list a bunch of projects, having only three projects is going to keep you from being able to solve certain issues. So having 25 projects really clearly makes it easier for everyone else. Add some tests. No one writes enough. Do it. Design ideas and reviews, as you'll see in my slides, I am not a designer. I think that they are witches and I respect them for it. And I think that if you know design, share that with someone who does not. Code reviews, right? So go to some pull requests that are already existing. If you know the code, if you're familiar with it, then comment on those code reviews, on those pull requests that already exist and keep someone else from having to do that first pass, right? Help someone else improve their pull requests before it even gets to the people who are on that team. Share ideas for features. You can promote a project that you maybe don't have time to work on, but tweet about it, blog about it, star it on GitHub. That takes a couple seconds and you're still helping that project. Track it on GitHub, so watch it and look for notifications about things that you can help with. Update a library. We're about to be Rails 5. Somebody's going to need help with that, right? So I would suggest you don't do that without talking to the person first, like they may not want that. But update a library or a gem that they're using from an older version. Fix any syntax errors that there are in the code so that the code is more maintainable and easier to read. Fix typos. That requires almost no code knowledge whatsoever. So fix typos that you see on a website. And then finally, and we'll talk mostly about this for the rest of the presentation, code, right? Maybe write some code. That would be nice, okay. So the first thing you want to do is find a project and choose which one you want to work on. And you can do that by just searching GitHub, but there are also a lot of tools that you can use. So Code Montage, the company that I work for, has social good projects that are open source. So open source social good projects, you can search by cause and find something like if you're really into education or you're really into open data, find a by cause and search for a project that you can contribute to and help that organization. Open Hatch has a lot of like little small bite-sized projects. So if you just want to do something really quickly and they have a lot of different languages that they support, GitRec, you put in your GitHub username and it will suggest repos to you based on the work you've already done and your existing profile. That's super cool. 24 pull requests, it's like Advent, but not chocolate. So you write code and you submit a pull request every day for 24 days in December leading up to Christmas. Make some presence for open source maintainers. Contribulator is kind of just the projects part of 24 pull requests. And CodeTriage looks for really, really bad off repos on GitHub and then they suggest them to you. So if you really want to take on like a struggle project, do that. But also if one of your professional goals is like, hey, I want to work for X company, look for their open source projects because their developers are running their open source projects and then they'll be looking at your code. Like who do you think they're going to go to when they're trying to hire but somebody that they've already kind of worked with from a distance. So if there's a company that you really like, look to see if they do open source and try to contribute to some of their open source code. It also gives you a sense of their workflow. It gives you a sense of their team and their communications and their dynamics. So that's really helpful. And the last thing is other developers. If you know other developers, they might have some suggestions. They might have projects they're working on, like reach out. It's a good way to connect with people. So if one of your career goals or personal goals is networking, hey, find somebody and help them out with their project. Okay. And then the next thing you want to think about is the task, the issue that you want to work on and GitHub its issues. And what you want to do here, depending on how you're feeling, right, you should probably make sure it hasn't been solved already. Sometimes they don't get closed until something gets incorporated. But I would check the pull requests as well and just make sure. And then if it hasn't been completed already, just comment on it to say that you're working on it so that it doesn't get solved before you finish, right? If having your code pulled in is really important to you, make sure that you comment and make it really clear that that's something that you're working on. And then know that that comment is a commitment, right? To push that task forward in whatever small way you can. So if you work on it for a couple hours, you don't get through it. And then you don't ever comment again saying like, oh, okay, I didn't get to this. Someone else can take it on. Well, now it's just not gonna get done. So consider your comment, some sort of a commitment. If you don't solve the issue, you can always take the research that you've done and the things that you've learned and comment on the issue again with that information and say, I wasn't able to get through this, but happy to pass it on to someone else. That's helpful. That's a step forward, right? So stop thinking that you're going to solve everything or fix a full feature and think about the small steps you can take to impact a project and to help a maintainer. And know that as somebody who maintains an open source project, any contribution you make is helpful to me. As long as you're in a good spirit about it, you're in a learning space, right? Anything that you do is helpful. Adding a comment, doing some research, that's work that I don't have to do or that someone on my team doesn't have to do. Like we're hungry for it. So again, don't be afraid to reach out and kind of put something out there. Just also don't be really aggressive about it, right? So if you have a feature idea and then you're like, hey, it's been a week, where's the feature? That's not going to be very helpful and it's not going to win you good graces, okay? All right. Another thing to think about before you start working is the community. So make sure that you know, because you're probably going to need help. There are probably going to be people on the team that know more about the code base than you do person just forking it for the first time. And so what you're going to want to do is make sure that you know where that community is. Maybe it's a Slack channel. Maybe it's a HipChat community. Maybe it's a forum somewhere. Maybe it's just an email for one guy, right? Find out what that community is and be aware of it. And also try to get a sense of what the community is like before you get started. That might also be a part of your decision factor. So for me, it was really important to have a community that would be responsive, that would be very kind because I was kind of in a place of like, oh, I don't know what I'm doing, but I'm scared. And so it's good to know what that community is like before you hop in. I would also say that you might want to talk to other coders you know to look for a good community. Another part of the community is like that level of responsiveness. So maybe looking at closed pull requests and seeing how long it took, how long that process took, and that'll help you set your expectations. Okay. So you will want to contact the community when it comes to any big changes that you want to make changing a big library, making a new version of it, adding a brand new feature that hasn't been discussed and isn't listed as an issue. Those are things you might want to reach out for first. Again, if it's important to you to have your code pulled in to the code base. But depending on your goals and depending on what you need, like don't wait for permission either. People are busy, open source maintainers often are not working full-time on that project. So don't wait for permission, but do check in. So I'm going to get into the technical bits of this now. And since most people here seem pretty good with Git and GitHub, and there's no way that I could possibly teach Git in the time that we have right now, we're going to kind of speed through. So the first thing you want to do on GitHub fork the project, right? And this is just a workflow. I know that not everyone uses the same GitHub workflow. This is just a solid one that you can use. And I would recommend a lot of times in the project itself, in the documentation, there's information about how to best go about contributing to the project. So this is a workflow that works. This is the workflow that I use. But it's not necessarily the workflow that's best for the project that you are working on. Again, so starting off fork the project and create a version in your own GitHub account. So that's on GitHub. And then you're going to want to clone your version of the project, your fork, down to your local computer, all right? And know that installing the project, so going through the steps that are listed in the documentation or with Rails, like a lot of us are pretty familiar with how to set up a Rails project. So maybe there is no documentation. Maybe you've taken that risk, which power to you. And you decided like, I know how a Rails project works. I'm going to just set this up and make some contributions and there's no documentation, which should be your first pull request. But just know that you can look at the readme.md file or the contributing.md file. Those are pretty standard. Find the documentation, the wiki, the community, whatever it is, and go through the steps that are listed there. Know that this is the worst part of open source contributing. The installation process is the worst part. So if you are feeling like I'm the only person who's ever come across this error and now I will never be able to achieve my needs with regards to open source, don't. It's normal to struggle. It's normal to have errors. The likelihood is that the person who created the project or the team that's working on the project has it set up and has had no problems. So if you hit an error or a bug, that's really important information for that person to know or for that team to know. Because they might not know that other people are hitting this snag and a lot of people are hitting it and just walking away. And that's people who could be contributing, could be coding who aren't. So what you wanna do is know that you're gonna struggle, push through the struggle, write down the errors that you get, make issues for anything that comes up that's broken and if you can fix it, write down the solution, right? Make a pull request to the documentation that adds information that was missing before. And then the last thing is if you fail, if you're not able to get it installed, those issues are still a way to move that project forward and just move on to your next best choice, right? It'll be okay and maybe they'll fix it and maybe it'll come back. So do your installation, get through it, don't get discouraged and then what you wanna do is celebrate, right? Make it rain, okay? So you did it, that's a really big deal. So if you get a project installed, like that's a big deal. Celebrate it, take a minute, tweet about it. Awesome. Okay, so these are the six GitHub commands that you'll wanna know for the workflow of like this is not my code base, right? Of moving past the Twitter clone that only exists on your computer to someone else's code base up in the cloud. So you're gonna wanna set a remote, which means that you wanna make sure that the headquarters version, the official version is linked to your code as well. So set a remote of like upstream root headquarters banana, whatever you like that is focused on, that is linked to that headquarters version of the code. All right, and then as you're coding, make a branch, name the branch something relevant to the code you're writing. So don't work on master is the takeaway. Name the branch something, write some code, commit, and then push back up to your fork, which should be called origin naturally and originally and maybe you changed it. And then make the pull request through github.com. And this is a GitHub workflow obviously, okay? And then the last part, this pull in rebase is gonna be something you wanna do as you continue to work on a project. So we've already discussed how the install process sucks. So if you have a good project and a good community and you've got it installed, like write more code, get connected, that helps you build that relationship, right? So pull down from the upstream to your master and make sure that your master, that you're always branching off of your master to make new code changes and that your master's always up to date with headquarters. And then rebase is what you'll use if like let's say you worked on something for a long time. So it's been four weeks and maybe that code base, that original code base has changed. So you'll wanna rebase against that original code base. And I'm saying all this just to say that you should know these six commands and how to use them. And if you don't, like this is the process that you'll take as you work on a code base that's not your own or something that you're more closely tied to. All right, so the next step is to code. Just this is a good that way, do it that way. And just understand as you're working and as you're working, maybe you've picked a task that's a little bit beyond you. Maybe you picked a task that requires you to, I'm gonna pause, that's a lot. Maybe you picked a task that is a little bit something new, that you have to research that it's gonna take you a long time. So just make sure that you're maintaining your motivation and that you don't give up because that's a waste of your time. So push through and see it as a learning experience, not as an obligation or I made this commitment and I need to write this code. See it as like, okay, I'm gonna learn something from this some way or another, and that really changes the way that you think about it. Find someone to hold you accountable, another developer. If you get stuck, find someone to pair with. Do your research before you reach out to the community for help. So go into the community with the sense of like, okay, one, two, three things that I tried that didn't work. Can anyone help me? Right, and that's just like basic developer courtesy is do some work before you ask for help and have some responses when people start to ask you questions. And then just know that like I said, everything that you do is some amount of progress. Okay. So your pull request, you've written the code, you pushed it up, you clicked the little button to make the pull request on GitHub. Awesome. Now in your pull request, please don't just make a pull request and submit an empty pull request. This is not helpful to anyone. Please list the changes that you've made in detail. If you made a front end change of any sort, even if it doesn't, even if there's no difference, make a before and after screenshot, especially if you've made a front end change, like CSS changes don't mean anything to the eyes of the developer and there's no reading the mind in terms of like what you changed and what you made different. So screenshots are really helpful. If you made something and it's like a little weak or it created a different bug, write that in the pull request, right, that's okay. If you have ideas for future improvements or it's like half done, maybe not half done, but at a good stopping place but there's still some work to be done, make some lists of like do the to do list of here's some new tasks. Here's some things that you might wanna add to this later. Here's a feature that might be great to depend on this and put that in there and then maybe make issues for them. And just don't do too much at once. So sometimes you'll start working on the code and then you'll be like actually we should refactor all of this CSS to better fit the needs of the other front end developers. Well, that's a different pull request. That's not related to the task that you've chosen, right? Or you start to change syntax or you start to move things around, do that separately. Just keep things very agile, right, different. Each pull request should change a very specific thing because that allows the maintainer to say, okay, you did this one thing really well as opposed to saying like, well, you did this one thing really well but then you did this other thing and I don't need that. And now I can't really separate out which one I need and which one I don't. So be really clear about what you've done and make sure that it's a very boxed off thing, right? I've fixed this issue to one pull request, one change. The other thing that's important with pull request that was important for me because I was in a learning place and I wanted people to review my code was saying specifically like I'm open to feedback. That's really important and that says a lot to other developers, right? So I would say in the pull request because sometimes it can be a little touchy. You want people to contribute to your code base. So you don't necessarily want to call them out and I mean, I don't want to call people out in rude ways and I don't want to hurt people's feelings. So if you say really specifically like, hey, I'm really open to feedback about this. I can see that there are some places that are weak, like please let me know whether something is working or not as opposed to just the opposite or the other option is like just ignoring the pull request, right? No, let me know and I'll fix it. I'm here to fix it. This is not just a one time drive by, right? So make sure that it's really clear that you are open to feedback and constructive feedback. Make changes if they're requested of you and this is more about again, building that relationship and then like I said, do your own research. Fix things when you can. Make sure that clarify things if you have to and take it as a learning experience. Great. Okay, so the last thing is taking all of this work that you've done and how do you make it work for you, whether it's been pulled into the code base or not, right? So we're gonna be patient, we're gonna wait for people to work through and we're gonna wait for people to get to the code and to respond to you but ultimately the code that you've written is code that you've written, it's yours and it exists out in the public realm unlike a lot of code that you may write for your employer. So what I would say is that each pull request is a problem that you've solved. It might be a little problem and it might be a big problem but it's a problem that you solved. So especially if you get to a place where you are writing bigger things or fixing bigger problems, it becomes like its own little bubble that you can take to interviews and use for people to see like this is the code that I write, this is how I write code, this is how I solve problems, these are why I made some of these changes, this is where I got hung up, it's a story in and of itself that you can use in an interview with a potential employer, add a meetup, what have you. I actually, when I was leaving the nonprofit world I went on to become a teacher assistant at Dev Bootcamp and I got hired because I walked through one of my open source code pull requests and kind of talked about all the changes I'd made and the things that I needed to learn in order to be able to make them and why I'd done certain things, right? So a pull request is its own little bullet point, like make a blog post about something that a pull request have you done, tweet about it, add it to your resume if it's substantial enough, like you can focus on this code that you, it's work, it's work that you've done. Similarly, the people that review that code, that work that you've done can become references if you play your cards right, right? So all those people that are reviewing your code, commenting on your pull requests, the maintainers like myself, you know, if you are building a relationship, if you are using enough emojis in your pull requests, use emojis in your pull requests, it's awesome. Confetti ball is a great one, tada, it's awesome. Clap is good, do it, do it, do it. But you know, get your personality across through the communication means that you can. Follow them on Twitter, chit chat with them, like be active in the community, be hype about their project, you know, and that's a good way to build connections and I don't mean in like a smarmy way, right? If you like the contributor, if you don't, then you know, whatever. Here's some code, bye. But you can build those relationships over time and get to a place where now you have references in the community that maybe you wouldn't have otherwise, and those references know your code. It's not like you met at a meetup and exchange business cards, it's not like they're really into your Twitter stream, they know your code, they know the work that you do. So that's pretty awesome. If you add value to a project over time, you can also become like a co-maintainer, you can get like a higher level of responsibility. This might not translate into anything like on the internet, but it will translate into something like being able to commit directly to the code base potentially or being able to review other people's code or being given responsibilities, and again, furthering that relationship that you have with people that you're writing code for. And then I would say make sure that you're tracking all the work that you do, so if you're writing issues about bugs and you're writing like these expansive kind of examinations of a bug, well, that's QA, it is. If you are doing code reviews on other people's pull requests, like that's some lead developer level stuff, you know? If you are, yeah, and if you're writing code like you're a developer, even if you're changing careers or you're from a different background, and I just think that like make sure that all the work that you're doing know that that's work that you've done. It exists, it's there in the world. Whether somebody acknowledges it, whether you get that pull request merged in or not. So build relationships, work with the same project over time, can be really awesome. And the last thing is like, as with all things, your relationships with other people matter. Be kind in the community that you're in. If the community itself isn't kind, find another community, it's not worth it, you know? Work over time to make sure that people get to know you. Take advantage of opportunities if you want to and if you can. One of the best things for me about the open source projects were that I didn't have to come up with the idea. Somebody else had come up with the idea. I'm terrible at the idea part. And at like taking something from scratch but being able to just pick up a problem in a larger pool and with more meaning was really nice. So it's a great opportunity to work together and to collaborate and you should build those relationships and take advantage of it. So be kind to yourself. Write open source code. Worst comes to worst, like I said, code montage is open source. So if you wanted to submit a full request to go to montage, that would be awesome. And so that's it. Thank you guys very much.