You are currently viewing a snapshot of www.mozilla.org taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to www.mozilla.org, please file a bug.



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.

Easy Ways You Can Get Involved With Mozilla

Did you think you had to be a developer to make a difference in the Mozilla Project? Think again. Here are ways anyone can get involved with Mozilla.

For the More Technically-Oriented

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, search Bugzilla to make sure your bug has not already been reported. If it has, then feel free to add any extra details you can. Read the bug writing guidelines before submitting a new bug.

Quality Assurance

Mozilla QA has a page dedicated to ways to get involved with helping. This does not involve knowing how to code, although a little knowledge of HTML is helpful. This is a good area for people wanting to get more familiar with Mozilla. Some of the ways to get involved (from that page) include:

Pre-screening Browser-General Bugs

The Browser-General component in Bugzilla receives hundreds of browser bugs every month. All of these bugs must be reviewed to determine whether they are worthwhile and which component they belong in.

Confirming the Unconfirmed

Bugzilla bugs filed by new bug filers start in the UNCONFIRMED state, which means that someone has to verify that the problem is actually a bug. This could be you.

Join The BugAThon

Bugzilla receives many bugs that engineers could fix faster if they had simplified test cases. Many bug reporters merely provide a URL, without isolating the bug's root cause. As a result, engineers must spend their time isolating these bugs, rather than actually fixing them. If you would like to help ensure engineers are fixing DOM and layout bugs rather than dissecting bug reports, join the BugAThon and get involved!

Fix Bugs

Is there some bug that really bothers you? Instead of just reporting it, feel free to fix it as well. To learn how the bug-fixing process works, read the hacking documents, particularly the life cycle of a patch.

When you start working on a bug 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.

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.

Contact Web Sites That Have Problems

Do your favorite web sites work properly in Mozilla or other Mozilla-based browsers? If not then you can help Mozilla succeed by helping to convince web sites and web developers to develop cross-browser, standards-based content which supports Mozilla.

You can help with the Mozilla Tech Evangelism project by filing Tech Evangelism bugs on sites which do not work in Mozilla, by triaging existing Tech Evangelism bugs, and by complaining to sites that they do not support your favorite browser!

If all else fails, as you read the news groups, status updates, and projects home pages, keep an eye out for people asking for help. If you notice people moving bugs or features back to later milestones, you might try asking if they need help with that item. If bugs in Bugzilla are marked more than a couple milestones off, maybe the owner of the bug could use some help. Try doing a Bugzilla search for bugs set to a milestone or two greater than the current one.