 Josephie here, I work for a little company called IBM and I'm happy to talk to you today about contributing to open source. It's kind of core to IBM and we've been involved in open source for a really long time dating back to maybe even before the Linux foundation, the Eclipse foundation like early open source kind of stuff and have been continuing to do that for many years and we have a lot of folks who are deeply involved in the open source space, the work, the code, the community, the foundations, things like that. I have been a part of the NodeJS community for some time and was a part of the NodeJS foundation. I also helped to merge the NodeJS foundation and the JS foundation into the newly formed open JS foundation which you know newly formed is a little, it's been a couple of years now so but the open JS foundation is where I spend a lot of time, my time now in addition to the NodeJS space and I'm the chairperson of the cross-project council which is the kind of advisory committee, the top committee in the foundation that helps get things done on a day-to-day basis, you know trying to help projects and provide things of value to projects as well as the community and our member companies but really focused on what would best serve the projects in their communities. So yeah that's kind of how I spend my days but I wanted to talk to you today about contributing to open source. You know perhaps some of you are already doing it, some of you are perhaps new to it, I'll try to touch on a variety of things here to make the talk interesting to a variety of people. So let's first talk about like etiquette I suppose. You know it could be daunting to get involved in open source but I encourage you to do so, I believe if you're watching this talk then you have an interest there. You know I think just kind of getting over the first hurdle or two, you know you kind of get in the door and realize that it's not as daunting as it may seem at first oftentimes. Typically the communities are very welcoming and they encourage new contributors and try to have things in place so that new contributors can easily get involved. Yeah I think the number one thing is to be courteous and respectful and consider it and remember that you know we're all just humans trying to get along here and write some code and build some applications and whatnot. So yeah just you know be nice and be respectful and you know I guess sort of along those lines to look at the ways in which the project is set up and the things that are in place to help you along your path and contributing to the project so contributing guidelines obviously being one, check out procedures and the guidelines there. Sometimes there are specific ways that they want commit messages for example or you know you'll want to get your project set up with the things like style formatting and such you know tabs versus spaces for example or you know what have you you want to you basically want to have as little friction as possible and getting your code merged upstream and so being aware of those processes and guidelines and such is really helpful and when you do submit your code you want to spend the time in pull requests talking about the code and what's happening there and not spend any time talking about styling or commit messages for example or you know semi-colons or not or what have you you know try to get aligned with how the project functions and then focus on contributing in that manner and then you know in pull requests again remember we're all just humans and so you know maintainers I encourage you to be constructive in your criticism and your critiques and contributors you know act accordingly as well be courteous and know that you know by and large these sorts of conversations are meant to be productive and you know work through these issues for a lack of a better term so that's a little bit on etiquette you know another thing we can talk about is when you're looking at projects to get involved in you want to kind of take a look at the community health of the project itself the best way or one way I supposed to do that is to go to the github repo and under the insights tab there is a community section and github helpfully tries to show you what the community has considered important in terms of a project being welcoming and healthy uh so you know number one a code of conduct um you want to make sure there's one in place it's best to kind of look at it and examine um what's in the code of conduct there are a few that are templates or starting points or or or um you know like the contributors covenant is a very common one that you can basically copy and and pull into your project that's the one that we primarily use at the open js foundation and such in that section you also find the contributing guidelines uh is another one you'll want to check the license to make sure that it's a project that you'll um you don't want to be contributing to um there may be rules that if you're a part of a company as to what kind of licenses uh you're able to contribute into in terms of open source another kind of shortcut to check out is if you go to a repo on github um you know it's github.com slash org slash project if you also add a slash contribute to the end of that url so for example github.com slash node j s slash node slash contribute um there's a auto generated page that'll come up um and highlight good first issues and um typically it'll highlight the um contributing guidelines and the code of conduct uh so that's that's really helpful too and it's a good segue to mention if you're looking to get into a new project uh that's a great place to look is to go to the issues look for the label good first issue um help wanted is another common one um you know try to to suss out any labels that the project has deemed appropriate for new contributors coming in and getting involved so that's that's um you know another another place to uh to look at so we'll just take a quick moment to talk about like the github open source contributing workflow and um I'll talk through this a little bit but you can certainly uh look on the internet for for more uh in-depth guidance along this sort of flow uh but the the for for folks new to this um basically you find the project that you want to uh contribute to you will fork the project into your uh space on github and then uh clone it locally um and then what I typically do is I go into that directory and I list the remotes uh that are there and and you know usually when you clone a repository uh you just have your origin uh which is set to your um fork of that repository so you want to add an upstream uh uh destination for your repo so you know get remote add upstream and then the um uh get url or uh get um what do you call it uh and then you'll see if you do a list of remotes again you'll see an origin and an upstream and one should point to your fork the origin should point to your fork upstream should point to the upstream repo um if you're really new to to to get then you know you want to do things like configure username and email and such um but again you know use the internet machine to to find all that stuff so once you have the repository locally and you have set your upstream um and you're ready to do some coding the process typically is to create a branch you know so get check out dash b dash b my branch um and you can set some tracking uh to upstream master if you desire uh it's a common practice I just I just do get check out branch and start a new branch and get rolling so you've got your branch now you're in your branch uh no longer in master but in your branch that you're going to do your work write some code um add your files you know get add uh period or get add specific files that you want to add to your commit uh run get commit uh you can do dash m and put your message in line or or have um your your terminal prompt you for a message um and then you'll push your push your changes to your fork to your origin and then from there you can open a pull request that will compare your changes to uh the upstream and you know once you submit that pull request then the process begins where the maintainers of that repository will review your code and comment on it and um you know whenever the process is there uh hopefully you end up in a spot where your code will be merged into the repository so it's great um that's kind of the typical uh the typical flow um you know one one way that uh I think is very common for this sort of flow to happen is if you are um looking at a new project to to use maybe you're not even thinking about contributing necessarily and this happened to me one time so um a couple years ago uh Gatsby was um uh something that I was considering using for a project and so I wanted to learn more about it and I started to read the documentation and um noticed a thing or two that were pretty minor but I was like well you know I might as well contribute it back and make some some updates here so I went through that flow you know uh forked it cloned it set my upstream and created a branch and then as I worked through the documentation um whenever I found something that I thought uh you know something I think one or two things were like grammatical uh so I fixed those and then if I was working through something and it didn't it wasn't clear to me um and I thought I could add value to the community and the project by making it more clear um I would I would make those changes in the documentation and then um you know I I got to a logical stopping point and had a few changes uh put it all together in a commit and pushed it up and um the the the the lead maintainer there his name is escaping me now but uh was super nice um one of the things that I had corrected um was like kind of auto-generated and so that uh we we discarded uh but the other changes uh he was happy to take upstream and uh again was very polite and was really uh very easy to work with and um you know I appreciated uh contributing there and so that's like a common workflow that that uh people might find themselves in just kind of going through some some documentation and it's a real easy way to get involved because you don't have to you know have that stress of I don't know this project super well and is this really the right thing or whatever or you're like I'm in fact coming to the project uh fresh and contributing to documentation like that is really helpful because your fresh eyes and typically uh you know a a a non insignificant amount of people coming to the documentation um will will be new to it as well and so adding that context and and such uh and making it more uh digestible for new folks I think is uh you know really valuable so that's a great way to to start to get involved right um so let's talk about uh you know contributing to open source isn't just code right um I think a lot of people that's what they think of first and that makes sense but there are other ways to contribute to open source as well so documentation is one of them uh which we just kind of talked about a little bit uh sometimes um oftentimes the project's website is in the organization as well and so if you see something on the website that needs you know there's an error or what have you uh you can contribute there in fact uh the project has uh had a long running um uh set of work to redesign the NodeJS.org website and it's coming along pretty well but we still need some help and so if you're interested in uh Gatsby and and React and um you know doing kind of front end work uh helping implement this design and making some improvements along the way uh please by all means get involved that's a that's a great way to help the NodeJS project is to help work on the new website um if you go to NodeJS.org repository you should see um a repo for NodeJS.dev is that right let me look that up really quickly uh yep NodeJS.dev we call the the the working group um the web design uh redesign website redesign um working group are we a working group I can't recall now anyway uh regardless uh that's a great place to to get involved so if you have any interest there please get involved um you know in terms of other ways to get involved in open source you know project management of some sort uh you know is is sometimes needed the website redesign work we you know having somebody to help kind of manage the work there and to have visibility over the overall effort and keep on track for like MVP work and such um you know that's that's a need that we have I'm sure uh there are other projects that are similar and I think even along those lines you know helping a project to manage the work that is going on there um is is helpful so like in Node we have a triage role um express uh establish something as well and um being able to help uh triage issues and pull requests and things of that nature is valuable uh really valuable so that's something to consider and then just even um you know getting involved in uh social aspects or community or outreach or things like that um for a project like Node we have uh we have um efforts uh initiatives along those lines as well uh and mentorship is another one um and uh you know so those things are really valuable I'm also reminded of we have a internationalization project as well that's that's doing um not only doing translations um of documentation and such but also the tooling that goes involved that is involved in in managing those translations and those contributions and such so you know that's another great area that someone could get involved um either the translation work itself or the work on the tooling that helps us manage the translation work uh so those are a few few um you know ideas in terms of um you know not just working on the core aspect of the project but the things that sort of go along with it as well um a couple other things that come to mind the release team for for Node that's really important work uh the build working group in Node is another one uh we just started a initiative uh called uh examples so trying to put together common use cases and such um using uh common tooling and and frameworks and what have you so that's another great place to get involved so there's there's lots uh going on uh in the node space and I imagine that's a lot of other communities have similar uh concerns and needs and such so so those are some ideas um you know another thing that I wanted to talk to you all about is how to do open source on company time um and there are a number of ways that I've seen this done in the past um there's this concept of open source Fridays I think if you again look on the internet you'll you'll find uh something um I think there's a whole website dedicated to to that initiative and uh whether it's like formal or informal it's a great way to to kind of get your team uh your organization your company more involved in open source is to take a Friday you know maybe once a month or the way we used to do it at Adobe which was really um great and we kind of had this slotted into for a time we had this slotted into our um sprint schedule where Fridays were always set aside uh to do non-sprint work and so uh we alternated every Friday between um you know one Friday would be uh crushing bugs and and technical debt um and working on those sorts of things that were outside of our sprint uh efforts and then the opposite Friday would be working on open source which we you know used a lot of open source tooling um we tried to contribute back we even had done some hiring through open source the people that we were working with in the communities um so we you know really um were dedicated uh to the open source efforts and so we would just alternate you know the first Friday would be bug bash the second Friday would be open source and you know we just uh alternated those and so that's a great way to to to kind of slot in some company time for open source work um I'm super fortunate that I I work at IBM and we really value um doing open source we value uh being a part of the community we value the level playing field that uh foundations and open source work uh creates um and we use open source in um a lot the majority of our our products and such platforms so um open source is super important and I'm lucky that I work at a place that's um you know they pay me to to focus on that stuff so if you can the best way is to get into a company that that that shares that um that value as well um the one thing I want to double back on uh in terms of Node.js is that you know some projects are easy to to get involved in and the um the the the the barrier to entry is fairly low that's maybe not as much the case with Node.js I mean I think um there are uh really great things about Node.js in terms of getting involved in open source I think you know the the the the one that comes to mind immediately for me is that it's a really fantastic community of people um who are really passionate about the work and the platform and um and so that part is really great uh but but getting Node.js up and running and um knowing how to contribute and where to contribute and what to contribute is maybe not as easy as other projects um and that that may be similar to other kind of uh platforms or um projects like Node.js um but my point is the or the point that I'm trying to get to is uh the way that I recommend people getting involved into Node.js is to look at the uh working groups and the teams that as well as the initiatives that are being worked on and try to get involved there um and then through that you can start to contribute and so an example is uh like I mentioned the website redesign work you know there's there are um uh are there weekly meetings now I think most of our Node.js meetings are are bi-weekly every other week the website redesign team might have started meeting weekly to try and keep progress really moving forward um but essentially um we've we've we've tried to do our work in the Node.js space uh for for many years as uh publicly and transparently as possible and so um number one the calendar is public it's a google calendar that you can subscribe I haven't integrated into my personal calendar um and so I see all the meetings that are happening uh the the build meeting the releases meeting the um you know the uh website redesign meeting com com tsc I think tsc is maybe the only one that's not uh totally public um but all the other meetings are public and um observers are welcome to join and see what's going on and that's the that's the best way to get involved because you can um you can you know lurk for lack of a better term observe uh what's going on what the focuses are uh where the team is is trying to go and when you feel comfortable um you can offer to help um or you can start to follow some of the issues and the pull requests you know another way that we try to be uh public and transparent is to do all of our work in in uh github um so documentation issues pull requests all those things are publicly available easy to contribute to and uh also easy to just kind of follow along and see what's going on and get involved and the good thing about getting involved in one of these teams or working groups is is you start to know the people that are there and um again they're they're by and large uh really good people who are happy to have other folks get involved and happy to support them and in getting involved um and so you can volunteer to do a bit of work and then you have the folks on the team who can support you in doing that work uh so if you have a question like you know my branch is is is out of uh uh sync with master and these merge conflicts i got to figure out and you know can you help me walk through this or what have you um you have those folks in place that that are there and happy to uh to kind of help you essentially help them you know help each other help the community uh get work done so that's that's really uh in my experience in my opinion the best way to get involved in and Node.js is to start to work with a team and uh they they should be easy to get involved with either looking through the calendar you go to the Node.js or God GitHub and and look through um the repos and you'll see you know the internationalization team you'll see the community committee you'll see um you know like i said the the release team the build working group um the the NAPI team uh modules modules actually maybe uh retired or retiring i can't recall uh but my point is you can see these groups in action you can look at their meetings in the calendar you can look at their issues their pull requests and things like that and find ways to get involved so that's what i that's what i recommend um yeah so i think that's that's kind of my my talk here um definitely reach out to me if you have any questions my dms are open on twitter joe underscore seppy scpi and um yeah thanks for having me