Why small contributions matter greatly?

When you're new to open source, a question that often comes up is, "How big should my first PR be?" It's a valid question, and actually quite crucial if you want to contribute to open source projects.

Why small contributions matter greatly?


When you're new to open source, a question that often comes up is, "How big should my first PR be?" It's a valid question, and actually quite crucial if you want to contribute to open source projects. You might be wondering why this question is so important. Well, as the title suggests, even small contributions matter, but not everyone talks about it or realizes its significance. It seems like a simple question with a straightforward answer, right?

And yes, it is. But let me explain why. I think sharing real-life examples not only makes it more believable but also more personal. Most tutorials and articles these days lack that personal touch, so I want to address this topic based on my own experiences.

How small or big can a PR get?

First things first, let's understand the difference between a small and a large pull request (PR). Generally, a large PR involves making extensive modifications across multiple files, sometimes even introducing major changes that can disrupt the project. Project maintainers don't usually prefer these kinds of PRs because they are difficult to review and have the potential to destabilize the project. I want to make it clear that large PRs do happen, but they are relatively rare compared to the multitude of small PRs.

Now, let's talk about small PRs. Unlike large PRs, small ones are much easier to handle. They are quick to read and understand since they have less impact on the codebase. However, don't underestimate the potential of a small PR. Depending on its purpose, it can have a significant impact on how a documentation, website, or even a piece of code functions. So, even though they may seem minor, small PRs can actually make a big difference.

Let me provide you with a few examples of common small PRs that you might come across:

  1. Documentation changes: Making improvements or clarifications to the project's documentation.
  2. Spelling correction: Fixing typos or misspelled words in code comments, documentation, or error messages.
  3. Code formatting: Ensuring consistent and clean code formatting, such as indentations, line breaks, and spacing.
  4. Basic bug fixes: Addressing simple issues or bugs in the code that have straightforward solutions.
  5. Grammar correction: Fixing grammatical errors or improving the readability of comments or documentation.
  6. And more: There are numerous other small PRs that can be valuable, such as refactoring redundant code, improving variable names, optimizing performance, or adding simple tests.

These kinds of PRs are super important for any project, especially the ones with lots of docs. It's tough to keep everything updated when projects change or add new features, so mistakes and inconsistencies happen a lot. But for the folks who put in tons of hours to create free and open source projects, even the tiniest contribution means a lot. Seriously, even a little dot or a space can be a big help. It's a way for us users of open source stuff to show some love and support to the projects we use. When we actively get involved and make things better, we're helping these projects succeed and thrive.

My personal experiences

I've been involved in the open source community for over 7 years now, both as a maintainer and contributor. Throughout these years, I've made numerous PRs to well-known tech giants like Stripe, Vue.js, Angular, Firebase, daily.dev, Quasar Framework, and more. I want to share some of the notable small contributions I've made to these projects. Most of them involve documentation updates and minor bug fixes, just to show you that this is a real thing. Even small acts of help like these are greatly appreciated by maintainers of large open source projects.

Vue.js

Documentation changes

docs: update nesting example by jofftiquez · Pull Request #1868 · vuejs/vitepress
Change getting-started.md to guide/getting-started.md
docs: update getting-started.md by jofftiquez · Pull Request #1847 · vuejs/vitepress
Remove unnecessary dot (.) after every “Step” word. I don’t know if this is intentional, but it doesn’t look right to me. I could be wrong, so yeah.- # Step. 1+ # Step 1

Stripe

Stripe.js library documentation improvements

Update README.md by jofftiquez · Pull Request #129 · stripe/stripe-js
Add yarn usageAdd various code formatting (semi-standard)Add code-block type in code samples
Update .travis.yml by jofftiquez · Pull Request #131 · stripe/stripe-js
Remove unnecessary keyword “run” in test, and build script invocation

Nuxt.js

Documentation update

docs: mention config file name before code block by jofftiquez · Pull Request #19634 · nuxt/nuxt
InspirationI wasn’t able to see the file name immediately in the code block example because it disappears whenever you’re hovering in the code block which makes it confusing for beginners. 🔗 Link…

Firebase

Functions example bug fix

Updated catch for req.cookie by jofftiquez · Pull Request #396 · firebase/functions-samples
The previous code will fail if no Authorization was set in the header.

Daily.dev

Documentation changes, grammar improvements

docs(README.md): minor grammar updates by jofftiquez · Pull Request #1803 · dailydotdev/apps
Generally, the previous grammar are totally acceptable, except for some very minor slip-up.Changes Minor changes to the README.md Describe what this PR does Minor grammar/sentence format change…

This one's a bit funny coz it's just an emoji change 🤣 but hey!

chore(README.md): update emoji by jofftiquez · Pull Request #893 · dailydotdev/daily
IDK, I think 🍻 is more appropriate for programmers vs 🥂

Angular

Typo correction

chore: fix typo by jofftiquez · Pull Request #1016 · angular/angularfire
Just a little bit typo Checklist Issue number for this PR: #nnn (required)Docs included?: (yes/no; required for all API/functional changes)Test units included?: (yes/no; required)e2e tests inc…

Quasar Framework

Typo correction

docs: fix typo by jofftiquez · Pull Request #13519 · quasarframework/quasar
From “ia” to “is” What kind of change does this PR introduce? Bugfix Feature Documentation Code style update Refactor Build-related changes Other, please describe: Does this PR introdu…

Documentation update

doc: add warning about manifest v3 by jofftiquez · Pull Request #13528 · quasarframework/quasar
Apparently manifest v3 support is implemented in Vite only setup. A warning has been added to avoid misunderstanding. For more details see - #8844 What kind of change does this PR introduce?…

Nativescript Vue

Documentation update

Update tab-view.md by jofftiquez · Pull Request #210 · nativescript-vue/nativescript-vue.org
Better explanation for selectedIndexChange event. The on how to get the index from the event object is not included in the docs so I had to explicitly add it.

Capacitor

Documentation update

chore: update README.md by jofftiquez · Pull Request #180 · capacitor-community/stripe
Update “not support” to “not supported” to make it grammatically correct.

DaisyUI

Starter list update

🆕 feat(README.md): add Nuxtwind Daisy starter to the list by jofftiquez · Pull Request #1891 · saadeghi/daisyui
Added a new starter to the list, Nuxtwind Daisy, which is a Nuxt 3 starter with pre-installed configurations like fonts, icons, animations, etc. It uses Tailwind CSS and daisyUI Template.

Website meta image update

🖼️ chore(default.jpg): update default image by jofftiquez · Pull Request #1890 · saadeghi/daisyui
ChangesThe default.jpg image has been updated to accommodate version change, previously shows version 2.0, now version 3.0. No functional changes have been made, only the image file has been repla…

Example updates

chore(docs): Update button.svelte.md by jofftiquez · Pull Request #1838 · saadeghi/daisyui
Make medium size explicitly documented in the button sizes section.Resolves #1837

And many more! 😄

Closing remarks

As you can see, most of these are documentation changes and it's okay. They are small, easy to review, and adds great value to the project. Some might say that these are just small changes and bigger PRs are better, don't pay attention to them. The true value in open source is the collaboration no matter how small or big your contributions are. So next time you see a typo or misspelled words or minor grammar correction, go for it, fork the project and submit a PR! Happy open sourcing!

About the author

Joff Tiquez, hailing from Manila, Philippines, is the individual behind the establishment of OSSPH. He is a web developer who strongly supports open source and has been overseeing projects like Vue Stripe for an extended period. To get in touch with Joff, you can visit https://bento.me/jofftiquez.