Custom Fields in Bugzilla
Bugzilla currently only has limited support for custom fields, and often they are not the solution you want anyway. This page gathers together the options you have if you feel the burning desire to add extra fields to your installation of Bugzilla.
Option 0: Do nothing
The first thing to ask yourself is: do you really need this field? Joel Spolsky, a respected software engineer, whose company writes a proprietary bug system called FogBugz, has written a well-thought-out piece about why his software will never support custom fields. It points out that several of the reasons often given for adding a custom field are bogus.
Option 1: Turn the feature on
If your mind is made up, then the second question is: does Bugzilla actually already support what you want, and you just need to turn the feature on? For example, if you want a field to add an email address to be notified on every bug, enable QA Contact and use that. If you want fields to track what time is spent on each bug, turn on Time Tracking. Check the "Bug Fields" section of the Parameters.
Option 2: Bug entry templates
But if Bugzilla really doesn't directly support what you want, then the third question is: do you really want a custom field, or do you just want to inject more order and structure into the bug filing process? Your organisation or project may have inexperienced people filing bugs, and you think that the default bug filing form doesn't prompt them for the right information. If that's the case, you should investigate bug entry templates, which were invented to solve just this problem (see the bottom of the page.) This allows you to define arbitrary fields in the bug filing page, and put the resulting values into the bug's initial comment.
Option 3: Keywords
But, a disadvantage of bug entry templates is that you can't easily search on the contents of the new "field", short of doing a full text search of the comments. Sometimes you want to label bugs in a way which is more easily searchable. One option here is to use keywords. Bugzilla's keyword system allows you to define a set of textual tags, such as "dataloss" or "crash" and tag any number of bugs with them. For some sorts of data, which perhaps don't apply to every bug, these make more sense than a custom field.
Option 4: Flags
Flags are a bit like a keyword which can have an associated state, and possibly a person. So a "review" flag can have states + (approved), - (declined) and ? (requested), in which case it could also have someone the review was requested from. See the manual for more details. These are a good substitute for custom project management fields.
Option 5: Co-opt an existing field
If keywords don't cut it, then you have the option of co-opting an existing field which you are not using. If you want freeform text, you can co-opt (and edit the templates to relabel) either the URL field or the Status Whiteboard field. If you want a single-select from a list of options, you can co-opt Priority, Severity, Platform or OS. For those four, you define the set of possible values on the "Field Values" configuration page. If you want an email address, turn on QA Contact. If you want multiple email addresses, make a mailing list the QA Contact.
Option 6: Use the limited custom field support
This is available in Bugzilla 3.0 and above. You can add custom fields which are either freeform text or one-from-many selections. See the documentation on the Bugzilla website.