General

How to Make Your First Pull Request for Hacktoberfest

Linda Thompson
12 min read
How to Make Your First Pull Request for Hacktoberfest
This article was written over 18 months ago and may contain information that is out of date. Some content may still be relevant, but please refer to official documentation for the latest information.

Leaves are changing color. Pumpkin spice flavors are everywhere. Yards are decorated with skeletons, ghouls, and spiders. It must be October in the US! This means it's also time for Hacktoberfest!

What is Hacktoberfest, exactly?

Hacktoberfest is a month-long event that celebrates open source software, and encourages everyone to get involved. Whether you participate through creating pull requests for your favorite projects, opening your own project to support from others, hosting an event, or donating directly, Hacktoberfest is a way to encourage the global community to help make the world of open source software a better place.

How does it work?

To participate, sign up directly on the Hacktoberfest site. You can sign up anytime during the month of October.

Projects on GitHub or GitLab can opt in to participate by adding the hacktoberfest topic to their project. You can often find issues that will have the hacktoberfest tag added to them. This means they're open to support on solving these issues, and that it will count towards your participation!

There are only a few simple rules:

  • Pick an issue you'd like to work on from any participating project and write a solution.
  • The solution must contain text and code you wrote yourself - no copying, no bot scripts!
  • It's also important to make contributions that provide value to the project. Find ways you can contribute that actively help the project, its maintainers, and the people who use it. Documentation is a GREAT way to get involved. Or maybe there's an issue you've run across while using it that you found a solution to. The key is to add value- some fixed typos and small writing changes are great, but try to avoid simply formatting files or something like adding your name to a list. Quality over quantity!
  • Submit your solution as a pull request (PR) on the project's page.
  • Your pull request counts towards your participation when it's approved by maintainers, has been merged into the project, or is marked with the hacktoberfest-accepted label.
  • Do this 4 times in the month of October, and you're good! The first 50,000 people with 4 approved pull requests can either get a free t-shirt or have a tree planted in their name.

Is This Dot Labs Participating?

We are! This Dot has a number of repositories for resources we share with the community year-round. And this year, helping us keep these resources accurate and up to date counts towards your Hacktoberfest progress!

Here's the list of repositories we have enabled for Hacktoberfest participation:

For all of these repositories, we're looking for YOUR help in growing our library of resources, ensuring the data we have is still accurate, and helping to make these resources easier to navigate. Have a resource you love that you don't see listed? Try to check a resource out and the link no longer works? Great at organizing, and want to create a table of contents? All of this help is greatly appreciated!

Ok, but what IS a pull request?

Great question! Let's create an actual pull request on one of these repositories, and see how it's done!

What You'll Need to Get Started

First, you'll need to have an account on GitHub. If you don't already have one, you can sign up here.

You'll also probably want a code editor. There are a ton out there to choose from. However, GitHub has also added the amazing ability to run a web-based version of the popular editor VS Code, which is what we'll use!

Step 1: Find an Issue to Work On

For this walkthrough, we're going to add some excellent tech podcasts to the Podcasts repository! So we'll go visit that webpage and double check to make sure the podcasts we want to add don't already exist in the list. In our case, we're in luck, and we have a few to add that don't already exist in the project!

Step 2: Make a Copy of the Repository to Work From

