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. If the ideas on this page are too technical for you, no problem - there's another page that lists ways anyone can get involved.
What Needs To Be Done?
- 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 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.
- Quality Assurance
-
Mozilla QA has a page dedicated to ways to get involved with helping. This doesn’t involve knowing how to code, although a little knowledge of HTML is helpful, and is good for people wanting to get more familiar with Mozilla. Some of the ways to get involved (from that page) include:
- Pre-screen 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’re worthwhile, and which component they belong in.
- Confirm 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. See the confirming page for more details.
- 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’d 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 figure out how the 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. If you’d like to contribute, let us know by posting to the documentation newsgroup.
- 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 newsgroups, status updates, and project 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.