MDN's mission is simple: provide developers with the information they need to easily build projects on the open Web. If it's an open technology exposed to the Web, we want to document it.

– MDN Web Docs mission statement

A community of developers and other contributors keep the MDN Web Docs up-to-date. The entire site is a wiki, meaning anyone can add to or edit the growing collection of documentation and tutorials.

But you don't need to be a professional developer to contribute to MDN Web Docs! Like many other open source projects, there are a lot of ways you can help.

If you're interested in contributing to MDN Web Docs, check out their Getting Started page.

Here are some quick links to useful resources:

• HTML, CSS, JavaScript
• Web APIs
• Graphics
• MathML
• Web Assembly

How to Use MDN Web Docs

MDN have built a reputation for having some of the best documentation for common web technologies. If you've ever been asked, "Have you checked the docs?" chances they're referring to MDN Web Docs.

Say you're working on a project and you want to use JavaScript's map() method, but you forgot the exact syntax.

All you need to do is pull up the page for [map()](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/map) and scroll down to the Syntax section.

There you'll get a quick overview of the syntax:

let new_array = arr.map(function callback( currentValue[, index[, array]]) {
    // return element for new_array
}[, thisArg])

And a list of arguments that the method accepts, along with a short description of each.

If you want to see some basic examples and common use cases, scroll down a bit more to the Examples section. There's a good chance that you'll find a snippet that you can use in your own project.

Also, if you ever find yourself having to support older browsers, most if not all the JavaScript documentation includes a Polyfill section.

Contributing to open source is very difficult. The people who do are experts with years of experience and we are just beginners — it’s not meant for us.

Those were the exact words of my friends when I first asked them about what open source and Google Summer of Code were and how we could contribute to them. The inferiority complex inside me (or I should say the superiority I gave to them for being a little more into coding than I was) made me believe their words for two long years. So I had totally abandoned the thought of ever contributing to open source.

But today, here I am with 12 PRs submitted successfully and 3 under review to organisations like Mozilla, freeCodeCamp and Gatsbyjs. And guess what? I’m still in college and have almost zero experience working in any organisation or company!

So, if you are someone who thinks open source is not meant for you just like I used to, then just STOP!

How did it all start?

A Little Background About Me ??

My coding journey started three years back when I learnt how to code in the C Programming Language. Since then, I have learnt C++, Algorithms & Data Structures, and solved hundreds of algorithmic and logical problems on multiple sites like CodeChef, SPOJ, HackerRank & Codeforces.

Later, I moved on to learn web development from freeCodeCamp. I liked its curriculum and most importantly their projects. But the best thing was their free and open community who were always ready to help you out. A lot of people helped me clear my doubts on the forum or the Gitter chatroom and the responses were always encouraging.

I literally felt that I owed the community and always kept looking for people to whom I could provide some help. To be honest, it always felt great whenever I helped someone with their questions and problems on the freeCodeCamp chat room. After a year, the thought of contributing to open source again came in my mind. I discussed my wish to contribute with those same friends, but all I got were those same words as before. I let that thought go away for the second time.

That Little Spark Of Self-Belief & Courage?

After successfully completing my internship and securing a job, I was totally free in my senior year of my undergrad. The thought of Google Summer of Code again stumbled into my mind. As it was probably my last chance of getting into GSoC, and I didn’t want to have any regrets after leaving college and before getting into the real world, I finally said this to myself:

Let’s just give it a shot. Worst comes to worst I might fail but at least I will know that I tried! I do not want to let go of an opportunity just because one person said to me that I can’t do it!

I googled everything about open source, what organisations to start with, how to find something to contribute to, every single thing!

Finally, I decided to go with Mozilla as it was the most beginner-friendly organisation. As Mozilla is a very large organisation, it has quite a lot of products under it, and again that big question came up: which product should I go with?

With the help of their introduction page and learning about my own interests, I went with Firefox DevTools. Why DevTools? Because for me, there’s nothing better than helping other people learn, improve and grow. And the fact that something developed or implemented by me would help others learn was the best feeling I could ever think of.

The Real Struggle Begins ?

I’ll be honest here, before starting out everything looked intimidating. But once it’s all done you start finding that everything is a piece of cake. The first and most important step is getting and building code. Almost all organisations have a very detailed step-by-step guide for this. I struggled a lot in getting the code. Firefox’s codebase is H U G E! And thanks to the slow internet connection which made it worse. After three days of struggle, I was finally able to get the code and was able to build Firefox locally by carefully following the steps as mentioned in the docs.