To add your own work, you'll need to make a copy that's tied to your account. To do this, we'll make a fork of the repository. You'll find this button in the upper right hand corner of the page. Click that, and it will ask you where you want to make the fork. Pick the account you want to work from (often you'll only have one account, but some folks might have a separate work account as well).

Screenshot of the thisdot/tech-podcasts repo on GitHub, with the cursor pointing over the fork button in the upper right hand corner.

GitHub will do a little magic, and we'll now have our own version of the project! 🎉

Some projects will also have a mention in the README file of their project pointing to contribution guidelines. Make sure you read this if you're wanting to work on this project! It will give you any specifics for running the project and submitting the pull request when you're ready.

Step 3: Create a New Branch to Make Your Changes On

It's almost always recommended to create a branch when you want to make changes on a project. This provides the maintainers with a way to view what's different between your changes and the current, up to date project, and ensures that anything that accidentally breaks the project isn't automatically pushed live when the changes are saved.

So, let's use this web-based editor! Once GitHub has redirected you to your personal copy of the repository, simply hit the . on your keyboard, and watch the magic happen. 😎 It should load the editor directly in the browser window, and once it's done, you'll see something like this:

VSCode editor open to the CONTRIBUTING file of the repository

And we're in! Now, we want to make a branch to work off of. We can do this in VS Code by clicking on the third icon down the left-hand list, the one with three small dots and lines connecting them. If you hover over it, it will say "Source Control". Then, from the menu in that panel, we'll create a new branch for our changes.

Showing the menu open and the mouse pointer hovering over the create new branch option

You'll want to name your branch something that describes what you're working on. If the issue you've picked up has a number associated with it, be sure to include that too. The editor will open a box for you to put in the name you've picked, and will ask if you want to switch to that branch. Switch over, and we're ready to work!

Step 4: Make the Changes!

Now, let's add those changes! I'm going to add a few podcasts I enjoy in the categories they fit best with, and provide the links to them. Make sure you save the file as you go, so you don't lose your work! Any lines you've edited will be highlighted on the left hand side, so you can quickly view where your changes are.

README updated with a few new podcast titles and links, showing what new changes look like

Step 5: Commit Your Changes

Once you've made the changes you want to make, tested your code, spell-checked your text, and you're feeling good about your work, it's time to get those changes pushed onto your copy of the repository.

There's a few steps here:

  • Add the changed files to our source control list
  • Make a commit - a description of the work we did, tied to a uniqiue identifier
  • Push the changes to our copy of the repository

If you've noticed, the "Source Control" icon we clicked on earlier will now have a little circle with the number of files we've updated on it. Click into this menu again, and we can do all these steps from here!

We'll see a list of the files with changes made. Next to each file, there will be some icons on the right side. For each one, we'll want to click the little + icon, to stage those changes. If you have a lot of files to add, you can also click the + icon from the "Changes" section as well to add all of them at once. We'll now see that these files have moved from "Changes" to "Staged Changes".

Source Control menu with the mouse pointer hovered over the plus sign

Great, now our changes are staged and we're ready to write our commit! In the text input at the top of the section, write your message - a short description of the work you did. Spaces are allowed here and there's not a hard length requirement, but try to keep it fairly short and succinct so others can quickly tell what changes we made.

Dialog filled in with "added 4 new podcasts to the list"

When you're satisfied with the message, press ctrl and enter together, and the editor will automatically commit those changes to your branch!

Step 6: How to Open a PR (Pull Request)

The moment you've been waiting for: we're ready to make an official pull request to the main repository! Since we've been using GitHub's web editor, we'll create our pull request directly from the same editor! And I'll also show you what it would look like from the main repository view as well, if you work from a local editor instead. Both options will need the same information, but the visual is a little different.

GitHub will be able to guess a majority of the information for you, but there's a few things to point out.

  • You'll be selecting your branch from your copy of the repository, and sending it to a branch in the remote / original repository.
  • Double check that it has selected the right branch from your copy of the repository. You should see the name of the repository with your user name before it, and the name of the branch you want to submit.
  • Also, make sure that the original repository you're sending it to is correct. It should show the company name, followed by the project name, and the branch you want to send this to. Often, it will be "main", but sometimes projects will want you to submit your request to a different branch. Make sure you check for a contribution guide if they have one!
  • Write a title for the request. This will be shorter than the commit message we made before, and describes the work we did overall.
  • Write a description. This will be a bit more in detail on the work we did. Some projects might have checklists of things they want to make sure you did, or they might want a list of the commits you created. There's no wrong way here - just make sure if the project specifiew what they want here, that you follow that!
  • When you're ready, click create!

From the Web Editor:

There's a button at the top of the "Source Control" menu that has a straight line next to a curved arrow with a plus sign (it's the second from the left side). Click this, and it will open the menu for you to fill out.

Web Editor showing the button to click to open the pull request menu Filled out pull request in the web editor

From the Website:

You'll often see a colored bar above the repository when you've got a branch that's able to be used for a pull request. Click the green button inside of it that says "Compare & Pull Request", which will take you to the form to fill out.

GitHub website showing the pull request button GitHub website pull request form

Step 7: Adjust for Feedback & Wait for Approval!

And that's it. Our pull request is created! The project maintainers can now view the changes you've made. You can see your pull request on the main repository's page, under the "Pull requests" tab.

View of our newly created pull request

Often, there might be changes they'd like you to make, or questions they want to ask about the work you've done. Be polite and honest, work diligently to make the requested changes, and ask questions if you don't understand something! When you make the changes, you can add those changes directly to your branch on your copy of the repository, and the pull request will be automatically updated. Just leave them a comment on the pull request view so they know there's new changes to review!

Once the maintainers are satisfied with your work, your pull request will be approved and merged into the project! Then you'll get to see the work you've done directly in the main repository and on the live site (if they have one). Excellent job!

