As a security precaution, we have turned on the setting "Require API key authentication for API requests" for everyone. If this has broken something, please contact email@example.com
There's a number of faux pas you can commit when using
Bugzilla. At the very
least, these will make Mozilla contributors upset at you; if committed enough
times they will cause those contributors to demand the disabling of your
Bugzilla account. So, ignore this advice at your peril.
Please also read the Mozilla Community Participation Guidelines
That said, Mozilla developers are generally a friendly bunch, and will be
friendly towards you as long as you follow these guidelines.
This is the most important section.
No pointless comments.
Unless you have something constructive and helpful to say, do not add a
comment to a bug. In bugs where there is a heated debate going on, you
should be even more
inclined not to add a comment. Unless you have something new to contribute,
then the bug owner is aware of all the issues, and will make a judgement
as to what to do. If you agree the bug should be fixed, vote for it.
Additional "I see this too" or "It works for me" comments are unnecessary
unless they are on a different platform or a significantly different build.
Constructive and helpful thoughts unrelated to the topic of the bug
should go in the appropriate
"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 and interest in your suggestions.
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 attack
things, not people. Examples of things include: interfaces,
algorithms, and schedules. Examples of people include: developers,
designers and users. Attacking a person may result in you being banned
No private email.
Unless the bug owner or another respected project contributor has asked you
to email them with specific information, please place all information
relating to bugs
in the bug itself. Do not send them by private email; no-one else can read
them if you do that, and they'll probably just get ignored. If a file
is too big for Bugzilla, add a comment giving the file size and contents
and ask what to do.
2. 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 a respected project contributor has marked a bug as INVALID, then it is
invalid. Someone filing another duplicate of it does not change this. Unless
you have further important evidence, do not post a comment arguing that an
INVALID or WONTFIX bug should be reopened.
Some of these rules may not apply to you. If they do not, you will know
exactly which ones do not, and why they do not apply. If you are not
sure, then they definitely all apply to you.
If you see someone not following these rules, the first step is, as an exception
to guideline 1.4, to make them aware of this document by private mail.
Flaming people publically in bugs violates guidelines 1.1 and 1.3. In the case of
persistent offending you should ping an administrator on Mozilla IRC in channel #bmo and ask them
to look into it.
This entire document can be summed up in one sentence:
do unto others as you would have them do unto you.
Other useful documents:
The Bug Writing Guidelines.