How to Contribute to Open Source Project …
Open Source software is one with free redistribution ,where one can do some tinkering and change stuffs based on requirements.
Why contribute to Open Source?
There are many great reasons to contribute to open source project:
- Contributing to an open source project helps to improve yourself , it gives real world scenario exposure in proven working situations.
- It will help you gain a much deeper knowledge about the software.
- It feels good to give back to a project, that you use.
- Contributing to project is fun and definitely gives you vibes of nirvana.
Getting Started
Step 0. Make a GitHub account
Most open source projects are hosted on GitHub ,which is a website for sharing and saving code. Anyone can make a GitHub account for free .Paid accounts are only necessary if you want to save some of your code to make it private.
Official Documentation to creating account on GitHub: https://docs.github.com/en/free-pro-team@latest/github/getting-started-with-github/signing-up-for-a-new-github-account
Step 1. Choose a Project and issue to work on
My advice is to contribute to the one which you have a use for, or strong interest in . If you aren’t using it, probably you would be ineffective in the long run. Also,either due to lack on enthusiasm or absence of understanding for the given project you will miss the soul of problem. You will get vibes of contributing, when you think “ why doesn’t x exist in y application, whether I could add that and will it be really useful for people ”.
To see the Issues ,go to the project where you want to contribute and then click on Issues tab , it will show you issues in this repository. Many open source projects use tags like “Good for new contributors” or “help wanted” to indicate which issues might be best to jump in on.
Step 2. Fork the project repository
After choosing project where you have to contribute “fork” it by clicking the Fork button in the upper right corner :
This creates a copy of the repository in your GitHub account, you will see that you are now looking repository in your account.
Step 3. Clone the fork
When you click on the green “Code” button, you’ll see a few options. If you’re a beginner, you may want to do “clone with HTTPS” You may need to click on “Use HTTPS” to reveal the option. You’ll see a link, which you should copy. If you use HTTPS, you’ll have to enter your username and password each time you want to save your code online. Or, you can use SSH, which is compatible with 2-factor authentication and is considered as better practice, but just some more work to set up. Or, you can skip all of this and use GitHub Desktop. You have options!
In the command line, navigate to the folder where you want to save the repository. On a Linux/Mac, ls will list the contents of the folder you’re in. cd foldername (write your own folder name) will open up a folder you saw in the list. cd .. will take you up/back one level. mkdir foldername will create a new folder.
Once you are inside the right folder, type git clone that-https-url_you_copied. Hit enter, and your project will start downloading. cd into the folder you just opened.
Step 4 . Check that your fork is the “origin” remote
You are going to be synchronising your local repository with both the project repository (on GitHub) and your fork (also on GitHub). The URLs that point to these repositories are called “remotes”. More specifically, the project repository is called the “upstream” remote, and your fork is called the “origin” remote.
When you cloned your fork, that should have automatically set your fork as the “origin” remote. Use git remote -v to show your current remotes. You should see the URL of your fork (which you copied ) next to the word “origin”.
If you don’t see an “origin” remote, you can add it using: git remote add origin URL_OF_FORK.
(If you run into problems during this step, read the Managing remote repositories page from GitHub’s documentation.)
Step 5. Add the project repository as the “upstream” remote
Go to your fork on GitHub, and click the “forked from” link to return to the project repository:
While in the project repository, click the green Code button and then copy the HTTPS URL:
Add the project repository as the “upstream” remote using: git remote add upstream URL_OF_PROJECT.
For example, I used “git remote add upstream https://github.com/scikit-learn/scikit-learn.git”
Use git remote -v to check that you now have two remotes: an origin that points to your fork, and an upstream that points to the project repository.
Step 6. Pull the latest changes from upstream into your local repository
Before you start making any changes to your local files, it’s a good practice to first synchronise your local repository with the project repository. Use git pull upstream master to “pull” any changes from the “master” branch of the “upstream” into your local repository.
If you forked and cloned the project repository just a few minutes ago, it’s very unlikely there will be any changes, in which case Git will report that your local repository is “already up to date”. But if there are any changes, they will automatically be merged into your local repository.
Step 7. Create a new branch
Rather than making changes to the project’s “master” branch, it’s a good practice to instead create your own branch. This creates an environment for your work that is isolated from the master branch.
Use git checkout -b BRANCH_NAME to create a new branch and then immediately switch to it. The name of the branch should briefly describe what you are working on, and should not contain any spaces.
For example, I used git checkout -b doc-fixes because I was making some small fixes to the documentation.
Use git branch to show your local branches. You should see your new branch as well as “master”, and your new branch should have an asterisk next to it to indicate that it’s “checked out” (meaning that you’re working in it).
Step 8. Make changes in your local repository
Use a text editor or IDE to make the changes you planned to the files in your local repository. Because you checked out a branch in the previous step, any edits you make will only affect that branch.
Step 9. Install dependencies
Almost every open source project uses other open source projects within their co debase — tools for running servers, parsing times and dates, animating, etc. These are referred to as dependencies.
A good open source project will have detailed instructions on how to install the dependencies in its README.md and CONTRIBUTING.md files.
If you are making multiple sets of changes, it’s a good practice to make a commit after each set.
Step 10. Commit your changes
Hopefully you’ve read through the README and CONTRIBUTING instructions for the repository.
After you make a set of changes, use git add -A to stage your changes and git commit -m “DESCRIPTION OF CHANGES” to commit them.
For example, I used git commit -m “fix typos in set_config docstring” for one of my commits.
If you are making multiple sets of changes, it’s a good practice to make a commit after each set.
Step 11. Push your changes to your fork
When you are done making all of your changes, upload these changes to your fork using git push origin BRANCH_NAME. This “pushes” your changes to the “BRANCH_NAME” branch of the “origin” (which is your fork on GitHub).
For example, I used git push origin doc-fixes.
Step 12. Begin the pull request
Return to your fork on GitHub, and refresh the page. You may see a highlighted area that displays your recently pushed branch:
Click the green Compare & pull request button to begin the pull request.
(Alternatively, if you don’t see this highlighted area, you can switch to your branch using the Branch button and then click the New pull request button.)
Step 13. Create the pull request
When opening a “pull request”, you are making a “request” that the project repository “pull” changes from your fork. You will see that the project repository is listed as the “base repository”, and your fork is listed as the “head repository”:
Before submitting the pull request, you first need to describe the changes you made (rather than asking the project maintainers to figure them out on their own). You should write a descriptive title for your pull request, and then include more details in the body of the pull request. If there are any related GitHub issues, make sure to mention those by number. The body can include Markdown formatting, and you can click the Preview tab to see how it will look.
On the right side, you may see a link to the project’s Contributing guidelines. This is primarily worth reading through if you are submitting substantial code (rather than just fixing a typo), but it may still be worth scanning through at this point.
Below the pull request form, you will see a list of the commits you made in your branch, as well as the “diffs” for all of the files you changed.
If everything looks good, click the green Create pull request button!
Step 14. Expect changes and be patient
Next up, a maintainer or contributor will review your code. This is an important part of doing open source!
If someone asks you to make changes, don’t feel bad! It’s part of the learning process. Most maintainers will be so happy for the help and love having new people pitch in. Keep in mind it may take a little while before someone reviews your work. If no one gets to you within a couple weeks, it may be appropriate to @ a maintainer in a comment on your PR. Just remember that they are volunteers, so please be kind. A good way to figure out who to ping is looking at the closed pull requests and seeing who commented/did the merges.Once your work is approved, it will be merged in!
Congratulations!
Congratulations on making your first open source contribution! 🎉 If you ran into any unexpected problems, I’d love to hear about it so that I can continue to improve this guidance.
