Contributing to an open source project

Francisco Calderón published on
4 min, 623 words

Some people have asked me how can they help? I recognize that working on open source projects is a bit different from how you work on private projects, especially when the project has several collaborators, these projects are sometimes very dynamic and we need to have a somewhat rigid work structure to optimize processes, I will try to explain some steps to follow without going too technical to clarify the panorama.

  • Each bug is created as an issue: We call programming errors bugs, when a user finds a bug and does not report it, the bug will continue to appear until someone reports it or a developer finds it, it may not never be found, it is for this reason that if you find a bug and report it, you will be helping the developers to improve the quality of the software and the beneficiary will be yourself since you are a user of the system.

  • Each improvement request is created as an issue: A system feeds on its users, those who have the best ideas to improve a system are those who use it daily, if you have suggestions or ideas for improvement, let them know through of an issue.

  • The issue is assigned to a project: In github we can create different projects for the same repository, with this we segment in time which issues must be completed for one or another project, this is how we organize ourselves to plan future versions . If you are not a contributor, you do not need to worry about this, but if you are curious you can see the scope of each project.

  • Labels are assigned to each issue: The labels help us to classify the issues, if the issue is simple, it is assigned "good first issue", this label is key so that new collaborators begin to become familiar with the system and make your first contributions.

  • An issue is not assigned to anyone: Unless the developer has already agreed to do it or if you are a developer and you agree to start working at that time you can assign it to yourself, if not You have the privileges to assign it to you, you can write a comment indicating that you want to work on this issue and a developer with privileges will assign it to you.

  • A branch for each issue: Once you have an issue assigned, suppose you have been assigned issue # 30, the following would be to fork and clone the project locally, then create a branch with a name like this " issue_30-short-description-of-issue ", make the changes in that branch, make a push and finally a Pull Request (PR), [here] (https://gist.github.com/Chaser324/ce0505fbed06b947d962) you will find details how to do this.

  • You always have to do a review: Once the contributor makes a PR it is necessary to review the PR, doing a review means that we must check that the changes do not break anything, for this the programmers review the code, in this [link] (https://docs.github.com/es/github/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request) we can see how to carry out a review at the code level, if you are not a programmer you can also collaborate using the branch and testing if the changes do what is indicated in the related issue and if they do not break anything in the system.

This work methodology allows us to optimize development by modularizing the changes to be implemented and dividing them whenever possible into smaller issues. In an active development system we will always find bugs and conflicts in our code but by working in an organized way we can minimize them.