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:
- names of people involved in something I’m intrigued by
- locations in the tree of code that I’m interested in
- other information from the bug – components worth paying attention to, dependencies, blockers, etc
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.
Got a story? Please share! I’d love to hear how other people’s experiences differ.
