3.2.1. autolinkification

bugzilla comments are plain text - so posting html will result in literal html tags rather than being interpreted by a browser. however, bugzilla will automatically make hyperlinks out of certain sorts of text in comments. for example, the text http://www.bugzilla.org will be turned into http://www.bugzilla.org. other strings which get linkified in the obvious manner are:

a corollary here is that if you type a bug number in a comment, you should put the word "bug" before it, so it gets autolinkified for the convenience of others.

3.2.2. quicksearch

quicksearch is a single-text-box query tool which uses metacharacters to indicate what is to be searched. for example, typing "foo|bar" into quicksearch would search for "foo" or "bar" in the summary and status whiteboard of a bug; adding ":bazproduct" would search only in that product.

you'll find the quicksearch box on bugzilla's front page, along with a help link which details how to use it.

3.2.3. comments

if you are changing the fields on a bug, only comment if either you have something pertinent to say, or bugzilla requires it. otherwise, you may spam people unnecessarily with bug mail. to take an example: a user can set up their account to filter out messages where someone just adds themselves to the cc field of a bug (which happens a lot.) if you come along, add yourself to the cc field, and add a comment saying "adding self to cc", then that person gets a pointless piece of mail they would otherwise have avoided.

don't use sigs in comments. signing your name ("bill") is acceptable, particularly if you do it out of habit, but full mail/news-style four line ascii art creations are not.

3.2.4. attachments

use attachments, rather than comments, for large chunks of ascii data, such as trace, debugging output files, or log files. that way, it doesn't bloat the bug for everyone who wants to read it, and cause people to receive fat, useless mails.

trim screenshots. there's no need to show the whole screen if you are pointing out a single-pixel problem.

don't attach simple test cases (e.g. one html file, one css file and an image) as a zip file. instead, upload them in reverse order and edit the referring file so that they point to the attached files. this way, the test case works immediately out of the bug.

3.2.5. filing bugs

try to make sure that everything said in the summary is also said in the first comment. summaries are often updated and this will ensure your original information is easily accessible.

you do not need to put "any" or similar strings in the url field. if there is no specific url associated with the bug, leave this field blank.

if you feel a bug you filed was incorrectly marked as a duplicate of another, please question it in your bug, not the bug it was duped to. feel free to cc the person who duped it if they are not already cced.