 Hey everybody, my name is Joe Sepi and I work for a company called IBM, International Business Machines. We've been around for 100 some odd years and counting and I am an open source engineer and advocate there at IBM and I'm very lucky and fortunate to have this role where I do the majority of my work in the community. I have worked in the Node.js community for a number of years and was a part of the group who helped merge the JS Foundation and the Node.js Foundation into the now open JS Foundation which happened a little over a year ago and I currently am the chairperson of the Cross Project Council which is the top technical advisory committee within the Foundation and we work in the CPC, the Cross Project Council to help projects to be successful, whatever that means for them and support them with infrastructure or security or standards or code of conduct and moderation processes, things like these. I'll also just add real quickly that we meet every Tuesday at the Cross Project Council and we have lots of work to do. If you have any interest in the work that we are doing, please join us. You can find more information on the openjsf.org site slash collaborate gives you links to Slack and the GitHub repose and the calendar and a variety of things that may be helpful. So yeah, that's a little bit about me. Let's talk about contributing to open source. I want to mention at the outset that the kind of center of the road here for this journey is talking about new contributors but I hope that I'll also raise things that will be helpful for maintainers or other seasoned open source contributors along the way as well. So to get things started, I think it makes sense to talk about etiquette and kind of how you approach open source and contributing to repositories in the open source space. I know that this can in some instances be very daunting. I understand that because every time I open up Nodecore to get some work done, I am daunted myself. So I feel your pain there but I encourage you to, you know, once you get over that wall, it's easier every other time and I encourage you to get started. I'll also add that it's when you're interacting with folks in open source, remember to be courteous. Don't be afraid to ask questions. Always assume good intentions. I would recommend that you take some time to read documentation around contributing and the processes that are in place for contributing to different repositories, whether they be, you know, code style, linting or commit message format and things like that. Make sure you put a little effort up front to understand what the project is expecting of new contributors so that you have less friction down the line. And I also encourage new contributors to, you know, be open to constructive criticism. It's sometimes difficult to put code out there and have it critiqued in an open form, have people commenting on it. But this is a great way to learn. It's really, I found the best way to learn and to engage with folks around open source because it really drives you to, you know, think through things thoroughly and to think about edge cases and testing and all these sorts of things. So remember that most of the people in open source are humans and you should assume good intentions and, you know, just dive in. And it's typically a good experience, so I encourage you to do that. Similarly, on the opposite side for maintainers and collaborators in projects, remember that it is daunting for new contributors. So be kind, be gentle. Remember, assume good intentions on both sides, right? There are no dumb questions. Let's be courteous to each other. Be sure that you are contributing guidelines and the things that go along with that are clearly documented like what you expect from commit messages if you are particular about that sort of thing. So, you know, on the opposite side, just make sure that things are in place for contributors to feel welcome and feel enabled and are lacking blockers to get involved, right? So one place that I would start to encourage folks to look at is the community health of a project. So if you know a particular project that you are considering getting involved in, I recommend you go to that repository and you'll notice in the tabs along the top, there is an insights tab. And if you click on that, there's a community sub tab, I guess you'd call it. And within that community view into the project, you'll find links to the code of conduct, contributing guidelines, license. You know, a few metrics that GitHub has determined are good indicators of a project's health as it relates to the community and particularly new contributors. So those are some important things to check out. Of course, you'll want to look at the license and make sure that that works for you. And if you're unsure about licenses, choose a license.org, I think it is, is a great resource for learning more about the different types of licenses and what they mean. As I've mentioned, check out contributing guidelines and such, which are referenced in the community health view there. But probably most importantly, the first place that I would go and look is the code of conduct. So make sure that there is a code of conduct in place. Make sure that you are comfortable with it to make sure that it is extensive enough that it covers, you know, the different areas that you may be concerned with. There is a contributors covenant that a lot of projects use and that's great. A lot of folks have landed on that. I know that there are a couple others, but definitely just make sure that something like that is in place. So there aren't any issues down the road. I think having a good code of conduct is a good indicator that the project takes these sorts of things seriously. And is welcoming to new contributors. And I would also, on the flip side again, encourage maintainers and collaborators to also view this page and see how your repository stacks up there. I'll mention that if you go and look at github.com slash node.js slash node and look at the community health profile. It's in pretty good shape. I mean, I think it's actually in great shape. It looks like it's saying that the code of conduct, I believe, is in the code of conduct or is it the contributing, maybe the contributing guidelines are not fully in place. But if you click through to it, you'll actually find that the node.js project through its years of work has really developed robust processes and guidelines around things like code of conduct and moderation and contributing. The documentation there is very well fleshed out. And I think that you should find that very helpful and very encouraging. These are things that we've been working on for a long time. So if the community health profile looks a little lacking, just make sure to click through and double check for yourself that the computers have got everything correctly. So moving on from, well, let me say actually, I wanted to also highlight this neat trick that I found someone posted on Twitter a few months ago, perhaps, that if you go to a repository, say, for example, node.js slash node, which is the node core repo, if you append slash contribute to any repository, it takes you to this really interesting view that it appears to collect all of the good first issue labeled issues. But it also goes a step further and I believe tries to algorithmically determine other issues that may be potentially good first issues. And I suspect that there's there are some like documentation issues in there. I don't know how it does it, but it seems like it tries to pull out issues that it thinks would be good, good first issues, even if they don't specifically have that label on them. So that's a neat trick. Definitely check that out. There's also a link there for the contributing doc directly from that from that view. So it's a really great place to get started. And again, I'll mention to maintainers and collaborators to also go to that page and see what your project looks like in that view. So moving on, we have talked about the process that a project may have in place to contribute. And you'll definitely want to spend some time going through this documentation so that you can be successful in your contributions. So, you know, I think we've mentioned a couple of times now like get commit messages. Some larger projects are very particular about how you may format these messages code style guide documentation style guide. There are a number of things that you'll want to just make sure you're aware of at the very least, and may want to reference again before you open your first pull request that you are in line with with what is expected. And I did notice today that from the node contributing guidelines, there's this really helpful paragraph that says, and I'll read this directly, if you are new to contributing to Node.js, please try to do your best at conforming to these guidelines. But do not worry if you get something wrong. One of the existing contributors will help get things situated and the contributor landing the pull request will ensure that everything follows the project's guidelines. So these are guidelines that are in place. But, you know, don't feel like it's such a barrier that you won't get involved because there are people there that can help you. Now, another thing to be mindful of are any prerequisites that may exist for a project. You know, Node has some when you first get started and you are running Node locally. There are some things you need to be aware of. And this can be tooling. This can be like underlying dependencies. But also it could be like concepts. So for example, ESLint, which is another OpenJS Foundation project, it's largely based on AST, the Abstract Syntax Tree. And so having a good understanding of how that works will be beneficial to you getting involved in a project like that. So there may be some upfront learning that you may want to do depending on the project. So now I'd like to take a moment and talk about like the typical GitHub open source contributing flow and what that looks like. And it's basically, you know, fork, clone, set your upstream branch, make changes, add those changes, commit, create a pull request. So that's kind of the TLDR really quickly, but I'll just go into each of those for a moment for folks that are new to this process. So you'll go to the repository that you're interested in. So say Node.js slash Node. And from there, you can fork that repository to your own account on GitHub. From there, you'll want to get the Git link or the HTTP link and clone it locally. You'll CD into that directory. And the first thing that I do is I check the remotes. I use Hub, which is a GitHub CLI tool. And so I just typed Git remotes. But I think like Git remote LS, I can't remember exactly, but you can see which remotes are attached to your repository. When you first clone it, it should just have the origin set to your Git repository. So the first thing you want to do is do Git remote add upstream and set that to the upstream repository. So Node.js slash Node in this instance. If you don't have Git configured correctly, you'll want to add your username and your email with gitconfig user.name and the value and gitconfig user.email and the value. So those are a couple of ways to get things set up. It's best practice to create a branch when you're contributing to an open source repository. And this way, if you have a couple of different pull requests that may be open, they don't step on each other. So if you keep everything in a branch, you can work on that branch and know that the next pull request you open isn't going to include these other changes and muddy the waters. So always use branches. You'll basically do your work, the changes that you want to make. And then you'll get add the files that you're going to include in this commit. And I'll say really quickly that it's best to keep your changes to a small set that is focused on a particular issue. Try to avoid larger pull requests that may touch on a variety of things. You want to definitely keep it as tightly knit as possible, as small and focused as possible. So once you make your changes, you'll add those files, git commit, I'm sorry, git add, and then your files or git add period is what I usually use when I'm just focused on one little thing in a branch. Git commit, I typically add my commit message in line, whatever works for you. And then you'll git push origin, your branch, right? So that's kind of the typical flow. Get your repository local, make your changes, git add, git commit, git push. With a project that has a lot of moving parts, a lot of things changing. You may also want to git rebase your changes from upstream so that when you create your pull request, it's in sync with what is the latest. And you may need to do that on an ongoing basis while your pull request is open. But you can do that with git fetch all, git rebase upstream master, and then git push force or force with lease. A note that while rebase is my friend, I think it should be your friend too, but you need to be aware that when you push something with force, it rewrites history. So it can be dangerous, but just use it wisely. I use it all the time. So that's kind of the typical flow. Within that tool that I mentioned earlier, Hub, you can create a pull request directly from the command line. And it's a good workflow to be using when you're contributing to open source. But I wanted to highlight that's not all contributions are code. There are a number of ways to contribute to open source projects. And I think that this is important to call out. So just in general, documentation is always a good place to get involved. In fact, a few months ago, I was working on a Gatsby site, and I found some discrepancies, some things that weren't particularly clear to me. And I just went and cloned the repo and brought it down and created a pull request. And the gentleman that leads that project, his name is Escaping Now, was really very courteous, very appreciative, and I was happy to contribute a really good experience there. So that docs are great. If you have interest in building websites, you know, a website for the project may be in place, and you can help there. Project management, frankly, is something that is always needed in an open source repository. And then there could be other things like social media, community outreach, those sorts of things. And I'll touch on that more in a moment. I'll just also add to that with projects like Node-RED, which is another open JS foundation project, you can contribute nodes to the programming interface. Loopback is another open source project that I've contributed data source connectors to and done work outside of core that's helpful. So there are a number of ways that you can contribute that aren't just the core code or even code at all. So another few ways that you can do that within Node is that we have these concepts of initiatives and teams and working groups. So some examples are the release team, which involves code for sure, because you may be back porting some things to different release lines. But that's always a very active team that you can get involved with. The build working group is another team within Node. There is a website redesign team that's been active for a while, and that's a great place to get involved too for Node. You're writing more kind of front end code for the website. Internationalization is another great place. There are not only the translations that are needed, but also the underlying work that supports the translation effort, the internationalization efforts. So those are a couple of good places. And then I mentioned social community outreach. Node has a newly formed social team. So there'll be a group of us that are actually managing the social media presence. There's, you know, in the past have been community and outreach programs as well, that are great ways to get involved. And then there's a new initiative recently started for examples. So good, straightforward, simple examples for a lot of common use cases. So that's another place that we'd love some more contributions. And speaking of all these things, I want to mention that the collaborator summit was on Monday and is happening again on Thursday and Friday. So that's another great place to get involved in open source and the work that we're doing and the foundation and such. So a lot of people will ask me, you know, how does one get their company to get more involved in open source? And as I mentioned at the beginning, you know, IBM is very supportive of my work in open source. And we have a lot of folks in IBM that are working almost exclusively on open source. But I've worked in a variety of other companies where, you know, it was a little bit more of a struggle to get company time to be involved in open source. And there's an initiative called open source Fridays that I think is maybe started by GitHub. It's a good website that kind of is helpful in trying to do more of this stuff and particularly like dedicating Fridays to it. What I found successful at my time at Behance in Adobe was that we were doing a lot of work in open source. We relied on a lot of open source tooling. And so we took the Friday approach, but we we alternated between one Friday would be like we would call it a bug bash. And we would just try to clear out, you know, bugs in our in our backlog. We wouldn't focus on sprint work and feature work. We would just try to knock out bugs. And then the other Friday we would alternate would be an open source Friday. So, you know, one Friday's bug bash, next Friday's open source, bug bash open source. And so that was a really great, like kind of middle ground compromise that I think could work for a variety of development teams. So you may want to consider that. I'll also point out a couple more resources for getting started in open source. There's the great for new contributors showcase that that GitHub has. There's the open source guide, which is great. It has a whole how to contribute section. There's also a first timers only website. That's a good resource as well. And then I'll do a little shameless plug as well. I've started an open office hours bi-weekly meeting for the open JS foundation and we meet every other week. And sometimes it's just the open office hours on a few occasions we brought in project maintainers, someone from Express, ESLint, internationalization and Node.js. We have a few more that we're lining up after the event. And that's I think a really good place for folks to come and ask questions and to learn about how to get involved in particular projects. So if you go to github.com slash open JS dash foundation slash open dash office dash hours, you can see more there. And that's my talk. I hope that you all get involved in open source. And I hope that it's a really great experience for you. And my Twitter DMs are open. So feel free to message me or if you join the open JS Slack, feel free to message me there. I try to spend some time helping new contributors get involved. So just reach out and I'd be happy to help you too. Cheers.