Now that I had got it all working, the next step was to actually get something to work on! I went through all the [good-first-bugs](https://bugs.firefox-dev.tools/?easy&tool=all) and commented on the ones I found interesting by introducing myself and showing interest in solving the issue. I got myself assigned to one of them.

Every mentor knows that we are new to open source. Finding that one place where we have to make changes is like finding a needle in a haystack. So they guide us to the code files and sometimes even the line numbers where we have to analyse the issue and make the requested changes. And even if they don’t, you have every right to ask them and they will help you happily.

For the next 10 days, all I did was study the code, debug, build, run and analyse…but, I couldn't get to any solution or conclusions! ? Finally, I decided to go with all my analysis and results and ask my mentor for help. Sometimes you have to ask for help because without doing so you cannot move forward! The whole code is new to you and no one is expected to understand it in a couple of days.

My mentor realized that it was not a good-first-bugs kind of issue and solved it himself. To be honest, that was a little depressing. But my mentor gave me another issue to solve which was comparatively quite easy and I finally did it after a day or two of analysis! Yes, I was finally able to submit my first patch (PR)! But getting it landed was really not that easy, so many minor mistakes and ESLint errors that were literally frustrating. Finally, after 3 to 4 rounds of reviews, my patch landed! Yay! ?

After submitting my first patch, I quickly started looking for more issues to solve. I kept solving a few more good-first-bugs but soon I realized that I want to solve issues that involved more than just making minor changes and were something more complex. I was also still not sure of my interests and so wanted to explore a few more organisations. So I solved a few issues on Mozilla’s Taskclusters, freeCodeCamp and Gatsbyjs as well. But very soon I realised that Firefox DevTools was the one I enjoyed working with the most ? and continued contributing to it.

This is how the process of contributing to open source looks like:

1. Get an issue to work on.
2. Study the codebase and understand what needs to be done.
3. Code. Ask questions. Commit.
4. Submit a patch.
5. Resolve review comments and make the patch land.
6. Go back to step 1.

Final Notes

To all the people who are reading this, I hope I was able to motivate you and make you realize that you are fit to contribute to open source — because the truth is you are! In fact, it’s not even necessary to know a particular programming language, as you can always help with the documentation or you can report detailed bugs and can always learn things along the way.

Yes, I know that we might not be making any big contributions to the codebase or not starting any big open source projects, but these little contributions are also as equally important as the larger ones. And it’s rightly said that little drops of water make a mighty ocean. You never know when your one little contribution may turn out to be so helpful for others and one day you might also end up with this:

Yes! I got recognized by Firefox DevTools for one of my contributions.✨ Here’s the tweet.

So to all the open source beginners or the ones wanting to start with open source, I just wanna say this: forget what others think and believe and only remember what you want to do. You are capable, and that’s all that matters in the end. Just take that first step fearlessly and the world will guide you further — or I should say the mentors will guide you further. ?

Lastly, I would love to thank all my mentors and open source maintainers who helped in my journey and will do so in the future. A special thanks to Jan Honza Odvarko and Nicolas Chevobbe for helping me, answering and clarifying all my doubts and questions, and showing so much patience while mentoring me. Thank you so much! ❤️

Anyone who needs help with starting out with either open source or programming, don’t hesitate and drop me a mail at sachdev.hemakshi[at]gmail[dot]com. I love getting emails ?.

Thank you to the freeCodeCamp team for publishing this article. ?

Currently, I’m working on a Firefox health dashboard as a part of my Outreachy internship with Mozilla. And here are the major goals we intend to achieve during the internship.

• Add new features to the graphical presentation of performance data
• Transfer existing JS Team (Firefox Performance) dashboard to the health dashboard
• Enhance existing information on charts and fix some bugs

The main purpose of this post is to explain the project to someone who is not in the community and not familiar with the stuff we are doing at Mozilla. The intention is to help newbies and other contributors to understand the dashboard so they can contribute to this opensource project with more sense of what is going on inside.

_Photo by [Unsplash](https://unsplash.com/photos/0-SGyQFiDRI?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="_blank" title="">rawpixel on <a href="https://unsplash.com/search/photos/health?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="blank" title=")

What is Firefox Health Dashboard?

Firefox health is a project to create dashboards for project managers and engineers. It displays Firefox matrics and insights to help meet release criteria. It allows including data/metrics from Mozilla’s issue tracker (Bugzilla), performance data (Perfherder), product metrics (Telemetry) and few more sources. All data is displayed in the form of graphs using an open source graphing library ChartJS to display insights against different dates and platforms.

It was previously known as Platform Health. It was refactored in Jan 2018 as Firefox Health Dashboard. One of the major changes in this refactorization was to separate backend from the front-end. This improved code maintainability.

Technologies:

The backend is written using NodeJS and Koa. The front-end is built using ReactJS along with an open source graphing library ChartJS. Some of the data is coming from different hosts through different libraries. For example, perf-google is querying Mozilla’s Perfherder for performance data. Information about the reported bug is coming from Bugzilla. So if you are planning to contribute sometime in the future, you need to have an understanding of the technologies mentioned above.

This dashboard caters to performance of different Firefox versions and devices. But today we are going to talk about Firefox android and how engineers at Mozilla take care of its performance.

Data/metrics for Firefox android

Currently, data for Firefox android is coming from different sources. We display the data in the form of graphs for better understanding and analysis. You can see all insights to Firefox android on the health dashboard. Here are some sources and information about Firefox android to help engineers improve the performance of the browser.

Bugzilla:

Developed by Mozilla, Bugzilla is a free, open-source tool for tracking bugs, issues and change requests in large complex applications. It is used by thousands of organizations to keep track of their product performance. We are using it in the Health Dashboard to keep an eye on the bugs popping up in Firefox Android.

A graph displaying bugs from Bugzilla

As mentioned above, we are using ChartJS to display data. Here we have a graph representing the number of bugs reported on different dates for Firefox Android at Bugzilla. Bugs with P1 label have the highest priority. They need to be fixed as soon as possible. Then comes P2 bugs with the 2nd highest priority. P3 level bugs are with lowest priority and engineers can fix them whenever they have time. This helps developers and product managers to review bugs of different priorities more effectively and solve them according to the priority.

NimbleDroid:

We are using a third party service called NimbleDroid to get some data insights after running the tests against Firefox Android. NimbleDroid is a functional performance testing service for android and IOS devices.

Monitor every critical user flow for every build of your mobile app. Pinpoint issues that degrade user experience early in the dev cycle. Seamlessly integrate with your CI workflow. — Official Site

Showing data insights given by Nimbledroid

Telemetry:

Telemetry is a tool that has the capability to provide performance and usage information to Mozilla to help engineers and decision makers to measure the performance of Firefox in the real world. It has the ability to collect performance, hardware, usage, customization, and other non-personal information from the user of Firefox and send it to Mozilla on daily bases to help engineers improve the quality and efficiency of the browser.

Telemetry graph view

For an Android device, the browser measures the time taken by it to load a content page on a device and reports it back through Telemetry. We then display it in graphical form. For instance, the screenshot says 75% of the users reported a total content page load time of 4.9 seconds on Sep 19, 2018. And this data is gathered from different devices from different users. This helps the engineers to keep an eye on loading time of the browser to improve its speed and make it more efficient.

Perfherder:

Perfherder is a system to help engineers visualize and analyze the performance data produced by the many automated tests run against Mozilla products such as Firefox or Firefox Android. Perfherder is a part of Treeherder project. It is another dashboard for check-ins to Mozilla’s projects. The main goal of this tool is to make sure that the performance of the Firefox gets better over the time. It assists developers in the understanding of their changes and potential fixes by reporting regressions.

In the coming articles, we will talk about Firefox Quantum and JS team dashboard. We will see how these tools are working to improve the performance of the Firefox browser.

Contribution guide:

If you care about the health of Firefox or interested in contributing to the project, then here is the way.

• Clone and set up the project on your local machine
• Follow the readme
• And start with good-first-issues if you are finding it overwhelming to start

Stay tuned to know more about the awesomeness we are doing at Mozilla.

When you’re new to open source, you’ll find yourself asking:

I know some [programming language]. I want to get some practice, while helping out. How do I find an open source project where I can contribute? Hm… I don’t know where to start. This seems complicated.

I’ve asked this same question over and over to a lot of developers. And their answers can be categorized as one of three approaches:

Approach #1: Contribute to something you love

The most common answer I get is to contribute to something you already use everyday. Something that interests you.

Approach #2: Specifically seek out beginner-friendly projects

Here are a few characteristics of beginner-friendly open source projects:

• Well-defined, detailed contribution guidelines that include setting up their project locally, their Git workflow, and their coding style guidelines
• Proper classification of issues using labels like “good-first-bug”, “beginner”, or “first-timers-only”
• Activity on those beginner issues, with previous questions answered quickly

Approach #3: Stop searching for projects and start searching for bugs.

This is the approach I chose, and the focus of this article.

After trying approaches #1 and #2, I stopped thinking in terms of projects. I focused instead on finding bugs that I thought I could fix.

Every bug is associated with a project, so when finding bugs, you’ll inevitably discover projects, anyway.

This approach works if you want to get started immediately. I can’t guarantee that it will inspire you to stick with a project after your first few contributions. Maybe you won’t be interested after all. But maybe you’ll dive into the project and discover that you really like it.

Either way, once you’ve fixed a few bugs, you’ll have the confidence to venture out there and explore more on your own.

So how do you find the bugs to begin with?

Deciding which bugs to work on isn’t easy. There are a ton of projects out there, and each has plenty of open issues. But you need to start somewhere.

So I’ll share all the resources and tips I’ve used to find bugs. First I’ll focus on finding good starter bugs in general in various bug trackers and code hosting sites. Then I’ll share some resources specific to the Mozilla ecosystem, where I’ve been contributing regularly.

Finding good bugs for beginners

A good place to start your bug hunt is Up For Grabs. The whole purpose of the site is to help new contributors get their feet wet by maintaining a list of projects with beginner-friendly issues. It’s a great place to get started if you feel completely lost.

GitHub has a powerful search engine where you can customize your search in a variety of ways. The easiest way to search is by issue label.

A lot of open source projects label their issues to conveniently track them. A lot of projects use labels like beginner, easy, starter, good first bug, low hanging fruit, bitesize, trivial, easy fix, and new contributor.

You can further narrow down your search based on the programming language you’re comfortable with, by adding language: name to your search query. For example, here are all issues labelled as “beginner” in JavaScript.

Issuehub.io is a tool for searching issues by label and language, in case you find it tedious to remember the GitHub search syntax.

If you’re completely new to open source, you should definitely start with First Timers Only. It’s an initiative by Kent C. Dodds, based on his own First Timers Only post and Scott Hanselman’s Bring Kindness Back to Open Source. The bugs are labelled first-timers-only.

You might also find this Twitter bot helpful. It tweets out all issues labelled as “first-timers-only”.

Another great way to find issues is YourFirstPR by Charlotte Spencer. They showcase starter issues on GitHub that can be easily tackled by new contributors.

Awesome-for-beginners is a GitHub repo that amasses projects with good bugs for new contributors, and applies labels to describe them.

Openhatch is a non-profit organization that helps lower barriers of entry into open source. You can find bugs and projects here, as well.

The Mozilla Contributor Ecosystem

A lot of Mozilla’s projects are hosted on GitHub. For these projects, everything I listed above is still useful. They use the label “good first bug” for starter issues.

But Mozilla also uses its own tool called Bugzilla as its primary issue tracker. They host some of their issues here, and use Mercurial for version control instead of Git.

Firefox is one of the projects that uses Bugzilla and Mercurial. It’s a bit scary, to be honest. It’s a lot to take in. So I recommend this excellent blog post and video, which does a great job at demystifying these tools.

Over the years, Mozillians have tried to make it as simple as possible to contribute to Mozilla. Here are their efforts:

• Good First Bugs: These are bugs that developers have identified as a good introduction to the project. They are often (but not always) relatively easy to solve
• Mentored Bugs: These bugs have a mentor assigned who will be there on IRC to help you when you get stuck while working on fix. They often review your patch and give feedback. If you don’t know where to begin with contributing to Mozilla projects, this is the best place to start. You’ll have someone who can answer your questions when you feel you’ve run up against a wall. All the mentors I’ve worked with have been super responsive, supportive, and helpful throughout.
• Bugs Ahoy: This is a site dedicated to finding bugs on Bugzilla. It has a friendly UI, where you can filter by language.
• Firefox DevTools: This site is dedicated to bugs filed for the developer tools in the Firefox browser. You can sort based on the DevTools components you want to work on.
• What Can I Do For Mozilla — This is a great way to explore and figure out what you can work on by answering a bunch of questions about your skill set and interests.
• Start Mozilla: This is a Twitter account that tweets about issues fit for contributors new to the Mozilla ecosystem.

If you know of any other resources for finding good bugs for newbie contributors, please let me know in the comments. I will be more than happy to extend this list.

If you think this post was useful, please tap the “︎❤” to help to promote this piece to others.