*What to do and what not to do in Bugzilla*
document title and heading don't match. I like the title better. Can you change it to "Rights and duties when triaging bugs"?
If you want to get bugzilla privileges
change all "bugzilla" to "Bugzilla"
If you want to get bugzilla privileges (as described below) mail Gerv
Gerv, you wrote "If you want "canconfirm", email me the URLs of three good bug reports you've filed." "email" is a noun, not a verb. Try "mail me..." or "send me the URLs... by e-mail "
that you've gone gone through
one "gone" only
You should report a bug in the NEW state under the condition that you've gone gone through the triaging process as listed in the two mentioned guides yourself.
You should only report a bug in the NEW state after going through the triaging process as described in the two above-mentioned guides.
You should look at all the bugs you've reported ... at least every two months and test whether they still exist.
"all the open bug reports" I prefer "periodically" over "at least every two months"
The more powerful editbugs privilege gives you the privileges of canconfirm
gerv, is this true? I thought editbugs and canconfirm are separate.
Therefore, don't abuse your privileges
"Don't abuse this privilege." or "Don't abuse your privileges."
Whenever you resolve a bug, CC yourself on the bug so that you are informed when new facts come up.
"When you..." and "CC yourself so that..."
If you're uncertain about resolving a bug, leave it alone!
When in doubt, leave it alone.
See this guide for screening DUPLICATE bugs.
See the <a>screening duplicate bugs</a> guide.
the bug reporter has not responded to questions for four weeks and the bug can't be reproduced with a current build.
nit. "one month" is easier arithmatic-wise than "four weeks"
The exception are bugs in other software which we have to work around.
Not neccessary "bugs". And I think the form of "be" word goes with the subject: "The exception is issues in..."
Bugs covering these exceptions should not be INVALIDated by anyone other than the module owner or module peer.
I count one "exception". This is a bit ambiguous: if you are not the module owner or peer, can you invalid'ate a bug?
Reports of problems with websites that result from bad coding or use of proprietary technology should also not be INVALIDated, but instead moved to the Tech Evangelism product.
my trusted 1997 Oxford dictionary has no entry for "website". Anyone w/ updated dictionary can find it?
Tech Evangelism should link to TE project page
Bug reports about crashes, hangs, dataloss, or severe security exploits (e.g. remote execution of arbitrary code) get the critical severity.
<tt></tt> around "crash", "hang", etc? Also, they should link to the keywords page:
Bug reports with crash, hang, or dataloss <a>keyword</a> or involving severe security exploits (e.g. remote execution of arbitrary code) get the critical severity.
If a bug belongs to a different Product or Component it should be reassigned. See this description of the products in bugzilla.
If a bug belongs to a different Product or Component it should be reassigned (see the <a>component description</a> of the products).
Make sure that you also test Thunderbird or Firebird bugs with the Application Suite and move the bug to one of the core products
"core components"
Thunderbird and Firebird should both link to projects/<product>/ page.
If you don't know where a bug belongs, don't touch it! ... and don't leave bugs in the JS engine Component if you know that the malfunction being described is a DOM problem.
didn't you say "don't touch it"?
<p><small>Written by Simon Paquet<br>
<p class="byline">.... _______________________________________________ mozilla-documentation mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-documentation
