Classifications tend to be used in order to group several related products into one distinct entity.
Versions are the revisions of the product, such as "Flinders 3.1", "Flinders 95", and "Flinders 2000". Version is not a multi-select field; the usual practice is to select the earliest version known to have the bug.
A Component is a subsection of a Product. It should be a narrow category, tailored to your organization. All Products must contain at least one Component.
Components are subsections of a Product. E.g. the computer game you are designing may have a "UI" component, an "API" component, a "Sound System" component, and a "Plugins" component, each overseen by a different programmer. It often makes sense to divide Components in Bugzilla according to the natural divisions of responsibility within your Product or company.
Each component has a default assignee and (if you turned it on in the parameters), a QA Contact. The default assignee should be the primary person who fixes bugs in that component. The QA Contact should be the person who will ensure these bugs are completely fixed. The Assignee, QA Contact, and Reporter will get email when new bugs are created in this Component and when these bugs change. Default Assignee and Default QA Contact fields only dictate the default assignments; these can be changed on bug submission, or at any later point in a bug's life.
A "bug" in Bugzilla refers to an issue entered into the database which has an associated number, assignments, comments, etc. Some also refer to a "tickets" or "issues"; in the context of Bugzilla, they are synonymous.
Voting allows users to be given a pot of votes which they can allocate to bugs, to indicate that they'd like them fixed. This allows developers to gauge user need for a particular enhancement or bugfix. By allowing bugs with a certain number of votes to automatically move from "UNCONFIRMED" to "NEW", users of the bug system can help high-priority bugs garner attention so they don't sit for a long time awaiting triage.
Flags are a way to attach a specific status to a bug or attachment, either "+" or "-". The meaning of these symbols depends on the text the flag itself, but contextually they could mean pass/fail, accept/reject, approved/denied, or even a simple yes/no. If your site allows requestable flags, then users may set a flag to "?" as a request to another user that they look at the bug/attachment, and set the flag to its correct status. Flags convey information on the quality of the support that the development community provides to the user community.
Flags can have three values:
(?) - A user is requesting that a status be set. (Think of it as 'A question is being asked')
(-)The status has been set negatively. (The question has been answered "no")
(+) - The status has been set positively. (The question has been answered "yes")
(<blank space>) - When the flag is unset, this just means that nobody has expressed an opinion (or asked someone else to express an opinion) about this bug or attachment.