And on the seventh day James Graham spoke: >> 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.
That is for the people who grant the privileges to decide, but yes I also think that it should be an obligatory read for everyone seeking a permission upgrade. >> 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. We're working on that. >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. Done. >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. Done. >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. Done. >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? Yes. >(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. Because a lot of people get this wrong. >Is it true that only "severe" security exploits are critical? I was told that this is the case. >It might be nice to link some other document such as >http://www.mozilla.org/projects/security/security-bugs-policy.html at >this point. I don't see how this relates to my document. >Under reassigning bugs, you might want to link the component >descriptions http://bugzilla.mozilla.org/describecomponents.cgi Done. >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. Done. >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 Done. But I haven't linked every small sub-chapter from the top, because I want people to see more of the doc on first sight than just the table of contents. >Hmm. I hope these comments aren't useless. Yes, thanks a lot. Simon -- Rusty: You scared? Linus: You suicidal? Rusty: Only in the morning. (Ocean's Eleven) _______________________________________________ mozilla-documentation mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-documentation
