This section distills some Bugzilla tips and best practices + that have been developed.
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: +
| bug 12345 |
| bug 23456, comment 53 |
| attachment 4321 |
| mailto:george@example.com |
| george@example.com |
| ftp://ftp.mozilla.org |
| Most other sorts of URL |
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. +
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.
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. +
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. +
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. +