Hi,
I've written a document for new bug triagers who just obtained their canconfirm or editbug privileges in bugzilla.mozilla.org
Actually, it seems to focus on people who wish to obtain these privileges, although obviously it is good both before and after the bugzilla status has been granted. Maybe reading the relevant section of this doc. should be a requirement for getting new permissions.
The document covers most of what a bug triager can or should do and what he should not do. The document can be found at http://www.babylonsounds.com/bugzilla-privilege-guide.html
A few persons have already reviewed it, but I would appreciate it if the wider public would also take a look at it before I check it in on www.mozilla.org
OK, some random comments:
http://www.babylonsounds.com/bugzilla-privilege-guide.html#permissions disagrees with http://www.gerv.net/hacking/before-you-mail-gerv.html on the requirements for getting permissions upgraded. Obviously the two documents should agree. (addendum: Gerv pointed this out already, I read it, and then totally forgot about it when, seconds later, I started my reply. Use that fact as a guide to the usefulness of my remaing comments)
In general, the links to other documents are very useful, although they become less numerous further down the page. As mentioned elsewhere on this thread, a link to Etiquette guide would be good.
Marking bugs WFM - it's obvious, but you should point out that the set of conditions where you can mark a bug WFM are trumped by the conditions under which you cannot mark a bug WFM. This is very clear in the first case (3+ people cannot reproduce with a similar setup), but not in the following cases (e.g. the statement a bug can be marked WFM if one stable release old and the bug cannot be reproduced with a current build doesn't really apply if the bug is BeOS only and you are testing on windows).
If a bug appears to be WFM, it is useful to make sure that the reporter is using an official Mozilla.org build. I remember some crash bugs that turned out only to be a problem with debian builds of Mozilla.
In the invalid section, it's not always clear what intended behavior is. Some sort of "if you're uncertian, do not mark a bug as invalid" would be useful. In fact, "if you're not sure, leave the status of the bug alone" would be useful.
In the section about changing the target milestone, you state that Target Milestone "must not be changed". Does this policy apply to bugs with target milestones in the past? (I suppose it might, since that makes it easy to see which bugs missed the last milestone. On the otherhand, I don't think that anyone pays any attention to target milestone amyway). If it does apply to milestones in the past, lots of people get this wrong.
You've said that you shouldn't change priority and target milestone twice.
Is it true that only "severe" security exploits are critical? It might be nice to link some other document such as http://www.mozilla.org/projects/security/security-bugs-policy.html at this point.
Under reassigning bugs, you might want to link the component descriptions http://bugzilla.mozilla.org/describecomponents.cgi I would be tempted to reorganise the bit about JS engine to start with "In general, don't move bugs unless you know which component they belong to." then use JS engine as the canoncial example of a component not to move bugs into unless you know what you're doing.
Bug flags
Well after seeing the blocking status of http://bugzilla.mozilla.org/show_activity.cgi?id=228672 change blocking status 11 times and account for about 50% of the bug comments, I think we'd be better if bugzilla enforced the "don't set +/- unless you're a driver / module owner" rule. But that's tangential to this document.
Incidentially, is <a name="foo"> still prefered over <a id="foo">? Additionally, it would be good if every paragraph / list/ etc. had a id so that people could be easilly directed to part of the document (in fact some :target style would be good here too, but that's probably a matter for the style guide.
Hmm. I hope these comments aren't useless.
Ciao Simon 'sipaq' Paquet
_______________________________________________ mozilla-documentation mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-documentation
