Start with the basics
Before you start to try and hack, you need to learn how to get around Bugzilla. Triage/QA/searching bugs for a couple weeks or longer is a good minimum requirement before you think “hey, I want to hack Firefox.�? Discovering how the project works, learning to sift for what matters, and applying lessons learned in the initial triage process will go a long way to finding your way through reviews and checkin. Picking something you find randomly isn’t usually the best thing to start with. Seeing what’s well-owned and what needs extra attention is also a good starting point for hacking.
Build the Fox
I could rehash what’s been better-written by others, but I won’t. Start with the generic instructions here, make sure you use CVS trunk, and get the beast built. You need to be able to make this work before you attempt to take the next step. Yes, it isn’t trivial to build anything from Mozilla CVS, but if you can’t figure it out even with help, you’re probably not ready yet. If I can go from “never compiling anything�? to “building on win32″ in an hour or so.
Source Code Organization
The next problem is “where does the app/front-end code live?�? Firefox-specific code lives here, and generic FE toolkit code lives here. (In your CVS tree, it would be mozilla/browser and mozilla/toolkit, respectively.)
Picking bugs to work on.
Votes sort of matter. Sort of. Sometimes its a simple matter to make it happen too, and if there’s low-hanging fruit, pick it. Other times, bugs with “good first bug�? in the status whiteboard are good places to go to find your way around. And of course, stuff that annoys you is good too. Lots of good personal satisfaction involved there.
Knowing where to ask for help
#developers on the Mozilla IRC server is a good place to start if you can’t figure it out on your own. But exhaust other resources first, like lxr/bonsai/google (and this wiki) before you bug real people. If its a “how should the UI look�? question, asking Mike Connor or another Firefox peer is probably your best plan, unless you’re ready to argue your case.
Changing the User Experience
If you’re thinking of implementing a feature request, or changing behaviour that will affect the user experience, it’s best for everyone concerned to get feedback before you start. Talk to Ben Goodger, Mike Connor, or one of the other Firefox peers, get reaction/adjustments. If we say its a no, you’ve just saved yourself a lot of stress and resentment (based on how people who don’t follow this role have reacted to review- in the past).