Bugzilla Etiquette Guide Now Available
Wednesday March 19th, 2003
Simon Paquet wrote in to tell us about the new Bugzilla etiquette guidelines, written by Gervase Markham. These guidelines explain a number of the most common Bugzilla faux pas and are intended to make Bugzilla a more pleasant environment for all. If you see anyone violating these rules, you should refer them to this document by way of a polite, private email. Persistent offenders should be reported to Gerv, who is well versed in the art of LARTing.
The only problem I see is with the handling of WONTFIX or INVALID decisions, or decisions in general, for that matter. As this is for newbies, the attitute to better not discuss such decisions is probably the best, but in general, I disagree. Firstly, for that rule to work, we would need a list of respected project contributors, and it seems, even those sometimes disagree about what is invalid or wont get fixed. Secondly, it seems to somewhat contradict rule 1.2. The crucial point here is that the rules - and reality - simply avoids discussion as tho who has the final decision on what. Some of these decisions cannot be reached by consesus, but if somebody is in a position to decide on an athoritarian basis, it should be visible to everybody why he/she can, but others not. So maybe bugzilla should mark the names/emails of those in power red or something ...
This is why we have the module owner list.....
#9 Re: Re: A very nice document
Wednesday March 19th, 2003 2:22 PM
but as Gerv points out, that's not really a useful answer - module owners aren't necessarily the ones that make these decisions... they don't necessarily even read bugzilla mail.
this document is a nice thing to have, but it's not going to change much in practice unless there are some means of enforcing it, and that is difficult if it isn't clear who has authority, or if the person or people with authority aren't involved in the discussion...
#10 Re: Re: Re: A very nice document
Wednesday March 19th, 2003 2:45 PM
It's not always clear who has the authority on a particular issue, but it's almost always quite clear who doesn't. Developers active in a certain area of code, the module peers, the module owners, the super-reviewers, <email@example.com> and to some extent <firstname.lastname@example.org> and QA contributors with particular expertise, all have more authority than people not in one of those groups.
And there are means of enforcing it. If someone makes a change and they clearly don't have the authority to make that change (for example, a random buzilla user reopening a bug that was marked as invalid by the module owner or module peer or an expert QA contact) then they should be told that it's not appropriate. That should be sufficient. If they continue to assert authority that they clearly don't have, that's classified as abuse and Gerv (or me) should be contacted.
It's not that difficult. Those that have been contributing code or QA long enough to establish credentials as valued contributors know who they are and for the most part recongnize others that fall into that catagory. Where it's not obvious we have list like the groups I mentioned above (owner,peers,super-reviewers,QA contacts,staff,drivers,etc.).
Exactly who a "respected project contributor" is depends on a whole load of factors, including the bug in question. There is no way we could define that term even if we wanted to; life is imperfect. The point here is that whining about decisions should be the exception to the rule, with a firm basis, rather than the norm.
#8 Re: Re: A very nice document
Wednesday March 19th, 2003 2:11 PM
In general, most developers give reasonable explanations for marking a bug INVALID or WONTFIX. The most common reasons for disagreement are (a) the problem is a UI issue and (b) the problem is a backwards or sideways compatibility issue. Case (b): Mozilla has made the reasonable decision to drop support for some older non-standard Netscape or IE features. This can sometimes cause problems for the viewer, but the solution is to try to get the web page authors to use the standards, rather than adding "cruft" to Mozilla. In this case, I would suggest that a standard boilerplate be added to the bug report that gives and concise explanation and recommends opening an evangelism bug for offending sites. Case (a): While I like some of the decisions to streamline the interface (and more can be done here), and I think that some of the alternatives that developers suggest are a better approach - I am disappointed when requests for optional functionality are denied even when there is great user support and *no* alternative is provided. An example of this is Bug 39057 <http://bugzilla.mozilla.org/show_bug.cgi?id=39057> . Note that the same functionality for tabs Bug 108973 <http://bugzilla.mozilla.org/show_bug.cgi?id=108973> is not marked as WONTFIX. In the case of UI issues, unless an alternative is provided, I am not sure I agree with just a WONTFIX. But that is just a personal opinion.
#2 What is LARTing??
by naylor83 <email@example.com>
Wednesday March 19th, 2003 8:18 AM
Yes, what is LARTing?
#3 Re: What is LARTing??
Wednesday March 19th, 2003 8:23 AM
"Yes, what is LARTing?"
If you are using Gecko, just hold your mouse over LART and it tells you.
If you're not using Gecko, what are you doing here?
#4 What a waste of time
Wednesday March 19th, 2003 9:47 AM
Nice document indeed.
Perhaps "I think this should be fixed ASAP" and "This bug prevents me from using Mozilla" should be added as other examples of useless comments (by courtesy of MozillaNews Bonsai Watch, e.g. <http://www.mozillanews.or…ch_warning.php3?id=196903>).
#12 Thanks...but I think the frustration shows through
Wednesday March 19th, 2003 3:50 PM
The goal we all (mostly) share is to make Bugzilla as efficient as possible, and the problem we all know: There is too much noise interfering with the signal in Bugzilla, and it's open nature has the potential for disaster.
The Bugzilla Etiquette guide is an essential concept -- something like it should train newbies before they post, and it's great that Gerv took the time to write it -- but I'm not sure about this implementation: The document seems more concerned with the authority and gripes of 'Respected Project Contributors' (RPCs) than with making Bugzilla more efficient and Moz better. It reads like an RPC trying hard to find a constructive outlet for his/her frustrations with non-Respected contributors; the frustration shows through. I think it might drive away potential contributors, leave a bad taste in the mouth of many, and not train them. I'm not an RPC, and I don't like condescension or spending my limited time where it's not wanted.
As written, the mistakes are transgressions against RPCs, and reasoning is the you shouldn't anger them, or else. The focus should be about making Bugzilla more efficient, and how that helps Moz. That's the whole point of this project and most contributors do it for Moz, not to please or annoy RPC's; they don't care about and often don't know about the RPC's.
For example, read the first sentence. Violating the "No Obligation" rule might get the bug ignored by RPCs, etc.
I'm sure it's very frustrating to contribute heavily to open-source projects and deal with 1,000 people, all doing less work than you or none at all, who think they're your bosses. But hey, loosen up. Isn't that what open source, grassroots, etc. is all about? Now you know how politicians feel. You can let the frustration grow, or do what the great politicians do: just smile at the signs of an active, flourishing, grassroots community -- whatever you're giving them, they seem to want more! You didn't think you'd get status, respect or a word of thanks for all your hard work, did you? (Thanks, by the way.)
A suggested rewrite, from a non-RPC who likes to provide solutions, not more problems:
How do thousands of part time volunteers communicate efficiently or ever come to a decision? With so many contributing to Mozilla.org, we could easily spend all day reading each other's comments, changing and re-changing each others' decisions, and never get to improving Moz. If Bugzilla is going to be effective, and if Moz is going to get anywhere, you must follow these rules. Failure to do so, consistently, might result in losing Bugzilla access:
* Posting Comments: Only comment when it's necessary, that is, when you have new information that will help, significantly, resolve the bug: Examples of helpful comments: "If I disable Java in Edit | Preferences | Advanced, the bug goes away" "WorksForMe - I'm using Moz 1.4a on Windows XP Pro (build 20030401009), followed the procedure in the problem description, but don't see the bug" "I think I found the problem in the file foo.bar: Line 26 clears the cache..." "This bug is a duplicate of bug 123456"
Examples of comments that waste time: "Please fix this - it's driving me nuts" -- Vote for the bug, don't comment "WorksForMe on the same Moz build and OS as the previous post" -- unnecessary, no need to repeat what's already been said. "Me too" -- Thanks to you, Moz will truly be great! "I disagree with the policy/decision..." -- Discuss policy in newsgroups, leave Bugzilla to the technical issues.
* Obligation: Remember, Mozilla is open source; it's DIY: If you want something done, feel free to ask nicely, but really it's your responsibility to do it. If you can't code, then do everything you can to pull your weight: Describe the bug completely, clearly and succinctly, with ways to reproduce it, and, if you feel it's necessary, briefly explain the benefits of fixing it. Nobody has an obligation to do it for you, so don't try to insist or complain.
* No personal abuse: Be polite and considerate of others. Of course.
* Changing Bug properties: Don't, unless you know what you are doing. Never change the Priority or Target Milestone fields unless you are the bug assignee or someone else authorized (you'll know it if you are authorized). If in doubt, add a comment suggesting the change.
* Disagreeing about decisions: If you have some new technical information to contribute, please do (e.g. 'Nobody has pointed this out yet: This decision will cause module Foo to crash'). For other comments ('don't remove that feature -- it's my favorite!' or 'I agree with Joe - this is a bad idea'), discuss it in the newsgroups. If you feel it necessary, provide a link to the newsgroup discussion.
If you see someone not following these rules, the first step is to point this out by private mail. They may well not be aware of the problems they are causing or this document. Flaming people publicly in bugs is inconsiderate (see above) and just causes resentment. In the case of persistent offending you should report the matter to Gerv.
In general: Like anything else in life, if you want others to listen to you and want more influence over the direction of Mozilla, you need to prove yourself: Establish a track record of effort, reliability, good results and teamwork with other Mozilla contributors. That's how the people with the most influence, with whom you might disagree, got to make the decisions.
Thanks for contributing!
#13 n/t: Sorry, lost 'Posting Comments' formatting
Wednesday March 19th, 2003 4:06 PM
Your's shines throught in this well crafted revision. Good work!