Skip to content

How to Contribute to Open Source

How to Start Contributing to Open Source (Step-by-Step Guide)

This section explains exactly how a beginner should approach open source, from the first visit to a project to making real contributions in large organizations.

You do not need prior open-source experience.

Step 1: Choose the Right Project

Before writing any code, choose the right organization and project.

How to choose a project:

  • Pick a project that matches your interest (web, backend, AI, systems, etc.)
  • Check if the repository is active (recent commits and issues)
  • Look for beginner-friendly labels like:
  • good-first-issue
  • beginner
  • help-wanted

Avoid projects that: - Have no recent activity - Do not respond to issues or PRs - Have no documentation

Step 2: Join the Community (Very Important)

Open source is community-first, code-second.

Join Communication Channels

Most organizations communicate outside GitHub.

Common platforms: - Discord - Slack - Matrix - Mailing lists

You can find links in: - README.md - CONTRIBUTING.md - Project website

What to do after joining:

  • Observe conversations for a few days
  • Understand how people communicate
  • Note how maintainers respond

Step 3: Introduce Yourself Properly

A good introduction builds trust.

Example Introduction Message:

Hello everyone 👋
My name is Shadil. I'm a Computer Science student interested in accessibility and open source.
I’ve been exploring this project and would love to start contributing.
Currently learning <tech stack>. Looking forward to learning and helping!

Good introductions are: - Short - Honest - Clear about interests - Respectful

Step 4: Read Documentation Before Asking Questions

This is mandatory.

Read: - README.md - CONTRIBUTING.md - CODE_OF_CONDUCT.md - Project wiki (if available)

Why this matters: - Most beginner questions are already answered - Maintainers respect contributors who read docs - Saves everyone’s time

Step 5: Understand GitHub Basics

Before contributing, you must understand how GitHub works.

What Is a GitHub Repository?

A repository (repo) is: - A project’s complete codebase - Includes code, documentation, issues, and history

What Is a GitHub Issue?

An issue is a task, bug report, feature request, or discussion.

Issues are used to: - Track bugs - Propose new features - Assign work - Discuss improvements

Common Issue Labels:

  • bug: Something is broken
  • feature: New functionality
  • documentation: Docs improvements
  • good-first-issue: Beginner-friendly
  • help-wanted: Maintainers want help

Step 6: Find an Issue to Work On

How to find issues:

  1. Go to the repository
  2. Click on the Issues tab
  3. Filter by labels like:
  4. good-first-issue
  5. beginner

Before starting:

  • Read the issue fully
  • Check comments
  • See if someone is already assigned

Claiming an issue:

Comment politely: 

Hi, I’d like to work on this issue. May I take it?

````

Wait for confirmation before starting.

---

## Step 7: Fork the Repository (Beginner Explanation)

### What Is Forking?

Forking means:
- Creating **your own copy** of the project on your GitHub account
- You can safely experiment without affecting the original project

### How to Fork:
1. Open the repository
2. Click the **Fork** button (top-right)
3. GitHub creates a copy under your account

---

## Step 8: Clone the Repository Locally

Cloning means downloading the code to your computer.

### Steps:
1. Go to your forked repository
2. Click **Code → HTTPS**
3. Copy the URL
4. Run:
```bash
git clone <copied-url>
````

Now the project exists on your local machine.

---

## Step 9: Run the Project Locally

This step is **critical**.

### Why?

* If it doesn’t run, you can’t fix it
* Setup issues themselves are valid contributions

Follow instructions in:

* `README.md`
* Setup guides

If the project fails to run:

* Try to fix it
* If successful, document the fix
* This alone can be a great first PR

---

## Step 10: Create a New Branch

Never work on the `main` branch.

```bash
git checkout -b fix-issue-123

Branch names should describe the change.

Step 11: Make Small, Meaningful Changes

Good first contributions:

  • Fix typos or broken links
  • Improve documentation
  • Fix simple bugs
  • Add tests
  • Improve error messages

Avoid:

  • Massive refactors
  • Changing unrelated files

Step 12: Commit Your Changes

A commit saves your work.

git add .
git commit -m "Fix setup instructions for Linux"

Good commit messages:

  • Short
  • Descriptive
  • Professional

Step 13: Push Changes to Your Fork

git push origin fix-issue-123

Step 14: Create a Pull Request (PR)

What Is a Pull Request?

A Pull Request:

  • Requests maintainers to review your changes
  • Proposes merging your code into the main project

How to create a PR:

  1. Go to your fork on GitHub
  2. Click Compare & Pull Request
  3. Fill in the template carefully

Step 15: Write a Good Pull Request Description

Include:

  • What you changed
  • Why you changed it
  • Link the related issue (Fixes #123)

Example:

This PR fixes the setup issue on Linux by updating dependency instructions.
Fixes #123

Step 16: Handle Review Feedback

This is normal and expected.

Maintainers may:

  • Ask for changes
  • Suggest improvements
  • Request clarification

How to respond:

  • Be polite
  • Ask questions if unclear
  • Push updates to the same PR

Step 17: PR Gets Merged 🎉

Once approved:

  • Your code becomes part of the project
  • You are now an open-source contributor

This builds trust.

Step 18: Be Consistent

Big organizations value:

  • Regular contributors
  • Good communication
  • Long-term involvement

After first PR:

  • Take another issue
  • Help others
  • Review PRs
  • Attend meetings