You're Ready to Help Open Source Projects!

Now that you know how to create a copy of a repository, find issues to work on, complete that work, and submit the pull request for it, you're ready to complete your 4 pull requests and win a sweet t-shirt or have a tree planted!

Here's our list of repositories that are accepting contributions for Hacktoberfest again:

Feeling like you're "too new" to coding, and aren't sure what you can work on? Try filtering your searches in issues by labels like "good first issue" or "help wanted"! And also, helping with documentation is a fantastic way to start to get involved! It's often hard to keep up with documentation, but incredibly vital to helping new folks start using a tool. Figuring out how something works or updating the docs with current information is completely valid and worthwhile!

The Hacktoberfest site also has some great resources for finding issues to work on for beginners and intermediate folks!

We also have some great open source tooling that we're working on! We'd love to have you check these projects out and let us know what you think! We're always open to suggestions for how we can improve them and other tools you'd like to see: This Dot's Open Source Projects.

Good luck on your contributions! We're so excited to see what you work on, and welcome your help in providing excellent resources for the community!

About the author

Linda Thompson

Linda Thompson

Software Engineer

Keep reading

View all posts →

Remix Deployment with Architecture

Intro Today’s article, will give a brief overview of the Architect framework and how to deploy a Remix app. I’ll cover a few different topics, such as what Architect is, why it’s good to use, and the issues I ran into while using it. It is a straightforward process, and I recommend using it with the Grunge Stack offered by Remix. So let’s jump on in and start talking about Architect. Prerequisites There are a few prerequisites and also some basic understandings that are expected going into this. The first is to have a GitHub account, then an AWS account, and finally some basic understanding of how to deploy. I also recommend checking out the Grunge Stack here if you run into any issues when we progress further. What is Architect? First off, Architect is a simple framework for Functional Web Apps (FWAs) on AWS. Now you might be wondering, "why Architect?" It offers the best developer experience, works locally, has infrastructure as code, is secured to the least privilege by default, and is open source. Architect prioritizes speed, smart configurable defaults, and flexible infrastructure. It also allows users to test things and debug locally. It defines a high level manifest, and turns a complex cloud infrastructure into a build artifact. It complies the manifest into AWS CloudFormation and deploys it. Since it’s open source, Architect prioritizes a regular release schedule, and backwards compatibility. Remix deployment Deploying Remix with Architect is rather straightforward, and I recommend using the Grunge Stack to do it. First, we’re going to head on over to the terminal and run npx create remix template remix run/grunge stack . That will get you a Remix template with almost everything you need. Generating remix template For the next couple of steps, you need to add your AWS ACCESS KEY ID and AWS SECRET ACCESS KEY to your repo’s secrets. You’ll need to create the secrets on your AWS account, and then add them to your repo. AWS secrets GitHub secrets The last steps before deploying include giving CloudFormation a SESSION SECRET of its own for both staging and production environments. Then you need to add an ARC APP SECRET . Adding env variables With all of that out of the way, you need to run npx arc deploy , which will deploy your build to the staging environment. You could also do npx arc deploy — dry run beforehand to verify everything is fine. Issues I Had in My Own Project Now let's cover some issues I had, and my solution for my own project. So, I had a project far into development, and while looking at the Grunge Stack, I was scratching my head, trying to figure out what was necessary to bring over to my existing project. I had several instances of trial and error as I plugged in the Architect related items. For instance: the arc file, which has the app name, HTTP routes, static assets for S3 buckets, and the AWS configuration. I also had to change things like the remix.config file, adding a server.ts file, and adding Architect related dependencies in the package.json. During this process, I would get errors about missing files or missing certain function dirs(), and I dumped a good chunk of time into it. So while continuing to get those errors, I concluded that I would follow the Grunge Stack, and their instructions for a new project. Then I would merge my old project with the new project; and that resolved my issues. While not the best way, it did get me going, and did not waste any more time. That resolved my immediate issues of trying to get my Remix app deployed to AWS, but then I had to figure out what got pushed. That was easy, since it created a lambda, API gateway, and bucket based on the items in my arc file. Then I realized, while testing it out live, that my environmental variables hadn’t carried over, so I had to tweak those on AWS. My project also used a GitHub OAuth app. So that needed to be tweaked with the new URL. Then it was up and running. Conclusion Today’s article covered a brief overview of what Architect is, why it’s good to use, how to deploy a Remix app and the issues you might have. I hope it was useful and will give others a good starting point....

