Developer Diaries | Week 14 - Hacktoberfest Time!

Happy October! It's one of my favorite months. Why?

Because some of us in the dev community celebrate...

HACKTOBER FEST!

It's a whole month long celebration of Open Source Software and learning how to contribute to code together. I started celebrating about two years ago, and I credit it with connecting me with other developers who graciously held my digital hand and guided me into the world of code collaboration while I was a baby developer terrified of pushing any of the wrong buttons.

So this week's post is a tribute with some info, like how to get involved, how to write your first PR, and projects I'm contributing to this Hacktober. Enjoy!

How to Get Involved

Head to the Hacktoberfest website and connect with your github account. (Don't have a github account? Now's a great time to get one! It's easy to set up.)

Once you're registered and connected with Github, it will automatically track your successful PRs and show you progress updates.

The goal: Complete 4 successful PRs in October, and ... YOU GET A FREE TSHIRT

[insert oprah gif a out you get a car]

Not gonna lie, I do this for the open source celebration, but also for the t-shirt.

Okay now it's time to find some issues! (Not sure what that means? Keep reading.)

Here are some good resources for finding issues:

-

Writing Your First PR

Okay so how does one exactly "make a PR"? I'm glad you asked because the first time I did Hacktoberfest, I was pretty confused. Here's some lingo you'll hear and what it means.

• repo: A repo is where a project's code is stored. This is typically on Github, and its basically like a Google Doc of all the code related to a project. When contributing to a project, you need to fork that repo and clone it on your local machine. But I'm getting ahead of myself with lingo.
• fork: Imagine you spent years building a project, and then someone came in, changed a few lines of code, and the entire app went down. That would be tragic right? We don't want that. So Github makes it reallllly hard to do that, and one way is by having a contributor say "this project is cool! I'm going to grab it and bring a copy of it to my house and then add some cool stuff on to it, and then I'll send it back to you and you can decide if you want it." The "fork" is when you tell it go over to your house. The "clone" is when you actually open the door and let it come inside. (I... guess that's a good metaphor?)
• PR/Pull request: Let's stick with my analogy. A PR is when you've played around with the code inside your house, and you want to let the other person see your changes and if they like them, bring them into their code. So you create a "pull request" where you're asking them to pull your changes (from your fork) into their code- the main codebase/repo!
• issues: We've all got issues, but no one has more than Github 😂. An issue is like a ticket saying "hey this is something I need done in the code". It could be a bug that needs fixing, or a new feature they want implemented. It could be something really small, like adding a target=_blank to a link, or it could be really large, like building a new page and components in an app. When you want to help out with a project, you want to start by looking at a repo's issues and pick one, then you'll reference that issue in your pull request.
• contribution guidelines: Look for a file called contribution.md or contributing.md typically in the root folder of a project. This is kinda like instructions for when you want to send your code back to the original code base so you know what they're hoping for.

Don't worry if these terms don't all make sense... it can take a while to get used to.

Pro-tip: Download the Github Desktop app. I spent a lot of time learning Git on the command line, and while it comes in handy sometimes, it's not essential for a newbie and if you're feeling intimidated with git and github, don't force yourself to stress about command line right now :) ESPECIALLY when cloning repos locally after you fork them. It's much easier to follow the UI as it walks you through it and uses normal language to help you understand what you're doing.

Don't worry if you're still feeling intimidated. Github makes it really hard to actually break anything, so no matter what you do, you don't have enough admin rights to actually destroy anyone else's code, so you really can't hurt anything, no matter what buttons you click. Also, ask questions in the issues. Code maintainers are typically super happy to help newbies get familiar with the PR process and answer any questions.

Projects I'm Contributing To

This year, I've found two projects that I'm helping out. Team Vibhav (that's the place where my fix was as simple as making some links open in a new tab), and AnitaB.org where I'm helping set up Prettier and Github actions, add routing, and add a documentation link section for each of their projects. Feel free to come join the party over there and grab some issues!