I realize that while I’ve been contributing to Mozilla since last July, I’m still quite new to a lot of the process and knowledge that more experienced developers take for granted. Therefore, I’m going to document the steps I’ve taken to increase my understanding and involvement in hopes that it generates some discussion on the best way to help new people get their bearings.

One of the most inviting aspects of the project right off the bat was that I had a point of contact. Benjamin Smedberg announced in a blog post that the Electrolysis project could always use more help, inviting interested people to get in touch with him. This was an immense help, as he pointed me towards a really good introductory bug that forced me to explore and learn about IPDL, IDL, XPCOM, Javascript, the build system, and more. This was perfect for me; I’m always looking to expand the horizons of what I know, and my work hooking up e10s with the typeaheadfind component allowed me to do just that.

I find that one of the largest hurdles for getting involved in any project for me is lack of knowledge. You’ve got a source checkout, and you’ve got a problem to solve, but no idea where to start. If you’re courageous, you can start dipping into random files and window shopping until you find something that looks promising. However, this approach is inefficient. As I said, I really like to expand the breadth of my understanding as quickly as possible, so here are my patented steps to getting a better handle on the source tree:

Subscribe to an RSS feed of commits

Hang out in IRC channels

Watch interesting Bugzilla users

The trick here is to have lots of information available for consumption, and to sample a wide variety of it. I read commit logs every morning, pick out entries that catch my attention and skim the commit. If I’m still interested, I’ll visit the original bug and read through its history. Through these actions, I am now in possession of:

IRC channels are a great way to act sponge-like. Many diverse conversations on all sorts of interesting code-related topics occur in #developers, while more focused channels like #content and #static allow me to pick up new concepts and insights into the work that I’m currently doing. Furthermore, they’re points of contact for people who are usually happy to help out when I’ve got a question.

Finally, Bugzilla is a goldmine of fascinating activity and information. When I started working on electrolysis, I realized that all of work I was interested in was clusted in the Core:IPC, so I set up an email watch on the QA contact for that component. Eventually, however, I wanted to diversify, so I began to follow specific users. Watching the activity of the polyglots of the project, those who dip in and out of every component is a great way to quickly become exposed to the wealth of work being done. There’s a downside to this: the more users you watch, the more intimidating your bugmail becomes. Today, I ended up receiving 270 emails over the course of one hour because roc decided to unassign himself from a crapload of bugs at the same time as a bunch of dependencies were added to some Jaegermonkey tracking bugs. However, I’ve become adept at quickly deciding whether a conversation thread is interesting to me or not, and these deluges are infrequent.

When it comes to learning about specific pieces of code that confuse me, I have another system. If it’s some fundamental concept that I need to grok (nsCOMPtr, ns*String, etc.), I turn to the faithful Google search: “mozilla X”, X being the unknown item, and 99% of the time the first result will be the relevant MDC page. If I’m more interested in quickly locating pieces of code, I pull out DXR and make use of its wonderful search limiters such as member: or derived:. If what I’m looking for is a piece of C or JS code, or simply isn’t indexed in DXR (m-c only), I haul out mxr and search there. If I do a few searches and can’t find what I’m looking for, it’s usually off to the friendly folk in #developers.

There’s one specific moment I remember from when I was starting out – my very first review. I’d submitted my first attempt at the typeaheadfind work, and to my horror, and email arrived with the subject “review denied.” I felt crushed. Reading through the review, I saw that many good points were made, but it was hard at first to shake the feeling that my code was simply not good enough. I’ve gotten better at accepting review- since then, but I feel that a simple change to the email subject (“review complete“) would go a long way to improving that user experience.

So that’s it, really. Through the application of these methods, I’ve gained enough knowledge to submit a bunch of patches, log some bugs, and start answering other people’s questions. It’s really just been a process of perseverance, asking the right questions, and making use of the correct tools.

14 Responses to “Getting involved with Mozilla”

Great blog post! It describes almost exactly the process I went through to familiarize myself with Mozilla. For a while I was known as “that guy who CCs himself everywhere”, and watching incoming bugs filed, reading bonsai (hgweb’s precursor), and hanging out on IRC were how I managed to get a “big picture” view of both the people and the code that make up Mozilla.

Yeah, we could probably use a more formal writeup of this. I would guess it’s how almost everyone who is currently an expert became one. It’s probably the same process you’d use in any context, just immersing yourself in the material until you understand it, but the specifics of doing so in the Mozilla world are useful. Personally I just made a habit of loading the bugzilla page for every bug I saw mentioned anywhere (in irc or forums or blogs, whatever) and at least skimming them. After a while you start to make lots of connections, and get an inherent sense of what’s going on and where to find things.

rimimirim ! For their mumper all his perch atop of the top their annuitants’ acorns not The war of lithium and presenting a celt, an angle of recalling a bland old holmsted here. Futhorc, this country asked by the bottol of their old vic, to provoke it. Wave bore some shine off the rascals came at it, like the seen your roughshod mind, is, was billowing across the prise of this glaubrous phace of Hippo outpuffs the mann to write a Geese; Gettle Nettie, Thrust him in (pardonnez-leur, je vous en son of, the macdublins on the crown and commutative

quite good content. I want to involve as developer in firefox project. However, same as you, I do not really know where I can start. First of all I have a setup my development environment. Do you have any preference, which editor is used or which IDE. I came from Java and ABAP background, therefore I do not have any preference for a linux based editor.

Hi Steve,
Personally I use emacs for everything. Other people on Linux swear by vim, while others like to use gedit. Just find something you’re comfortable with – the most important part is what you do with it!

same problem; I just created an account and I really want to get involved. I read a lot of interesting things but I have no clue how and where can I start; plus I do no know about IPDL, IDL … except javascript.

I wanted to get involved in fennec android . I have made the build . Now i really wanted to start working on source code for fennec. I need help in finding the url for source code explanatory docs. Give me any suggestions to start with it.

Thank you to all of you. Although I haven’t officially “started” anything yet, I appreciate reading as much as possible on helping to develop and enhance Mozilla’s apps (am I using the right terminology?) I don’t even know how to CODE….but I’m determined to learn! I AM GOING to DO THIS! Not for gain or glory, but to help broaden the horizons of the “sheep” that walk this planet! So on that note if ANYONE can recommend ANY reading material that might help me to understand coding, javascript, or anything ELSE that could help me at least be in the vicinity of the launchpad I would greatly appreciate it!