Where’s the code?
The location of source code cannot be anymore obvious, it’s under
src directory just under the project root folder.
Where’s the documentation?
Documentation exists under
docs directory right under the project root folder. In addition to traditional documentation regarding usage of the project and project policies, Mozilla has also included a page documenting weekly updates.
How can you get involved?
One great thing about Mozilla is its strong friendly community. A great way to get involved is to join their slack team. You can get a feel for the environment of the community by idling on the channel and observing conversations. You may also notice that veteran contributors will welcome you to the team and encourage you to select a bug to work on. These folks will also extend help when you need an extra boost while tackling bugs.
In addition to joining their slack channel, the repository also includes a CONTRIBUTING.md file which contains all the details about how to contribute to the project. Common ways of contributing include reporting bugs, suggesting enhancements, writing documentation, giving talks, and organizing meetups.
Since Mozilla has a large community base and has many years of experience in opensource, the team also includes participation guidelines that they expect all members of the community to follow. This is to ensure a mutually respectful and open environment.
Finally, Mozilla has a bug bounty program. If a vulnerability is found, the community suggests reading policies regarding reporting vulnerabilities. In addition, they recommend creating an issue on Bugzilla (Mozilla’s internal bug tracker) for security issues.
What are some interesting things you’ve learned while observing the project?
Being a first timer at an official opensource project, I’ve found the way the team has structured the issues and pull requests.
Issues generally have a screenshot (where possible). This is then followed by a short 1-2 sentence description of the issue along with examples of the problem and the expected result. Some issues will include steps to reproduce. The community has placed strong emphasis on steps to reproduce as it will help new contributors to reproduce the problem in order to tackle the bug. The issue tracker also includes a host of descriptive tags such as: in progress, not-available, difficulty:medium, enhancement, performance, bug, tracking, code health, and good first issue. In particular, “in progress” is the most useful tag as a contributor can see at a glance, which issues to skip when searching for issues to work on.
The issue tracker also has a claim bot, which manages who is responsible for an issue. Contributors can reply to the issue with
/claim to have the claim bot set the issue to “in progress” mode and signals to the community that he/she is currently working on the issue.
It’s interesting to note that the project contains a
.github folder. Inside that folder, you will find files that contain templates for issues and pull requests. This is something I have not seen before, but can quickly grasp the importance of having such files for projects involving multiple contributors.
The pull requests contain the following information:
• The statement “Fixes Issue #(issue number)”
• Summary of Changes
• Test Plan (Step-by-step instructions for the reviewer to check that the fix is working)
• Screenshots of the fix (optional)
One interesting thing I’ve learned just this past week from Professor Humphrey is that GitHub has a set of keywords that can be used in a pull request title or description to allow the associated issue to close automatically upon merging. It appears Mozilla is taking full advantage of this by enforcing the “Fixes Issue…” statement in their pull requests.