Getting Your Work Into Mozilla
Pages: 1, 2, 3, 4
Taking part: newsgroups, IRC, helping others
Once you've become acquainted with mozilla.org by studying the web site, you can begin to take a more active role in the project.
Newsgroups
If the mozilla.org web site is the front door of the Mozilla project, then the netscape.public.mozilla.* newsgroups are the foyer. Reading and taking part in the discussions going on in such active newsgroups as netscape.public.mozilla.xpfe, netscape.public.mozilla.builds, and netscape.public.mozilla.seamonkey, you can very quickly get acquainted with many of the day-to-day challenges in Mozilla development and in your area of focus. You can also see which contributors are busiest in which areas and begin to take a role yourself as a helpful advocate, tester, teacher, or engineer.
There are dozens of newsgroups available in netscape.public.mozilla.*, and you will find that Mozilla developers are more likely to respond to questions and discussions in newsgroups than by e-mail, since the newsgroups give developers an opportunity to confer, to share, and to verify the information that is being disseminated.
The Mozilla IRC channels
Even more specific and fast-paced than the newsgroups are the two or three IRC channels that Mozilla developers use to communicate with one another about development matters. You'll see the that IRC channels #mozilla, #mozillazine, and #qa are busy with just the vexing and technical issues you'll be faced with when you edit, contribute to, and build the source code.
To access the IRC channels on Mozilla's IRC server, you can use one of the many shareware IRC clients, such as mIRC, or you can use Mozilla's own Chatzilla, which is available on the mozilla.org web site and can be accessed from the Tasks menu of the Mozilla browser once it is installed.
Finding and fixing: Bugzilla and the source code
Taking part in Mozilla discussions, you will very often see references to bugs and bug numbers. These bugs are stored in a massive database called Bugzilla, which was a tool developed by Mozilla and which many developers have appropriated for use in their own development and project management environments. Very often in the newsgroups or in IRC, you will see problems identified with or answered simply by numbers, as in the following example:
Moz1: Hey, why doesn't the profile window pop up in today's build?
Moz2: I think that's 52445.
Alphanumerica's foray into the world of bugs began with a bug that someone wrote about needing to have a way to recover data on crashes. This bug, bug number 36810, formalized the need for a feature of the kind that Alphanumerica was already working on. If you haven't already, look at the bug and see what kinds of information are exchanged in the bug database; you will notice that the tone of the bug comments is broad and informal, and that the comments identify all kinds of things happening with that particular feature or bug. The QA contact, the responsible engineer(s), the steps to reproduce a bug, related bugs, status, priority, and many other pieces of information are associated with a bug.
Before bug number 36810 was written, Alphanumerica was having a difficult time finding a way into the code base. In a sense, a bug provides a forum for discussion and development; it can legitimize the wishes of users and the ambitions of developers.
Preparing your work for submission
This section describes some of the ways in which your work must be validated and prepared before it can be submitted to Mozilla for inclusion in the source.
Give yourself some credit: licensing your work
Before you are ready to submit anything to Mozilla, you will first need to
give yourself some credit for the work that you have done. You can do
this by prepending the Mozilla Public License to each of the individual files in your code. This basically states that you are granting the Mozilla organization rights to use your code in their project. Without this, it would be illegal for anyone to take your code and reuse it in Mozilla.
The MPL is fairly straightforward to use. On the mozilla.org site, there are copies of the license that have blanks in the areas that you need to fill out. These blanks are mainly for putting your name as the copyright holder of the code and for identifying the contributors who helped with the project.
For Total Recall, the license simply states that Alphanumerica created this function and that Pete Collins, Joshua Lerner and David Boswell worked on it.
Commenting and documenting your work
Good documentation is always important, but in an environment as collaborative and open as Mozilla's, it's essential. Whether it's better for you to comment your code in clear detail or create separate documentation such as "getting started" documents, READMEs, or installation instructions, you must provide documents that explain what your project is about and what your code does.
The Mozilla community uses a couple of different tools for commenting source code. The main tool is LXR, which is described below. You don't need to do anything special to your code so that it generates the HTML pages of the source code that LXR displays, but it always helps if you explain what each element, function, or module in your code does.
Mozilla also encourages developers to use JavaDoc-style comments in their code (see example below), from which other developers can generate reference documentation by using a tool like Doxygen.
JavaDoc style comments: /** * ... text ... */
See the Doxygen site's Documenting the code for more information about commenting code for use with documentation systems such as Doxygen and JavaDoc.
