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.

#12 Thanks...but I think the frustration shows through

by guanxi

Wednesday March 19th, 2003 3:50 PM

You are replying to this message

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, 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 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!