Contributing to πŸ”“ Open Source Repositories#

When using software β€” whether open source or proprietary β€” we often have ideas or opinions on how to improve it. We might find certain aspects of the software or its documentation unclear, or we may spot typos and minor issues that we could easily fix ourselves.

Today is your lucky day! You will learn just how simple it is to contribute to publicly hosted repositories on remote services like GitHub and GitLab, so that next time when you stumble across some bug in some open-source project you actually can suggest your own fix.

Β 

In most cases external contributions follow a general workflow.

However, be sure to always consult the contribution guidelines of an open source repository.

Step-by-Step#

1. Check Existing Issues πŸ‘€#

  • Browse existing Issues - open and closed ones - to see if the same or a similar Issue was already created.

  • If your Issue exists already, check for related Merge/Pull Requests and if they implement what you had in mind. If not, skip the next step (i.e. don’t create a new Issue) and simply proceed with step 3. Read Documentation.

Bugs

Explain how a bug can be reproduced!

2. Open an Issues πŸ“#

  • Write a short and concise description of the Bug, Question, or Suggestion.

  • Focus on defining the Issue such that it becomes clear why some work should be done.

3. Read Documentation πŸ“š#

  • Check for guidelines on how to contribute. Usually, they are to be found in a file called CONTRIBUTING or in the README.md.

  • If unsure, simply stick to this step-by-step workflow

4. Fork the Repository 🍴#

  • Create a personal copy of the repository by forking it.

5. Make Changes ✏️#

  • Implement the changes or features you want to contribute. For smaller changes you might directly work on the healthy reference (i.e. main) of the forked repository. Bigger changes should be implemented in a separate branch following the feature branch approach, for example.

  • Follow the project’s coding style and guidelines.

  • Make sure the branch on which you implement the changes, remains up to date with the target branch from to repository.

  • Test and document your changes.

6. Create a Merge/Pull Request πŸ”„#

  • Go to the original repository and submit a Merge/Pull Request to propose your changes.

  • Follow the guidelines, if present. If not:

    • Link the related issue with a closing statement (e.g. Closes #123)

    • Short description of how you addressed the Issue in your changes.

    • Explain why you followed a particular approach (if unclear).

7. Participate in Code Review πŸ‘₯#

  • Engage with project maintainers and other contributors during the review process.

  • Be open to feedback and make any necessary revisions.

  • Respect the maintainers decisions and adaptations, if you are not happy with them you can always keep your forked repository and maintain it on your own!

8. 🌟 Stay Engaged 🌟#

  • Once the Merge/Pull Request is merged or closed, feel free to delete your fork of the repository. This avoids confusion about which repository is the most up-to-date.

  • Continue to contribute to the project by helping with other issues or discussions.