In this post, I am going to go down memory lane and talk about my contributions to one of the open source communities I contribute to. The post is long so if you don’t have lots of time, you can read the short and sweet version here:
TLDR:
- Joined Mozilla in 2012
- Sent email asking to contribute, worked on low hanging Quality Assurance (QA) tasks
- Talked about Mozilla products and privacy at a number of events
- Invited to join Participation Team and Reps program (community building and leadership programs)
- Built team of five local contributors, strengthened and supported teams in the region, represented Mozilla officially in Africa at events e.g AfricaCom, Tech4Africa
- Formed Zimbabwe team, taught privacy, digital literacy
- Triaged bugs, mentored new testers
- Did QA for Firefox and Firefox OS on Desktop, tablets and smartphones
- Was part of Firefox OS Launch Team. Demoed Firefox OS devices at trade shows
- Tested a number of Mozilla sites. Worked on Mozilla Developer Network, Mozilla community Directory, Firefox Addons site and the main Mozilla website.
Leveling up
For as long as I can remember, I’ve always loved, preferred and advocated for the use of Free and Open Source Software. In 2010, I decided to find an open source project to contribute to. I did this for three reasons; I wanted to give back to the Open Source community, meet new people and improve my skills.
Back then, I was in my first year at a Polytechnic and I had next to zero technical skills. I knew that if I was going to contribute to a project, I would have to perform many seemingly non-technical tasks like correcting spellings or responding to support requests and things like that. I wanted to contribute to a project that had a beginner friendly and welcoming community as well as clear steps on how to get involved.
I like the web, networks and the Internet. The project I got involved with had to be a player in this space. I researched a lot of projects and the skills required to contribute code to each one. I quickly figured out that I would need to learn HTML, CSS, JavaScript and a general purpose programming language like Java or C++ because that is what most projects used.
I started learning about making web pages using HTML sometime in 2011 or 2012 through a website called P2PU. While learning, I found out about Mozilla and how it was a non profit that made the Firefox browser. I was drawn to Mozilla because it is a web company and their mission to create a free and open web resonated with me.
In this post I’ll go over how I got involved with Mozilla and what I accomplished. Many of the contributions I describe here happened between 2012 and 2018, note that the order I list them in isn’t chronological, I just grouped similar activities together.
Choosing a project
I visited the a “Contribute to Mozilla” page on their website and signed up to be a volunteer tester. This was the easiest thing I could do given my modest skills. Deep down, I didn’t think anyone would respond to me given how big Mozilla is. Shortly after that, one of their Quality Assurance Engineers (Rebecca Billings) got in touch with me and explained what her team was working on at the moment and how I could get into it and start contributing. I was pleasantly surprised.
Testing
I started working on low hanging quality assurance and manual testing tasks for Mozilla websites such as the Firefox Addons Site. As I got more experience, I worked on testing pre-release versions of Firefox and other Mozilla websites including mozilla.org, Mozilla Support site, the Mozilla community directory and the Mozilla Developer Network
Testing involved working with Mozilla engineers to ensure that each website feature or Firefox version worked according to specification and that reported bugs were addressed and resolved. If a particular feature didn’t work the way it was expected, I would file bug reports. I spent a lot of my time watching incoming bugs on Mozilla’s bug tracker and triaging them. This is a fancy way of saying I sorted the bugs, assigned them to the right people and worked on getting as much detail and information from bug reporters as I could to make it easy to fix the bug.
Firefox
Firefox follows a 6 to 8 week release cycle meaning that every 6 – 8 weeks there’s a new official Firefox release. During that time a number of things happen behind the scenes. Beta versions of the browser are released, tested and fixed before the code is finally built, validated and tagged for release to the general public.
Every day, Mozilla developers write code that is merged into a common code repository (mozilla-central) and every day that code is compiled so as to create a pre-release version of Firefox based on this code for testing purposes, this is called a Nightly build. Nightly is shipped with all the bleeding edge and experimental features that Mozilla wants to try out. Because of this, it doesn’t have the stability and quality of the release version. The QA team and members of the Nightly community work on testing the new features, checking that old bugs have really been resolved in the current version and helping to catch new bugs.I worked as a Nightly tester/user for Linux for a couple of years. By using Nightly, I would send crash data and some web-activity data to Mozilla to help improve the browser experience.
After a few weeks, the Nightly code receives patches to stabilise it and the mature nightly code is merged into the Beta branch. Here the browser receives more tests, review, inspection, and polishing until a level of quality is reached that allows Mozilla to ship a new final version of Firefox to millions of people.
I used to take part in what Mozilla calls “Test Days” and “Bug Days”. These are special days in the release calendar that are set aside for thorough testing. On each of these days, I would go through bug fixes to make sure that there were no regressions, verify that the new features introduced in the most recent Nightly stage measured up to expectation and that reported bugs either got fixed or got the attention of the right developers responsible for the Firefox component the bug affected.
When I wasn’t doing boring stuff like filing bugs, I enjoyed testing new fun features and playing with JavaScript APIs that got added to the browser. I wrote a post here about how we tested WebGL and another one here about testing WebRTC, DTMF (Dual Tone Multi Frequency) support and the responsive design mode before these features were released.
I became pretty good at testing so I would help new testers get started and answer any questions they had in IRC or via email. I received a few notable mentions on the Mozilla Quality Blog on some of these test days.
Firefox OS
In 2011 Mozilla started work on a project called B2G (Boot to Gecko) that would later be known as Firefox OS. Firefox OS was a complete operating system based on open web standards and designed for mobile devices and smart TVs.
There’s a ton of work that goes into developing a new OS. From a Quality Assurance perspective, Firefox OS needed to be tested regularly, defects had to be reported, feature gaps had to be identified, the UI needed to be translated and incoming bugs needed to be triaged. I worked with multiple teams within Mozilla at this time around Firefox OS. Here are some highlights:
Test Firefox OS on different devices and form factors
I got and used two test devices, a Foxconn tablet and a Fire Flame phone:
I would use the devices for everyday tasks in order to send feedback and telemetry data to Mozilla. During this time I also worked on triaging bugs that were reported by other beta testers.
Translation (L10N)
A common saying at Mozilla is “Users first, no matter where they are” and one of Mozilla’s goals with Firefox OS was to make it affordable and available to consumers in the third world. One of the ways they’d go about that was making the UI translated into as many languages as possible. I led a team of 4 translators to translate the UI into Ndebele, my native tongue.
Our team made substantial progress in translating the UI but we were unfortunately unable to complete the translation because Mozilla pulled the plug on Firefox OS in 2016. There was a round of layoffs and reorganisation within Mozilla and many people were unhappy with the direction they were taking. I was in that group. I felt hurt that a project I and many other people had worked very hard on was killed without warning or proper communication.
I have digressed a little, back to translating Firefox OS. I learned a lot about how software projects are adapted to different languages and regions while working on the translation project. Here are pictures from one of our translation sprints:
Demonstrating Firefox OS at developer events and trade shows.
From 2015 to 2016, I was part of the Firefox OS Africa launch team. I attended meetups, trade shows, and conferences talking about, and demoing Firefox OS. The most notable events I got to attend are AfricaCom in Cape Town and Tech4Africa in Joburg:
Speaking, Community Building and Engagement
I was invited to join the Participation Team under the Mozilla Reps Program, a program that provides a framework and a specific set of tools to help Mozilla contributors to organize and/or attend events, recruit and mentor new contributors, document and share activities, and support their local communities better. With the training I got from the Reps program, I was able to recruit community members to join the cause as well as support other communities in the region.
A big part of being a Mozilla Rep involves organising events, speaking and training others. I have written about some of these events here, here and here. Here are some pictures from some of these events:
Code
In 2017, I got serious about learning to code and in 2018, I started coding for Mozilla. I authored a few patches that were accepted into the mozilla-central repository (Code base that contains Firefox code) that year.
As of July 2019, that was my last contribution to Mozilla because of work and other personal commitments. I plan on getting back into contributing sometime towards the end of the year.
What I got out of it
Gear
Working on Mozilla projects wasn’t all hard work and no fun though. Mozilla really knows how to take care of it’s contributors and recognize the work they do. I got so much swag and gear from Mozilla that for a long time, I didn’t buy t-shirts. Yes, I said it, I was only in it for the T-shirts and stickers.
Skills.
- I learned how to work in a collaborative, globally distributed team
- Python. I picked up Python in order to write and run automated test Web Driver tests
- Public Speaking. I had the opportunity and resources to speak at many events
- Version control; I learned how to use git, mercurial,used different workflows, pull requests, code reviews and all that jazz.
- Bug reporting. Reporting a problem or a crash entails more than just screaming “It doesn’t work!”.
- Testing. I learned all sorts of testing approaches, tools and frameworks; manual, functional, automated, Selenium WebDriver, Intern, Marionette etc
- Release management. Mozilla follows a release train model to release Firefox builds, I got to see this process up close.
- Good communication and writing skills. I read, wrote and commented on many bugs from diverse contributors around the world so I learned how to communicate effectively with different types of people.
- Networking and meeting new people. I got to travel to many events and Mozilla workshops and conferences around the world. I met most of my friends and professional acquaintances this way. For instance, I met Eric Jung, the founder and CEO of FoxyProxy, a company that develops browser extensions and VPN networks at a Mozilla Summit in Toronto, Canada. Eric would later become my boss.
Recognition
Working as a volunteer contributor to an open source project is challenging because its unpaid work you have to make time for at your own expense. It is easy for your contributions to go unnoticed and this can lead you to feel unimportant and not seen.
I appreciated the efforts Mozilla made to recognise volunteers. Most of the teams I worked with showed appreciation for the work I did by personally thanking me whenever I put in work that made an impact, calling me out at team and company meetings and giving me all the resources I needed to do my work. A simple and specific compliment goes a long way in making contributors feel welcome, I can attest to that.
Mozilla through the Participation and Reps teams, would send me signed letters of commendation from time to time. At one time, I got an email from Mitchell Baker, the Executive Chairwoman of Mozilla Foundation expressing appreciation and acknowledgement of the work I was doing. Quick side note, Mitchell Baker was once included in Time magazine’s list of 100 most influential people and she was instrumental in the creation of the Mozilla Foundation.
At the Mozilla Summit in 2013, I received an award for being the “The Person with the Most Positive Impact” on summit delegates:
Thanks to Mozilla, I got to visit many countries on three different continents and I met and made friends with many, many people along the way. One of the best trips was an all expenses paid trip to Tokyo.
Outside Mozilla HQ in San Fransisco is the Firefox Monument dedicated to contributors. The side panels of the monument read:
“Doing good is part of our code.”
These are the technologists, thinkers and builders, past and present, who help us keep the Internet alive and accessible — a global community dedicated to preserving the power and potential of the world’s largest public resource.
The monument lists the names of thousands of Mozilla contributors and my name is up there. To date, I haven’t had the opportunity to visit San Fransisco to see it for myself but I am greatly honoured by what Mozilla did there.
Conclusion
Being in the Mozilla community changed my life, the work I do is fun, interesting and challenging. If you’re looking for an Open Source project to contribute to, do consider Mozilla. If you’re not sure where to start, here’s a tool to help you on your way.