William Hutt4 mins
RemixOpen SourceArchitectureAWS

Introducing Vue and Angular Versions of Framework.dev + New Landing Page

Our team created Framework.dev to help developers feel less overwhelmed when researching technical resources. We appreciate how important it can be to have a starting point when it comes to learning a new technology, or keeping up to date with the latest developments in the OSS community surrounding a stack. Previously, we started with just React, but our solution is deliberately extensible, and designed to be themed and filled in with different content for different frameworks. That's why we are happy to announce our new Vue and Angular versions for Framework.dev, a series of websites dedicated to cataloging resources to learn and develop in a given frontend framework. Our newest versions have the same features as the React version, which allows developers to search, compare, and discover libraries and resources! By adding tags and filters with a number of different attributes to all resources, and also making all the titles and descriptions searchable, we make the task of finding what you are looking for way easier. And who knows? Maybe in that search for finding out which library is the best for your needs, you ended up encountering one which you have never heard about before. Or perhaps you are just not sure which one to choose because all the options are solid. Well, we got you! With Framework.dev, you can compare libraries to look at metrics like the number of downloads, test coverage, and Github stars so you can get an idea of how popular and well supported it is. To help you in these decisions, we've made it so you can take any set of libraries, and arrange them into a sortable table with a number of useful statistics sourced from npms. Our New Landing Page Since our plan is not to stop here, but to keep updating and making the site much bigger with more resources, frameworks and more, we decided that it was time to launch our landing page! This is where you can easily access the framework you are most interested in. Take a look at it! Help Build and Curate the Content! We are just getting started, and we know there's still a lot of content to add and cover! Framework.dev is hosted and maintained by This Dot Labs, but is a fully open source project. No single person can keep up with how the frontend framework ecosystem constantly evolves and changes, but we might just stand a chance if we work together. Framework.dev is made for the community, and we hope community members will be inspired to enrich it. Do you have a favorite book that you think others should know about? Do you know about a cool feature that we could add? Did you encounter a bug? Then go look at our contribution guidelines and contribute to Framework.dev today!...

Jesús Padrón3 mins
ReactVueAngularOpen Source

How to Contribute to Redux with Mark Erikson

We are kicking off a brand new series of videos in 2022 to help developers learn how they can contribute code to some of the world’s most popular JavaScript frameworks and technologies. Subscribe to This Dot Media’s Youtube Channel. For those interested in React state management, I sat down with Mark Erikson, maintainer of Redux recently! If you would like to check out that interview, you can see it here. What is Redux? Redux is an open source JavaScript library that helps developers manage and centralize global state in their large scale applications. By wrapping state in a store, you can alert all code that subscribes to the store of updates to the state. Mark Erikson Mark Erikson started contributing to Redux in 2016. After working with JavaScript and Backbone for years, Mark began learning React and Redux, which eventually led him to a chat channel called Reactiflux. While hanging out on these channels, he noticed a ton of people asking the same questions, which inspired him to volunteer to write an FAQ page for the Redux project. Shortly after, Redux co creator Dan Abramov gave Mark commit rights to the repository, allowing him to triage issues and answer questions. This goes to show anyone can contribute to open source you just need to get started! What to Know Before You Get Started Before jumping into contributing to Redux, it's important to know a few key things about the repository: There are three primary repositories within the Redux org. These include redux core, react redux, and redux toolkit. Redux toolkit is how the team wants people to use Redux today and where the bulk of the open source work is taking place. Each repository is structured similarly, so once you understand one, it'll be easy to understand the other two! First Steps for Contributing Since most of the work is taking place in redux toolkit, new developers will find that it is the most active. In fact, new contributors can learn more, and even help out by reading and responding to questions in the discussions tab located in redux toolkit as a way to start contributing easily. Redux toolkit also has many open issues that developers can work on or triage! Developers can help by reproducing bugs or by editing and adding to documentation. If you're interested in helping in redux core, Mark is looking for TypeScript experts who are interested in reviewing types! If you are interested in contributing but need a little additional guidance, Mark invites you to reach out to him with your questions and he will do his best to get back to you! Good luck contributing, and we hope you have fun submitting your first PR to Redux!...

Tracy Lee2 mins
Open SourceReduxJavaScript

Introducing Framework.dev

Have you ever started to learn a technology and felt overwhelmed by the amount of information out there and became paralyzed, not knowing where to start? We at ThisDot can certainly relate, which is why we are creating framework.dev...

Jae Anne Bach Hardie3 mins
ReactJavaScriptOpen SourceRelease