- How to Contribute to Bugzilla
- Developers' Guide
- List of Reviewers
- Reviewers' Guide
- Approvers' Guide
- Localizers' Guide
- Documentor's Guide
- Release Noting Guide
- How To Release a Bugzilla Version
- Database Schema Documentation
- The Bugzilla API Documentation
firstname.lastname@example.org - This mailing list is for discussion among people who are assisting with the development of Bugzilla. Discussion on this list tends to get quite technical. If you're interested in contributing code to Bugzilla, you should subscribe to this list. Subscribe / Browse Archives
Much Bugzilla development discussion happens in real time on IRC. We hang out on the #bugzilla channel on irc.mozilla.org. Feel free to drop in there anytime to discuss Bugzilla (both development and support discussion happens there).
The easiest way to get on IRC is to use the Bugzilla IRC Gateway, which lets you chat with us through your browser, without installing anything.
How to Help
Patches to Fix Bugs/Implement New Features. These are very welcome, especially if they are targetted for the upcoming release! They need to be appropriately generic for all Bugzilla installations and conform to our other requirements (see the Developers' Guide) before they can appear in our repository, but if you don't wish to do this, anything is better than nothing, and we can use your work as a base. Read our step-by-step process for information on how to get your patch submitted to us.
Some good places to start:
New documentation. If you are an aspiring technical writer and are familiar with (or willing to learn) DocBook, the Bugzilla documentation needs a lot of love. There are a lot of features in Bugzilla that have still never been documented, and Bugzilla is a rapidly moving target. Besides the never-ending battle to keep the cvs tip documentation up to date, we have documentation on two supported stable branches which is still somewhat incomplete. Patches against the source xml using
diff -uare the prefered method of submitting changes.
Some good places to start:
- Open documentation bugs/requests
- Fixed bugs requiring documentation changes that haven't been made yet. Patches for these can be attached to the same bug.
- File a new bug for additions to the documentation not listed in either of the above two links, then attach your patch to the bug.
- Localisation. Localise Bugzilla into your language and make a localisation pack available. More details.
- Testing. Search for bugs in the Bugzilla software, as well as trying out pending patches in the bug system.
- Review. If you have experience with Perl and Bugzilla code, it would
be very useful if you look over pending patches in the bug system
and see if there are any problems with them. As we are coming off the tail
end of a templatization effort which put tons of little patches on hold for
over a year, review and testing of those remaining patches is especially important.
Generally we expect reviewers to have submitted some patches first
so we can evaluate their ability. If you fit into this category, please
contact Dave Miller about
this. We are currently in particular need of reviewers with expertise in
the following areas:
- LDAP authentication
- Installation on Windows
- Automatic Problem Finding. If you have ideas for automatically detecting problems, please let the team know by filing a bug in the Testing Suite component.
The Bugzilla team mainly communicates through the IRC channel #bugzilla on irc.mozilla.org. All are welcome on this channel, whether you are an administrator of a Bugzilla installation or wish to contribute. The more the merrier.