And on the seventh day Clover spoke: >> The canconfirm privilege is the first privilege given to you in >> the bugzilla.mozilla.org. > >I got editbug and canconfirm at the same time
Text changed to |The canconfirm privilege is the first privilege you can obtain in |bugzilla.mozilla.org. >> It allows you to confirm bugs. It also allows your bug reports to >> start in the confirmed state (NEW). > >and also to report bugs without going through Bugzilla helper. If a person heeds the advice given in the document (to read the confirming unconfirmed bugs guide), I think it is unnecessary to mention this. >> At least 5-10 bugs which were reported and/or confirmed by you. > >I don't understand this requirement. Why would you need editbug if all >you do is reporting and confirming bugs? Read the full text in this paragraph. With the no additional permissions or canconfirm all a bug triager can do is report bugs, comment in bugs, or confirm bugs (if he has canconfirm). If he gets editbugs he can do more and will do more. >> Resolving bugs as DUPLICATE... > >I think when we give out editbug we already has enough confidence that >you know how to resolve bugs as dupes ;-) And that is why I'm just linking to another text and then tell the reader some additional things, which he is probably unaware of. >> * the build the bug is reported against is more than one stable release >> old and the bug can't be reproduced with a current build. > >This rule is not strict enough and should be removed I think the rule is fine. In fact this rule was suggested by one of the finest triagers we have in the community, Boris Zbarsky. But of course I'm open for improvement suggestions. >> You should resolve a bug as INVALID, if the issue described in the >> bug is clearly not a mozilla bug > >spelling, "Mozilla" ;-) Yep. Thanks. >Also qualify this. If the issue is not a Mozilla bug but is a web site >compatibility/accessibility bug, then it should be moved to Tech >Evangelism. Yes, thanks for the suggestion. >> The only exception are bugs in other software which we have to work >> around. > >can you explain this? Sometimes we have to workaround bad HTML code in Layout (quirks mode) or buggy behaviour of webservers. Bug 220807 is a recent example. >> Bugs covering this should not be INVALIDated by anyone other >> than the module owner or module peer. > >what is "this"? http://www.mozilla.org/owners.html But you're right. I should put in a link. >> Always remember to check the "Reassign to default owner and QA Contact" >> radio-button under the comment textbox. > >Not "always" though ??? >> Mass changes (changes to more than one bug simultaneously) are >> discouraged. Don't do it! > >hmm..., I'd say mass change that involves adding a new comments should >be discouraged. So you can add yourself to CC list of many bugs, as long >as you don't add unneccessary comment. Or you can mass verify (now >requires no commenting, yeah!), etc. Please remember the target audience: unexperienced bug triagers who just got their permission(s). I'm aware of the fact that some things in this text do not apply to experienced QA people. But these people have experience in bmo and normally they know pretty well what they should and shouldn't do. So these people do not need this document. Simon -- Default QA Contact Firebird - Menus/Toolbars/Installer My Mozilla Blog: http://sipaq.blogspot.com _______________________________________________ mozilla-documentation mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-documentation
