Effectively Contributing to Open Source Projects: Webmaker
Contributing to open source projects has lots of merits. While contributing to such a project, you get to learn the professional way of development that is deployed by big organizations. Such skills prove to be very useful for people's careers and help them to learn things that they might not be able to learn during their education/work.
This article has been designed for beginners and intermediate developers wanting to contribute to open source projects. I will demonstrate contributing to the Webmaker Project of Mozilla Foundation, to explain how you can effectively contribute to open source projects.
Case Study: Mozilla Webmaker
We will go through the whole process of getting involved in a project, from understanding the guidelines of contributing, using a GitHub account and using Git to using Bugzilla efficiently. This tutorial will demonstrate how you can get your patches merged into the main codebase of a project. I will be using the example of an old and simple bug that I fixed, when I had just started open source contribution.
First of all, you will have to find the repository of the project. For instance, we will be working on the Profile component of Webmaker.
Log in to your GitHub account, and Fork the project. After doing so, you will have the forked repository located under your username.
For instance, I had the following:
You will need to have Git installed on your system. You can read the guidelines on how to do that.
On the bottom right hand side, you will notice a box like this:
You can copy that URL to clone the repository in your system. Now, run Git in command line mode and enter the following command.
This will import all the code into your system under a folder named webmaker-profile-2. Contributing guidelines are usually present in a file called
CONTRIBUTING.md and installation instructions are in
README.md. Do read those two documents very carefully. They contain important information for developers.
Now, you will have to find some relevant and easy bugs to start with. For any Mozilla related projects you can use Bugs Ahoy for finding good first bugs as well as mentored bugs specific to your skill set. Mozilla uses Bugzilla for bug filing and management, as well as handling of feature requests. You can log in at Bugzilla using Persona. Once you find a relevant bug, you should comment on that bug showing your interest in fixing the bug.
You can also ask for help in finding a specific file in the source code where the bug is present from the developers at Mozilla's IRC. They are a really friendly group of people who will gladly help you to solve your first bug. In case no one is online, try adding a
needinfo flag for the mentor mentioned in the bug and he will get back to help you!
Now, assuming that you have solved the bug and made the respective changes in the files locally, you will need to see the files that have been modified locally using the version control system. Just type the following command in the
This will give the details of the modified files as well as new files which have been added to the local repository. If you are satisfied with the files that have been changed, add the modified/new files to the staging area.
git add names_of_files
If everything is going right, then you can safely commit the files.
git commit -m "Your message here"
Cleaning the Commit Log and Pushing Changes
Make sure that your commit does not contain unnecessary white-spaces or new lines. It is considered a good practice to name the message something like "Fixing Bug 1040556", for reasons I will explain to you later in this article. The maintainers of the repository prefer if you have a single commit per pull request. So, if you have more than one commit locally, you should rebase them.
git rebase -i HEAD~2
The above command assumes that you have two commits, and
-i is the flag for interactive rebasing. It will show the two commits along with their messages, which will have the word
pick prefixed. Just replace
squash at one of the commits and you are good to go. The next screen just squashes the commit messages together.
Congratulations, you have successfully rebased the commits. Now you just have to push the changes to your GitHub repository.
Or if you already pushed the first commit and rebased afterwards, try the following command.
git push -f
Opening a Pull Request
Now open your online repository and click on the button for Pull Requests and open a new pull request.
It automatically fills the title of the pull request from the commit message and shows the diff (below figure shows the diff for my pull request).
Congratulations, you have made your first pull request. But you still need to do a few more things. Copy the URL of your pull request and open your bug at Bugzilla. Select Add an attachment and paste the URL of the pull request there. Tick the check box that says patch and add a review flag for your mentor.
Assuming that your patch was correct, your mentor will merge your pull request into the main repository and the bug will be automatically resolved by the github robot at Bugzilla (this only happens if the commit and pull request name contain the bug number).
There's nothing as joyful as seeing your code being merged into the main code base and being deployed to the main website that is used by million of users!
I hope that you were able to follow the steps to fix your first bug at Webmaker or any other similar open source project.
Source: Tuts Plus