Re: New document on what a person should and should not do in bugzilla.mozilla.org
fantasai wrote: Clover wrote: 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 email isn't a word at all. :) e-mail is both a noun and a verb. http://www.m-w.com/cgi-bin/dictionary?book=Dictionaryva=e-mail my trusted 1997 Oxford dictionary has no entry for website. Anyone w/ updated dictionary can find it? So far as I'm concerned, email is both a noun and a verb. And Daniel, you are /not/ going to find a 1997 Oxford dictionary to be an up-to-date reflection of current Internet-related vocabulary usage. now m-w entry for website, although it has Web and World Wide Web. -- -- Andrew Schultz| The views expressed might [EMAIL PROTECTED] | not represent those of NCSU. http://www4.ncsu.edu/~ajschult/ | They are however, correct. ___ mozilla-documentation mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-documentation
Re: New document on what a person should and should not do in bugzilla.mozilla.org
This is turning into an editing exercise :-p *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 ascreening 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 akeyword/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 acomponent 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? psmallWritten by Simon Paquetbr p class=byline ___ mozilla-documentation mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-documentation
Re: New document on what a person should and should not do in bugzilla.mozilla.org
And on the seventh day Clover spoke: *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? I like the other one better, so I changed the title to What to do and what not to do in Bugzilla. :-) If you want to get bugzilla privileges change all bugzilla to Bugzilla Yes. 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. Yes. 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 Yes. I prefer periodically over at least every two months Periodically can also be every five years. Therefore, don't abuse your privileges Don't abuse this privilege. or Don't abuse your privileges. I like the therefore here. It connects this sentence with the one before. |The more powerful editbugs privilege gives you the privileges of |canconfirm and also the ability to edit most aspects of a bug. |Don't abuse your privileges. doesn't sound very well. The two sentences seem to be very alien to one another. 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... Yes. If you're uncertain about resolving a bug, leave it alone! When in doubt, leave it alone. I changed it to When in doubt about resolving a bug, leave it alone! 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 Yes. The exception are bugs in other software which we have to work around. Not neccessary bugs. I already explained this in [EMAIL PROTECTED] And I think the form of be word goes with the subject: The exception is issues in... Really? Bugs covering these exceptions should not be INVALIDated by anyone other than the module owner or module peer. I count one exception. Right. This is a bit ambiguous: if you are not the module owner or peer, can you invalid'ate a bug? You can invalidate a bug as long as the bug does not cover the exception. Tech Evangelism should link to TE project page Done. 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 akeyword/a or involving severe security exploits (e.g. remote execution of arbitrary code) get the critical severity. No. All bugs covering crashes, hangs, or dataloss get the critical severity, not only those that have the keyword. 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 acomponent description/a of the products). The link does describe the different products. If you click on the link to one of the products the product components are described. So I think the current wording is correct. 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 This was written in light of the coming bugzilla reorganization. Thunderbird and Firebird should both link to projects/product/ page. Yes. 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? I say don't touch it, if you don't know what you're doing. The last sentence says please touch it, if you what you're doing. 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
Re: New document on what a person should and should not do in bugzilla.mozilla.org
Clover wrote: 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 ... my trusted 1997 Oxford dictionary has no entry for website. Anyone w/ updated dictionary can find it? So far as I'm concerned, email is both a noun and a verb. And Daniel, you are /not/ going to find a 1997 Oxford dictionary to be an up-to-date reflection of current Internet-related vocabulary usage. ~fantasai ___ mozilla-documentation mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-documentation
Re: New document on what a person should and should not do in bugzilla.mozilla.org
Simon Paquet wrote: So, any suggestions for the document here? You are a new bug triager who has just obtained new permissions in bugzilla.mozilla.org. Don't make such explicit, specific assumptions about the reader. He is just as likely to be a person without any permissions, maybe one who just wants to get a better idea of what they are. Here you find information explaining I suggest using This document explains instead. You should avoid here in general. You use it too much. It allows you to confirm bugs. It also allows your bug reports to start in the confirmed state (NEW). Combine these last two sentences. Also, you want to start the paragraph with the main definition (what canconfirm is), not a side note (that it's the first privilege). e.g. The canconfirm privilege allows you to confirm bugs and also to start your bug reports in the confirmed state (NEW). _Here_ NEVER link with the text here. Please apply as many steps listed in the guide for confirming unconfirmed bugs or the confirming layout bugs guide as possible before reporting a bug with status NEW, because fewer bug triagers will look at confirmed bugs, and a second view can be useful. This could be made easier to understand if you just stipulate that starting bugs as NEW means you've gone through the triage process already yourself. Upgrading your permissions This section belongs under Editbugs. After you have reported and/or confirmed a few bugs you are probably eager to do more. This sentence is more or less useless. It could, however be tweaked to give a brief idea of when someone should be applying for editbugs. The more powerful Editbugs privilege level gives you You vary between privilege and privilege level. Pick one concept and stick with it. the privileges of Canconfirm and also the ability to edit most aspects of a bug. Therefore, this privilege should be used with special care. The last sentence has the literary power of That's nice. How about something like a don't abuse your privileges? To resolve bugs is an important task for a bug triager. Fluff. Take out. Whenever you resolve a bug CC yourself comma after bug See this _guide_ for screening DUPLICATE bugs. Extend the link to the end of bugs. You want the link text to stand out on its own. I should be able to scan the document, pick out the links (they stand out), and know where each one will go. (for example bug description and/or summary are clearer, a patch is already attached, a lot of people are already CC'ed, etc.) You can take out the for example and the linking verbs (is, are). Also, I don't think a clearer summary is a good reason to give something better emphasis. A better description is important, but the summary is easy to change. So, you can recommend changing the summary to the better one. Also bugs on websites, which are the result of bad coding or use of proprietary technology, bugs *in* websites *that result from* bad coding or use of proprietary technology [no comma] The decision to mark a bug WONTFIX is reserved for developers. Do you want to restrict that to the module owner/peer group? Verifying DUPLICATEs is the easiest task, so you should start with it. start with that. is relatively easy, if a developer no comma Before verifying FIXED bugs, you should make sure that the bug triager can verify them on every hardware/OS they were reported on. I'm confused. Isn't you the bug triager? For verifying WORKSFORME bugs there are no clear steps. There are no clear steps for verifying WORKSFORME. At the top of every bug report ... This paragraph serves no great purpose. You can take it out. This policy does also apply for all bugs with Target Milestones in the past. (Bugs with Target Milestones in the past are /not/ excepted.) network connectivity (ftp, http, IMAP) or HTML rendering or - and if a bug also exists in the Application Suite a bug - the bug In general, if you can take a sentence or phrase out (i.e. it's not offering the reader any useful information), take it out. If the result reads awkwardly, then you're doing something else wrong and need to adjust either the wording or the sentence organization. Try imagining yourself just starting out. What would you need to know and what's just fluff? Coding -- a) Put the heading text in the anchors. b) Don't use emphasis (strong) for codes. code is more appropriate. c) Don't use capital letters for emphasis. Use strong class=stronger, if you need to. d) Consider using div class=section to structurally organize the document. e) Read the mozilla.org Documentation Style Guide. This is all in there. :) ~fantasai ___ mozilla-documentation mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-documentation
Re: New document on what a person should and should not do in bugzilla.mozilla.org
On 2004-01-17, fantasai [EMAIL PROTECTED] wrote: Simon Paquet wrote: So, any suggestions for the document here? [snip] (for example bug description and/or summary are clearer, a patch is already attached, a lot of people are already CC'ed, etc.) You can take out the for example and the linking verbs (is, are). Heh... those weren't there in an earlier draft - they were inserted at my suggestion :) You can't just put a list into the middle of a sentence, even if it is in brackets, IMHO. But that's not important... Also bugs on websites, which are the result of bad coding or use of proprietary technology, bugs *in* websites *that result from* bad coding or use of proprietary technology [no comma] What we're talking about here is websites not displaying as intended in Mozilla. That, as your change makes clearer, is a result, not a cause. Better would be: 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. Verifying DUPLICATEs is the easiest task, so you should start with it. start with that. Simon seems to have misinterpreted this one (or maybe I have and I don't agree with you). This should read: Verifying DUPLICATEs is the easiest task, so start with that. Also, in the next bullet, about verifying invalid, it has INVALID'ated instead of INVALIDated as elsewhere. Try imagining yourself just starting out. What would you need to know and what's just fluff? Coding -- b) Don't use emphasis (strong) for codes. code is more appropriate. Not all of these have been changed (e.g. talking about blocker and critical severity). In any case, I think it makes the document hard to read. Is it necessary to use code tags each time the document mentions product or component? I'd be inclined to use code just for the values, and leave the field names as normal text. c) Don't use capital letters for emphasis. Use strong class=stronger, if you need to. I think there's a bit too much emphasis generally in this doc. If you're emphasising words in several sentences next to each other, it might be best to work out which is the most important to emphasise, and drop the other emphasis. One other thing I just spotted is (ftp, http, IMAP) - should either be all lowercase, or all uppercase (probably all upper). Nice to see all these people helping out with this doc. Would be nice if the maintainers of some other docs would facilitate doing this kind of stuff... -- Michael ___ mozilla-documentation mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-documentation
Re: New document on what a person should and should not do in bugzilla.mozilla.org
On 2004-01-17, Michael Lefevre [EMAIL PROTECTED] wrote: One other thing I just spotted is (ftp, http, IMAP) - should either be all lowercase, or all uppercase (probably all upper). Gah... one more after I posted: The conditions for getting a permission upgrade are also listed on Gerv's. page. should not have that full stop after Gerv's. Thanks Simon :) -- Michael ___ mozilla-documentation mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-documentation
Re: New document on what a person should and should not do in bugzilla.mozilla.org
And on the seventh day Michael Lefevre spoke: One other thing I just spotted is (ftp, http, IMAP) - should either be all lowercase, or all uppercase (probably all upper). Gah... one more after I posted: The conditions for getting a permission upgrade are also listed on Gerv's. page. should not have that full stop after Gerv's. Thanks Simon :) All issues fixed. 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
Re: New document on what a person should and should not do in bugzilla.mozilla.org
Michael Lefevre wrote: On 2004-01-17, fantasai [EMAIL PROTECTED] wrote: Simon Paquet wrote: So, any suggestions for the document here? [snip] (for example bug description and/or summary are clearer, a patch is already attached, a lot of people are already CC'ed, etc.) You can take out the for example and the linking verbs (is, are). Heh... those weren't there in an earlier draft - they were inserted at my suggestion :) You can't just put a list into the middle of a sentence, even if it is in brackets, IMHO. But that's not important... Maybe that's why I picked them out as not fitting. :) That remark is not fitted into the paragraph. It still feels like a list. b) Don't use emphasis (strong) for codes. code is more appropriate. Not all of these have been changed (e.g. talking about blocker and critical severity). In any case, I think it makes the document hard to read. Is it necessary to use code tags each time the document mentions product or component? I'd be inclined to use code just for the values, and leave the field names as normal text. I think the component field names should be distinguished from regular text. But I'd use var instead of code. c) Don't use capital letters for emphasis. Use strong class=stronger, if you need to. I think there's a bit too much emphasis generally in this doc. If you're emphasising words in several sentences next to each other, it might be best to work out which is the most important to emphasise, and drop the other emphasis. Yeah, I agree. :) ~fantasai ___ mozilla-documentation mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-documentation
Re: New document on what a person should and should not do in bugzilla.mozilla.org
And on the seventh day fantasai spoke: c) Don't use capital letters for emphasis. Use strong class=stronger, if you need to. I think there's a bit too much emphasis generally in this doc. If you're emphasising words in several sentences next to each other, it might be best to work out which is the most important to emphasise, and drop the other emphasis. Yeah, I agree. :) As a general I've now tried to only emphasize those cases, where someone should not do something instead of emphasizing should as well as should not cases. As of now only 11 strongs still exist in the document. And I think that this is quite right. 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
Re: New document on what a person should and should not do in bugzilla.mozilla.org
And on the seventh day fantasai spoke: I remain of the view that it could be 50% shorter, though. I agree that it's not fair for me to keep insisting this without giving examples, but I don't have time - so, as a substitute for that, have you read Fantasai's excellent document: http://fantasai.inkedblade.net/weblog/ ? I'm glad you think so highly of it, Gerv, but the URL should be http://fantasai.inkedblade.net/weblog/2003/marketing/ So, any suggestions for the document here? 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
Re: New document on what a person should and should not do in bugzilla.mozilla.org
Gervase Markham wrote: I remain of the view that it could be 50% shorter, though. I agree that it's not fair for me to keep insisting this without giving examples, but I don't have time - so, as a substitute for that, have you read Fantasai's excellent document: http://fantasai.inkedblade.net/weblog/ ? I'm glad you think so highly of it, Gerv, but the URL should be http://fantasai.inkedblade.net/weblog/2003/marketing/ And I need to add another entry and adjust the stylesheet so other people don't do the same thing. ;) ~fantasai ___ mozilla-documentation mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-documentation
Re: New document on what a person should and should not do in bugzilla.mozilla.org
James Graham wrote: Incidentially, is a name=foo still prefered over a id=foo? Yes. See the documentation style guide: http://mozilla.org/README-style.html#linking ~fantasai ___ mozilla-documentation mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-documentation
Re: New document on what a person should and should not do in bugzilla.mozilla.org
Simon Paquet wrote: I remain of the view that it could be 50% shorter, though. I agree that it's not fair for me to keep insisting this without giving examples, but I don't have time - so, as a substitute for that, have you read Fantasai's excellent document: http://fantasai.inkedblade.net/weblog/ Yes, I have read it. But I don't know how that relates to this document? It should hopefully give you lots of ideas as to how to make it shorter while saying the same thing in a clearer way :-) One idea might be to ask fantasai (by email) to take a look at your current draft. Gerv ___ mozilla-documentation mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-documentation
Re: New document on what a person should and should not do in bugzilla.mozilla.org
Gervase Markham wrote: That's news to me. Is there a case for revisiting that decision after the recent changes (Netscape/MF)? Perhaps. If you can bring this up at the next staff meeting, that would be great. Though the current system has one advantage -- it makes it clear that the milestone is being used for developer convenience, not as a real target. ;) -Boris ___ mozilla-documentation mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-documentation
Re: New document on what a person should and should not do in bugzilla.mozilla.org
Simon Paquet wrote: Who is upgrading permissions regularly apart from me? Asa and I upgraded quite a few permissions on the last bugday and this will probably continue with the next bugday. Fair enough. The instructions for upgrading privileges should match those outlined on http://www.gerv.net/hacking/before-you-mail-gerv.html . If they are consensus, fine. Consensus? They are the _law_, dude :-) Your smiley implies that this isn't really the case. No it doesn't. That would be this smiley: ;-). So should I now change my doc or shouldn't I? Those conditions are the standard ones - they aren't just on my web page, they are on various mozilla.org pages as well. Others may have different conditions for different circumstances (like a Bug Day), which is fine, but those should be the ones in the doc IMO. I remain of the view that it could be 50% shorter, though. I agree that it's not fair for me to keep insisting this without giving examples, but I don't have time - so, as a substitute for that, have you read Fantasai's excellent document: http://fantasai.inkedblade.net/weblog/ ? Gerv ___ mozilla-documentation mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-documentation
Re: New document on what a person should and should not do in bugzilla.mozilla.org
Michael Lefevre wrote: At the moment people have to tell future triagers the same stuff everytime they upgrade permissions. Who is upgrading permissions regularly apart from me? Asa, for one. If there are going to be regular bugdays, I assume he will continue to do that regularly. And then there are other people who do it irregularly. Fair enough. Out of interest, what instructions do you give people when you upgrade their permissions? I normally say Use this power wisely, my son. :-) The instructions for upgrading privileges should match those outlined on http://www.gerv.net/hacking/before-you-mail-gerv.html . If they are consensus, fine. Consensus? They are the _law_, dude :-) If this doc says that the procedure is to email you, then you can certainly define the procedure, and this doc should reflect that :) But going back to the point above, you're not the only person with editusers privileges. Even if everything does go through one person, it's still better to have stuff documented, so that procedures are transparent, and can be picked up easily if that one person goes away (of course I hope you won't be going anywhere, but one never knows) What I meant by that (perhaps slightly flippant) comment is that over time, that standard has emerged as a reasonably good one to use, and the large majority of those who get canconfirm or editbugs get it by meeting it. Gerv ___ mozilla-documentation mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-documentation
Re: New document on what a person should and should not do in bugzilla.mozilla.org
Boris Zbarsky wrote: YES. If nothing else, bugzilla only allows targeting one major version ahead, so past target milestones have to be used if one wants to reasonably prioritize work. This is not a Bugzilla limitation. If you want more future target milestones, just ask :-) Also, priority is generally used for prioritising work (hence the name) rather than TM. Gerv ___ mozilla-documentation mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-documentation
Re: New document on what a person should and should not do in bugzilla.mozilla.org
Boris Zbarsky wrote: Christian Biesinger wrote: of course one could use the Priority field for prioritizing work ;) It's not fine-grained enough... ;) Seriously? Gerv ___ mozilla-documentation mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-documentation
Re: New document on what a person should and should not do in bugzilla.mozilla.org
Gervase Markham wrote: This is not a Bugzilla limitation. I never said it was. If you want more future target milestones, just ask :-) They got cut back on purpose, out of a belief that people were mis-targeting too far in the future and really have no business planning more than 3 months in advance. Which is true, but relies on target milestones actually corresponding to the releases; if you just let people use them to sort of order things, it makes sense to have a lot of milestones available in either the past or the future. Also, priority is generally used for prioritising work (hence the name) rather than TM. It's not fine-grained enough... ;) Seriously? Yes. Consider someone who has 100 bugs assigned to him (for whatever reason; say default assignee for a component or just too dumb and weak-willed, like me, to not take bugs and to reassign them to default owners aggressively). Priority gives you a way to put them in 5 bins, in order of how important you think it is for you to work on this bug (at least that's how I tend to use it). Pretty coarse. Frankly, pretty useless. Priority + TM lets you set 1) How important you think it to work on the bug and 2) The approximate order you want to work on bugs in. There are plenty of reasons why a P1 bug may end up with a TM of not right now or even future -- depends on other bugs that need resolving first, requires large changes that can't land for another two months (alpha cycle is done), etc. So you set TM to put an ordering on your bugs and you use priority to influence this ordering and to decide which of the ordered bugs to work on first -Boris ___ mozilla-documentation mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-documentation
Re: New document on what a person should and should not do in bugzilla.mozilla.org
And on the seventh day Gervase Markham spoke: So should I now change my doc or shouldn't I? Those conditions are the standard ones - they aren't just on my web page, they are on various mozilla.org pages as well. Others may have different conditions for different circumstances (like a Bug Day), which is fine, but those should be the ones in the doc IMO. Ok. Document changed. I remain of the view that it could be 50% shorter, though. I agree that it's not fair for me to keep insisting this without giving examples, but I don't have time - so, as a substitute for that, have you read Fantasai's excellent document: http://fantasai.inkedblade.net/weblog/ Yes, I have read it. But I don't know how that relates to this document? 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
Re: New document on what a person should and should not do in bugzilla.mozilla.org
And on the seventh day Gervase Markham spoke: The instructions for upgrading privileges should match those outlined on http://www.gerv.net/hacking/before-you-mail-gerv.html . Ok, I changed the numbers from 10 to 5-10 to indicate that the numbers may vary if you ask different people for a permission upgrade. You should make a concerted effort to make the document say as little as possible. Yesterday I went through the document and tried to shorten it a little bit without taking out any of the guidelines. It's not much but it is definitely shorter than before ;-) 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 Are you sure there are not already documents on www.mozilla.org covering this topic? Somewhere around, for example, http://www.mozilla.org/quality/help/ ? I found http://www.mozilla.org/quality/bug-verification-guidelines.html But this document is so outdated and incomplete in comparison to this document that it should be removed (IMO) and replaced with this document. It is only linked to from http://www.mozilla.org/docs/start.html (link can be changed) and www.mozilla.org/quality/duplicate-resolved-bugs.html which is even more outdated. The doc tells you to verify duplicates from 1999. Since no other document on www.mozilla.org links to www.mozilla.org/quality/duplicate-resolved-bugs.html I think that this page should also be removed. IMO www.mozilla.org/quality badly needs some cleanup, but I will post about this later. 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
Re: New document on what a person should and should not do in bugzilla.mozilla.org
The canconfirm privilege is the first privilege given to you in the bugzilla.mozilla.org. I got editbug and canconfirm at the same time 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. 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? 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 ;-) * 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 You should resolve a bug as INVALID, if the issue described in the bug is clearly not a mozilla bug spelling, Mozilla ;-) 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. If the issue cannot be fixed by Mozilla developers/contributors, it should be INVALID. Usually this cover bugs with very general description, e.g. page rendering is slow or the UI sucks and no dependencies (it's not a meta bug). The only exception are bugs in other software which we have to work around. can you explain this? Bugs covering this should not be INVALIDated by anyone other than the module owner or module peer. what is this? 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. ___ mozilla-documentation mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-documentation
Re: New document on what a person should and should not do in bugzilla.mozilla.org
Clover wrote: 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 ;-) Surely the point is that you *can't* resolve bugs as dupes without editbugs? Always remember to check the Reassign to default owner and QA Contact radio-button under the comment textbox. Not always though Always is a pretty good approximation. If you don't need to do this, you probably know the rule doesn't apply. On the other hand, it's not very obvious that you do need to do this without being told. ___ mozilla-documentation mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-documentation
Re: New document on what a person should and should not do in bugzilla.mozilla.org
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
Re: New document on what a person should and should not do in bugzilla.mozilla.org
And on the seventh day Clover spoke: Bugs covering this should not be INVALIDated by anyone other than the module owner or module peer. what is this? ups, sorry I totally misinterpreted this question. Sentence has been clarified. 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
Re: New document on what a person should and should not do in bugzilla.mozilla.org
Clover wrote: 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. Case in point. If you're mass-verifying, you're doing something wrong, in 99% of the cases, imo. -Boris ___ mozilla-documentation mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-documentation
Re: New document on what a person should and should not do in bugzilla.mozilla.org
Simon Paquet wrote: The problem, that there is no documentation about what people should or should not do when having privileges. What about the Bugzilla Etiquette document? At the moment people have to tell future triagers the same stuff everytime they upgrade permissions. Who is upgrading permissions regularly apart from me? Are there are large number of cases of people misusing their privileges? What are the most common mistakes people make? - People abuse the flags, when they shouldn't because there is no clear statement anywhere saying, Don't do this! - People do mass comments/changes because they see other people doing this and think it's ok. I for myself got into this mess, because I sent out a mass comment and nearly got my privileges revoked for that. - People resolve bugs as WFM, INVALID, or WONTFIX when they shouldn't What do you mean by when they shouldn't? The instructions for upgrading privileges should match those outlined on http://www.gerv.net/hacking/before-you-mail-gerv.html . If they are consensus, fine. Consensus? They are the _law_, dude :-) But in the past I got the impression that other people with editusers, like timeless for example, want to see a little bit than what you say on your page. I also noticed that some developers think, that too many people have editbugs (I do not necessarily agree). If so, such developers should be contacting me with the names of people they think are not using their privileges correctly. Gerv ___ mozilla-documentation mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-documentation
Re: New document on what a person should and should not do in bugzilla.mozilla.org
On 2004-01-07, Gervase Markham [EMAIL PROTECTED] wrote: Simon Paquet wrote: The problem, that there is no documentation about what people should or should not do when having privileges. What about the Bugzilla Etiquette document? That covers comments you shouldn't make, and also has one line about changing fields (which does indeed overlap). It doesn't say what you should do though. At the moment people have to tell future triagers the same stuff everytime they upgrade permissions. Who is upgrading permissions regularly apart from me? Asa, for one. If there are going to be regular bugdays, I assume he will continue to do that regularly. And then there are other people who do it irregularly. Out of interest, what instructions do you give people when you upgrade their permissions? Are there are large number of cases of people misusing their privileges? What are the most common mistakes people make? [snip] - People resolve bugs as WFM, INVALID, or WONTFIX when they shouldn't What do you mean by when they shouldn't? Well that's in the document. :) Pretty much nobody should be resolving things as WONTFIX unless they're a module owner or peer. And people shouldn't be resolving things as WFM, just because it does work for them. In fact it's probably mis-named, we need a WORKSFOREVERYONEELSEBUTTHEREPORTERWHOHASGONEAWAY resolution. The instructions for upgrading privileges should match those outlined on http://www.gerv.net/hacking/before-you-mail-gerv.html . If they are consensus, fine. Consensus? They are the _law_, dude :-) If this doc says that the procedure is to email you, then you can certainly define the procedure, and this doc should reflect that :) But going back to the point above, you're not the only person with editusers privileges. Even if everything does go through one person, it's still better to have stuff documented, so that procedures are transparent, and can be picked up easily if that one person goes away (of course I hope you won't be going anywhere, but one never knows) If so, such developers should be contacting me with the names of people they think are not using their privileges correctly. They probably should, but it's a lot less effort for them to just correct the mistake and tell the person not to do it again, which is I imagine what you would do anyway in most cases, isn't it? -- Michael ___ mozilla-documentation mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-documentation
Re: New document on what a person should and should not do in bugzilla.mozilla.org
Simon Paquet wrote: 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
Re: New document on what a person should and should not do in bugzilla.mozilla.org
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
Re: New document on what a person should and should not do in bugzilla.mozilla.org
Simon Paquet wrote: 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. In that case, I would state this explicitly, because a *lot* of people get this wrong. 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. That's exactly what I had in mind. Although I don't see the new ids in the document. Simon ___ mozilla-documentation mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-documentation
Re: New document on what a person should and should not do in bugzilla.mozilla.org
And on the seventh day James Graham spoke: 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. In that case, I would state this explicitly, because a *lot* of people get this wrong. 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. That's exactly what I had in mind. I played a little with the markup and found a way to squeeze this information into the TOC and still display the first paragraph on a 1024x768 resolution. Take a look. 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
Re: New document on what a person should and should not do in bugzilla.mozilla.org
Christian Biesinger wrote: of course one could use the Priority field for prioritizing work ;) It's not fine-grained enough... ;) -Boris ___ mozilla-documentation mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-documentation
Re: New document on what a person should and should not do in bugzilla.mozilla.org
Simon Paquet wrote: I've written a document for new bug triagers who just obtained their canconfirm or editbug privileges in bugzilla.mozilla.org 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 What problem is this document trying to solve? Are there are large number of cases of people misusing their privileges? What are the most common mistakes people make? The instructions for upgrading privileges should match those outlined on http://www.gerv.net/hacking/before-you-mail-gerv.html . You should make a concerted effort to make the document say as little as possible. The longer it is, the less people are likely to read it. If someone gets something wrong, It's in the Privilege Guide, Page 3, Paragraph 7 is not a particularly helpful response. 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 Are you sure there are not already documents on www.mozilla.org covering this topic? Somewhere around, for example, http://www.mozilla.org/quality/help/ ? Gerv ___ mozilla-documentation mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-documentation
Re: New document on what a person should and should not do in bugzilla.mozilla.org
On 2004-01-06, Gervase Markham [EMAIL PROTECTED] wrote: Simon Paquet wrote: I've written a document for new bug triagers who just obtained their canconfirm or editbug privileges in bugzilla.mozilla.org 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 What problem is this document trying to solve? [snip] Are you sure there are not already documents on www.mozilla.org covering this topic? Somewhere around, for example, http://www.mozilla.org/quality/help/ ? The problem I guess it's trying to solve is the fact you have to point to documents somewhere around You're the maintainer of the section - if you're not immediately sure of what is covered there and where it is, then the chances are that nobody else is. Currently most of the information in this document is passed along by talking on IRC, or meta-discussion in bugs. It should be possible to point someone at the /quality/help page, and for them to be able to know how bugzilla is used, and what they should and shouldn't do. The QA page has: http://www.mozilla.org/quality/help/unconfirmed.html - not bad, but only talks about unconfirmed bugs, and it contains links to queries which return 5000 bugs and then suggest you use back/forward to step through. http://www.mozilla.org/quality/browser/prescreening.html - talks about browser-general bugs only, overlaps with other docs, talks about Netscape. http://www.mozilla.org/newlayout/bugathon.html - bunch of stuff about BugAThon, writing testcases. A smoketest nightly builds link, which fires a load of crap at the bugzilla server which returns an error. Link to tests - fine, but not to do with triaging bugs. Then under the howtos, bug writing guidelines - good for writing bugs screening duplicates - fine for screening duplicates how to find duplicates - fine for screening duplicates how to pick components for crash bugs - a draft requesting comments to [EMAIL PROTECTED] (who?) and then how to use regex searches in bugzilla. Where, in the above, does it give any kind of overview of what people are supposed to do in bugzilla? There are howtos for various specific tasks, but nothing general. You're right that the documents should be as short as possible - this document is far shorter than the above selection, and it covers how the various resolutions are used, how bugs are verified, what the various fields are (this is covered in links from the bugzilla page, but in a generic way that isn't consistent with Mozilla's usage). Also the stuff about whether bugs are assigned to Firebird or Mozilla. The QA section is currently a mess of overlapping and badly organised document. This document is more useful than some of the stuff up there already. If we had documentation that was well organised and relatively complete, then how does this fit in with what we have would be a good question. As it is, the existing stuff is a mess that nobody is going to fix any time soon, so, IMHO, you may as well add this to it. Alternatively, this document can live on a different site, and people will get referred to this instead of the official docs, because it's too much to get it onto Mozilla.org (as with the Firebird/Thunderbird documentation, Mozilla and FB/TB themes and extensions - the actual products link directly to non-mozilla.org sites, because those sites are actively maintained to be cohesive, something which people involved feel would not be possible if the content was on mozilla.org). -- Michael ___ mozilla-documentation mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-documentation
