Quick Search

Bugzilla Etiquette

It is our intention that Bugzilla remain a useful tool for reporting
and commenting on bugs, feature requests, and tasks for the Mozilla community.
No single contributor's work outweighs the importance of civility and professionalism
in the Mozilla community.

In order to keep Bugzilla a useful, inclusive place we have
guidelines which, by using this site, you agree to follow.
In addition, your participation on this site is also subject to the
Mozilla Community Participation Guidelines.

Violations of Bugzilla Etiquette or the Mozilla Community Participation
Guidelines are grounds for curtailing your privileges on this site, or suspending
your account altogether.

Guidelines

Commenting

No abusing people.
Constant and intense critique is one of the reasons we build great products.
It's harder to fall into group-think if there is always a healthy amount of
dissent. We want to encourage vibrant debate inside of the Mozilla
community, we want you to disagree with us, and we want you to effectively
argue your case. However, we require that in the process, you criticize
things, not people. Examples of things include: interfaces,
algorithms, and schedules. Examples of people include: developers,
designers, and users. Attacking or encouraging attacks on a person
may result in you being banned from Bugzilla.

No obligation.
"Open Source" is not the same as "the developers must do my bidding."
Everyone here wants to help, but no one else has any obligation to fix
the bugs you want fixed. Therefore, you should not act as if you
expect someone to fix a bug by a particular date or release.
Aggressive or repeated demands will not be received well and will almost
certainly diminish the impact of and interest in your suggestions.

No spam.
Posting comment spam will lead to the suspension of your account.

No pointless comments.
Limit comments on a bug to information which will help with
resolving it. Unless requested, additional "I see this too" or "It works for me"
comments are unnecessary. Constructive conversations unrelated to the topic of
the bug should go in the appropriate
discussion forum.

No private email.
Do not send comments on bugs by private email to users;
no one else can read them if you do that, and they'll be missed and/or ignored.
If an attachment is too big for Bugzilla, add a comment
giving the file size and contents and ask what to do.

Changing Fields

No messing with other people's bugs.
Unless you are the bug assignee, or have some say over the use of their
time, never change the Priority or Target Milestone fields. If in doubt,
do not change the fields of bugs you do not own — add a comment
instead, suggesting the change.

No whining about decisions.
If another project contributor has marked a bug as INVALID, then it is
invalid. Filing another duplicate of it does not change this. Unless you have
further evidence to support reopening a bug, do not post a comment
arguing that a bug resolved as INVALID or WONTFIX should be reopened.

If a comment is abusive or threatening use the tag abuse. An admin will
receive a notification shortly and be able to follow up. Bugs with
comments marked, 'offtopic', 'spam', and 'advocacy' will also be reviewed.

If you think a comment may violate our policies, but your are not sure how to mark it,
tag the comment admin and a moderator will review it.

If a bug's short-description, whiteboard tags, attachments,
or user-created content other than comments that violate the
Mozilla Community Participation Guidelines
or Bugzilla Etiquette, please describe the issue
in a comment and tag that comment admin.

If you cannot tag comments (which requires
editbugs privileges,)
or if you need to contact a Bugzilla community administrator urgently: