So You Wanna Help Mozilla?
A common theme we heard in responses to our web developer survey was: “I wish I could help Mozilla, but I’m just a web developer.”
Well, fellow web ninjas, you can put your skills to work with Mozilla and help make the web a better place. Our web projects are open, just like Firefox, and we’d love your help!
If you’re a web developer and want to help Mozilla and Firefox users while working on sites that see millions of visitors every day, follow me through the jump and I’ll show you around our shop and introduce you to the tools we use.
Our Projects
Mozilla Web Dev is responsible for pretty much every web site at Mozilla, from Addons to Support to Mozilla.com to Spread Firefox. We also take care of web services like the Application Update Service, Plugin Finder Service and the Crash Report Beacon.
Almost all of our code (everything except Socorro—the crash report beacon—I think) is available on svn.mozilla.org. You can browse around the server and see the source right now. It will all basically run on the standard LAMP (where P is PHP or Python) stack.
Our Tools
The control center of web development at Mozilla is Bugzilla. All our work takes the form of “bugs” here. A “bug” is not necessarily a problem with the software. A new feature or a software update would also be called a “bug.” I’ll talk about the life-cycle of a web development bug below.
IRC is just as important as Bugzilla. Both our staff and our contributors are geographically diverse, and IRC gives us a good way to coordinate and talk to each other around the globe. If you’re new to IRC, ChatZilla is an easy place to start. Most projects have their own channel on irc.mozilla.org, like #sumo for Support and #amo for Addons. We’re also usually in #webdev.
As web developers, are chief weapon is HTML. HTML and CSS. HTML, CSS, and JavaScript. No one expects the… (Sorry.) On the front-end, we chiefly work in HTML, CSS, and JavaScript, and occasionally other technologies like XML. On the back-end, nearly all of our projects are in PHP or Python.
For version control we mostly use Subversion, though git (and git-svn) has gained a bunch of ground lately. (Addons will be moving to git sometime next year.)
To work on your own computer, you’ll probably need to set up Apache, MySQL, and PHP or Python. XAMPP can be incredibly helpful here. Working on Linux (or Mac OS) is usually easier than Windows, and closer to our server environment. A tool like VirtualBox will let you run a Linux virtual machine on most other operating systems. It’s a little slower but switching back and forth is easy. I’ll try to write about my local development set up soon.
Our Workflow
Let’s go over the life of a bug. This is a little long-winded.
A bug is born either when someone describes a problem or when we decide to add a new feature. (Every project has its own way of doing the latter.) Sometimes our Web QA team finds problems, sometimes community members do. Then the bug is created, or filed, usually by the person who discovers it—that could be you!
Once a bug has been filed, possibly after some discussion of the best way to fix it, a developer—and that could be you, too—will “take” the bug, accepting responsibility for fixing it. Fixing a bug means changing the application in some way: changing a behavior, adding a localization, etc.
When the developer believes they’ve fixed the problem in their copy, they generate a patch (Subversion’s “diff” command is useful). They then upload that patch as a new attachment, and request review (r?) from someone else. Who does the review will depend on the project and how busy everyone is. If you’re not sure who to ask, ask in IRC.
The patch will either get an r+ or an r-. An r+ means it’s good to go, and it can usually be checked in to Subversion (unless there are reasons to wait). An r- means there’s something wrong. This can range from a patch containing some extraneous data to a patch not solving the problem, and an r- almost always includes a description of the problem.
When a patch with a positive review (r+) gets checked in to Subversion, the developer will include the revision in the bug and change it from new to resolved: fixed. In a few minutes, the change will appear on a staging server that’s updated frequently with the latest code. Our Web QA staff and contributors will test the bug, compare expected to actual behavior, and with either reopen the bug, if it’s not fixed, or set the status to verified. Then the bug is considered done. Verified bugs rarely reopen.
Once all the bugs for a milestone are done, we “freeze” the source against new commits while Web QA does a final check that everything is in good shape. When QA signs off on the current code, we push the new version onto our production web servers.
So that’s the life of a bug, from filed to production. When it gets to production, your code can be seen or used by millions of people every day.
Join Us
So if you’re a web developer and want to help Mozilla and Firefox, head over to Bugzilla or IRC and get started. We hope to see you soon!
I just want to add one thing in relation to:
“a developer will “take” the bug, accepting responsibility for fixing it”
Don’t worry, taking a bug does not imply you have to figure it all out by yourself. I’m sure all of us webdevs would be more than happy to help you along, especially as you’re starting out. As James is illustrating, we are excited to receive your help and will certainly assist you along the way!
Really, I’d prefer that we stop all this ninja stuff. I’d rather hang out with vikings than ninjas.
@Paul: Absolutely right. No one needs to work in a vacuum.
@Jeff: But Vikings are loud, boorish, drunken… hmm, you may have a point.
I love your “life of a bug” piece. It’s very informative.
I’d like to see Pixar make a movie from it.
There’s some other great ways to get involved and help out Mozilla listed here.
http://www.mozilla.org/contribute/
I think that its important to push Mozilla technology breakthroughs to the web design community. E.g. WOFF and SVG effects on non SVG-content*.
There is a ton of articles on Webkit specific stuff, since the design community is very Apple-centric. E.g: http://24ways.org/2009/
Another example would be Modernizr, which in its current implementation is rather Webkit biased. I know they are working on it and we should see some improvements in coming versions, but it would be great if anyone could give them a helping hand on issues like:
1. How to detect WOFF support programmatically, without causing HTTP requests.
2. How to programmatically detect support for SVG effects. (And SVG!)
* https://developer.mozilla.org/en/Applying_SVG_effects_to_HTML_content
@Lars,
The Mozilla Hacks blog and the Mozilla Developer Network are working to do just that. I’m sure they’d appreciate help, too!
I think it’s also important that we make more noise about features that are safe to use in all browsers. Even as a Mozillian, I don’t want to segregate the internet, or put “best viewed in” back on my web sites. There’s been a lot of progress among all the major browsers, and we should be vocal about what’s really ready for widespread use.
@James Socol
Hi,
I got your email for getting started with Mozilla , I appreciate that you gave me an opportunity to work with you. As I mentioned about my skills regarding the web development , is it necessary to be expertize programmer PHP , as I am fluent with Java.
Secondly, where I can find you to talk personally (splly on IRC)
Thanks
Rupesh
@Rupesh
You can basically always find me in #webdev on irc.mozilla.org. I’m jsocol there.
We don’t, as far as I know, have any web projects in Java. (We have a Live Chat component of Support.Mozilla.com [SUMO] that’s built in Java. Ping me in IRC and I can point you at bug lists and the lead dev on it.) But that doesn’t mean you need to be a PHP expert, either!
We do a lot of HTML, CSS, and JavaScript work, which requires little-to-no PHP knowledge. On SUMO, we’ve started marking certain bugs as good places to start. If you’re more interested in learning Python, Socorro (our Crash Reporter) is a Python app, and Addons (AMO) is moving to it.
Find me on IRC and we can talk more!