Start Contributing

There are lots of ways to get started contributing to the Open Source ecosystem. It can be working on a bug in a current project, publishing your research in an open way, or helping facilitate an active project with non-coding work like project management.

How do I Start Contributing?

You don’t have to contribute code

A common misconception about contributing to open source is that you need to contribute code. In fact, it’s often the other parts of a project that are most neglected or overlooked. You’ll do the project a huge favor by offering to pitch in with these types of contributions!


Do you like planning events?

  • Organize workshops or meetups about the project, like @fzamperin did for NodeSchool
  • Organize the project’s conference (if they have one)
  • Help community members find the right conferences and submit proposals for speaking

Do you like to design?

  • Restructure layouts to improve the project’s usability
  • Conduct user research to reorganize and refine the project’s navigation or menus, like Drupal suggests
  • Put together a style guide to help the project have a consistent visual design
  • Create art for t-shirts or a new logo, like hapi.js’s contributors did

Do you like to write?

  • Write and improve the project’s documentation
  • Curate a folder of examples showing how the project is used
  • Start a newsletter for the project, or curate highlights from the mailing list
  • Write tutorials for the project, like PyPA’s contributors did
  • Write a translation for the project’s documentation

Do you like organizing?

  • Link to duplicate issues, and suggest new issue labels, to keep things organized
  • Go through open issues and suggest closing old ones, like @nzakas did for ESLint
  • Ask clarifying questions on recently opened issues to move the discussion forward

Do you like to code?

  • Find an open issue to tackle, like @dianjin did for Leaflet
  • Ask if you can help write a new feature
  • Automate project setup
  • Improve tooling and testing

Do you like helping people?

  • Answer questions about the project on e.g., Stack Overflow (like this Postgres example) or Reddit
  • Answer questions for people on open issues
  • Help moderate the discussion boards or conversation channels

Do you like helping others code?

You don’t just have to work on software projects!

While “open source” often refers to software, you can collaborate on just about anything. There are books, recipes, lists, and classes that get developed as open source projects.

For example:

Even if you’re a software developer, working on a documentation project can help you get started in open source. It’s often less intimidating to work on projects that don’t involve code, and the process of collaboration will build your confidence and experience.

Git Basics

Git is a free and open-source version control system.  Version control systems, also known as source control, is the practice of tracking and managing changes to software code over time.  Git originally created by Linus Torvalds in 2005 (to creator of Linux). It is build to give every developer has the full history of their code repository locally. 


Git has a couple of key concepts:

  • Repository (Repo) – a place where files like code, documentation, licenses, etc. are stored. This can be Github, Gitlab or another location
  • Cloning – Making a copy of a Repo with all of the Git history
  • Branching – making a copy to work on without modifying the original
  • Merging – bringing your modified version back into the original code
How Git works

Here is a basic overview of how Git works:

  1. Create a “repository” (project) with a git hosting tool (like Bitbucket)
  2. Copy (or clone) the repository to your local machine
  3. Add a file to your local repo and “commit” (save) the changes
  4. “Push” your changes to your main branch
  5. Make a change to your file with a git hosting tool and commit
  6. “Pull” the changes to your local machine
  7. Create a “branch” (version), make a change, commit the change
  8. Open a “pull request” (propose changes to the main branch)
  9. “Merge” your branch to the main branch


Resources for more reading:





A software bug is an error, flaw or fault in the design, development, or operation of computer software that causes it to produce an incorrect or unexpected result, or to behave in unintended ways. The process of finding and correcting bugs is termed “debugging” and often uses formal techniques or tools to pinpoint bugs. 

Bugs in software can arise from mistakes and errors made in interpreting and extracting users’ requirements, planning a program’s design, writing its source code, and from interaction with humans, hardware and programs, such as operating systems or libraries. 

What make up a good bug report?

1) Bug Number/id
A Bug number or an identification number (like swb001) makes bug reporting and the process of referring to bugs much easier. The developer can easily check if a particular bug has been fixed or not. It makes the whole testing and retesting process smoother and easier.

#2) Bug Title
Bug titles are read more often than any other part of the bug report. This should explain all about what comes in the bug. The Bug title should be suggestive enough that the reader can understand it. A clear bug title makes it easy to understand and the reader can know if the bug has been reported earlier or has been fixed.

#3) Priority
Based on the severity of the bug, a priority can be set for it. A bug can be a Blocker, Critical, Major, Minor, Trivial, or a suggestion. Bug priorities can be given from P1 to P5 so that the important ones are viewed first.



#4) Platform/Environment
OS and browser configuration is necessary for a clear bug report. It is the best way to communicate how the bug can be reproduced.

Without the exact platform or environment, the application may behave differently and the bug at the tester’s end may not replicate on the developer’s end. So it is best to clearly mention the environment in which the bug was detected.

#5) Description
Bug description helps the developer to understand the bug. It describes the problem encountered. A poor description will create confusion and waste the time of the developers as well as testers.

It is necessary to communicate clearly about the effect of the description. It’s always helpful to use complete sentences. It is a good practice to describe each problem separately instead of crumbling them altogether. Don’t use terms like “I think” or “I believe”.

#6) Steps to Reproduce
A good Bug report should clearly mention the steps to reproduce. These steps should include actions that may cause the bug. Don’t make generic statements. Be specific on the steps to follow.

A good example of a well-written procedure is given below


Select product Abc01.
Click on Add to cart.
Click Remove to remove the product from the cart.
#7) Expected and Actual Result
A Bug description is incomplete without the Expected and Actual results. It is necessary to outline what the outcome of the test is and what the user should expect. The reader should know what the correct outcome of the test is. Clearly, mention what happened during the test and what the outcome was.

#8) Screenshot
A picture is worth a thousand words. Take a Screenshot of the instance of failure with proper captioning to highlight the defect. Highlight unexpected error messages with light red color. This draws attention to the required area.

Skip to content