getting involved

So you want to help? Great! You don't have to be a C++ guru and you don't need to spend lots of time. A big portion of the help we need is feedback and bug reports.

Start out by test driving mozilla. Download a binary and get a bugzilla account. You'll need the bugzilla account to report bugs. Before you do so, be sure to read the bug writing guidelines. If you plan to code, read the hacking documents.

Whenever you begin work on something that's more than a day's work, we strongly recommend that you let people know about it. Post your plans to an appropriate newsgroup (See the owner's page for more details). If you're working on fixing a bug, make a note of it in bugzilla to track your progress and to catch the attention of others. If no bug exists already, then file a bug and assign it to yourself. When adding features, consider adding an enhancement request for the feature in bugzilla and assigning it to yourself. An enhancement request is a bug whose severity is "enhancement".

Publicizing your efforts lets others know what you're working on so they can coordinate their work with yours, offer help, and avoid duplicating your work. It opens your work up for peer review, and provides an archive so the same issues don't need to be repeated. Also, if someone else is working on the same thing, they can let you know and save you a lot of work.

What Needs To Be Done?

Write documentation

We need documentation for users, web developers, and developers working on mozilla. If you write your own code, document it. Much of the existing code isn't very well documented. In the process of figuring things out, try and document your discoveries. If you'd like to contribute, let us know by posting to the netscape.public.mozilla.documentation newsgroup and mailing webmaster@mozilla.org.

Report Bugs

Start by downloading a binary. Use it as your everyday browser and report bugs when you find them. Before submitting a bug report, query bugzilla to make sure your bug hasn't already been reported. If it has, then feel free to add any extra details you can. Before submitting a new bug, read the bug writing guidelines. Bug reports should be carefully written so engineers can easily reproduce the problem. If they can't, it will be difficult or impossible for them to fix the bug.

Run Tests

Mozilla QA has sets of tests designed to exercise many different aspects of the browser. Help out by running their tests or by writing your own test cases. Here are their Browser and Mail/News tests.

Write Test Cases

Many bugs would be easier to fix if very specific test cases were written for them. This is especially true of layout bugs. A new bug report might say that something is wrong at a given url. Analyze the html at the url and simplify things until you find the simplest form that exihibits the problem. For instance, if you found that a problem only occurs in nested tables with an odd number of columns, that's useful information that lets the owner of the bug spend more of their time fixing bugs and less time diagnosing. Read about the BugAThon for more information on writing test cases for the layout engine and the DOM.

Read about editor API logging for more information on writing editor test scripts. Record your keystrokes while using the editor and save them to a file. Attach the file to a bug, and engineers can replay your keystrokes and more easily recreate and fix bugs with the editor.

Save The Most Doomed

Help people on the most doomed list. As milestones near, a milestone status report and bug list is posted to the mozilla.seamonkey news group by Chris Hofmann. This lists the number of bugs for each developer at the next milestone. Those with the most bugs to fix before the next milestone release are the most doomed. Help these people by going through their bugs lists and searching for bugs that are duplicates, writing test cases, attaching screen shots, and adding more feedback to bug reports, or fixing the bug. Be sure to do your testing with as recent a build as possible. If you don't compile your own tree, try using a nightly build. If you find a bug you think is a duplicate make a note of it in the comment section and let the bug owner be the one change the bug's status.

Save The Most Recently Doomed

The most recently doomed are people who have the most new bugs. When bugs are first entered, they are often assigned to the wrong person, are duplicates of other bugs or are invalid (perhaps because it's a Navigator 4.X bug). In addition, bug reports can be improved by verifying that the problem can be reproduced on other platforms, under different conditions, or perhaps by adding a test case, or screen shot. The Browser Bug Count Report and the MailNews Bug Count Report lists the number of new bugs by engineer.

Someone who is chronically doomed is Don Melton, who owns the default component for the browser. When people enter bugs and don't set the component component, the bug is assigned to him and he has to spend time weeding though dozens of bugs and assigning them to the right people. You can speed up this process and direct bugs to engineers more quickly by looking through these recently entered bugs and figuring out which component they actually belong to so bugzilla can route the bug to the right person.

To decide whether a bug is newly entered, its status should be NEW, be owned by don@netscape.com, and not have a target milestone assigned. Bugs with a target milestone have already been reviewed by Don, as have bugs in the Browser-General component with owners besides him. Bugs with entries in the Status Whiteboard or lots of comments by engineers have probably also been reviewed so tread lightly on these bugs. Better yet, just click the query link given above.

Fix Bugs

Is there some bug that really bothers you? Instead of just reporting it, feel free to fix it as well. Create a patch and attach it to the the bug in bugzilla. People will then be able to review your patch and apply it. For a list of some of the more important bugs, see chofmann's watchlist.

When you start working on a bug be sure be sure to indicate this by making a note of it in bugzilla in the "additional comments" box. This lets others know that someone is working on the problem and helps reduce duplication of effort. When you're done, create a patch with "cvs diff -u" and attach the patch to the bug. Others can then try out your patch. If everything works, the owner of the bug will apply the patch and close the bug. If you're adding a feature, create an enhancement request for your feature and assign it to yourself. Go to Bugzilla and enter a new bug. Set the severity to 'enhancement' and the owner to yourself.

Improve Performance

One of our goals is for mozilla to be fast and efficient. Try running it in a profiler or check for memory leaks with a tool like Purify. Even if you don't fix any code yourself, the data from these tools can be helpful. Read the newsgroups netscape.public.mozilla.performance and netscape.public.mozilla.performance.size-matters for more info. Look at the purify logs published by the Mail/News group. Search for memory leak bugs in bugzilla.

Write Code

Feel free to participate in any of our projects or propose one of your own. You probably already have a good idea of what you'd like to work on, but if you're just looking for ways to help get the job done, here are some suggestions.

HELP WANTED

Search for items in bugzilla marked HELP WANTED. A developer may mark bugs or enhancement requests this way if they think an item is worth doing but they can't do the work themselves right away or if they need someone else's expertise. Search for the words HELP WANTED in the Status Whiteboard field. Working on these items may help get things working in Mozilla ahead of schedule or may implement a feature that had originally been dropped due to time constraints. (This is new, so there aren't too many items marked yet)

Build Warnings

Fix build warnings. Check out the tinderbox warnings page which is a summary of the build warnings that's created using cvsblame. When a warning shows up in the unix build log, whoever touched that line last gets blamed. When you fix warnings, create a patch, create a new bug in bugzilla and attach the patch to it. Then post a note to the mozilla.builds newsgroup to announce your fix and its bug number.

Enhancement Requests

Browse through bugzilla's enhancment requests and see if there's anything you'd like to implement. Here is a list of new enhancement requests. If you decide to work on one, assign the bug to yourself and add a comment saying so. Post to a newsgroup explaining what you plan to do.

When you have working code, attach a patch file to the enhancement request in bugzilla and announce your hack in an appropriate news group. Give the bug number and let people try out your patch. Do this for each new version of your patch. If people agree this is a good thing, it can be checked in.