There's a number of faux pas you can commit when using Bugzilla. At the very least, these will make Mozilla contributors upset at you; if committed enough times they will cause those contributors to demand the disabling of your Bugzilla account. So, ignore this advice at your peril.
That said, Mozilla developers are generally a friendly bunch, and will be towards you as long as you follow these guidelines. 1. Commenting
This is the most important section.
1. No pointless comments. Unless you have something constructive and helpful to say, do not add a comment to a bug. In bugs where there is a heated debate going on, you should be even more inclined not to add a comment. Unless you have something new to contribute, then the bug owner is aware of all the issues, and will make a judgement as to what to do. If you agree the bug should be fixed, vote for it. Additional "I see this too" or "It works for me" comments are unnecessary unless they are on a different platform or a significantly different build.
2. No obligation. "Open Source" is not the same as "the developers must do my bidding." The only person who has any obligation to fix the bugs you want fixed is you. Never act as if you expect someone to fix a bug by a particular date or release. This is merely obnoxious, and is likely to get the bug ignored.
3. No personal abuse. Bugzilla is a window into the world of Mozilla development. The fact that we permit anyone with an account to add a comment does not mean you may harass, harangue or otherwise hassle contributors. Do not make weak threats like "I won't use Mozilla until this bug is fixed!" If a respected project contributor complains about your Bugzilla attitude, then you may have your account disabled. If you don't like this possibility, become a respected project contributor.
2. Changing Fields
1. No messing with other people's bugs. Unless you are the bug assignee, or have some say over the use of their time, never change the Priority or Target Milestone fields. If in doubt, do not change the fields of bugs you do not own - add a comment instead, suggesting the change.
2. No whining about decisions. If a respected project contributor has marked a bug as INVALID, then it is invalid. Someone filing another duplicate of it does not change this. Unless you have further important evidence, do not post a comment arguing that an INVALID or WONTFIX bug should be reopened.
3. Applicability
1. Some of these rules may not apply to you. If they do not, you will know exactly which ones do not, and why they do not apply. If you are not sure, then they definitely all apply to you.
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 this document. Flaming people publically in bugs just causes resentment. In the case of persistent offending you should report the matter to Gerv.
This entire document can be summed up in one sentence: do unto others as you would have them do unto you.
Other useful documents: The Bug Writing Guidelines.
Working in helpdesk for a mid-sized software company... The VP of Consulting Operations let a cab back over his Dell Latitude CPi. The LCD was cracked, the keyboard did not work, but hook it up to external monitor, keyboard and mouse and there was NO PROBLEM!
I pulled out the HDD and stuck it in an identical machine for him. He was on his way in ten minutes.
I've worked in internal IT Help Desk support for a mid sized company with 2000+ employees all using Dell laptops and desktops for 4 years now. I've seen lots of Dell hardware problems, specifically with the backlight in the laptop LCDs. I have NEVER failed to get parts replaced the next day following my call to tech. support. I've sometimes had to follow the dummy-mode step-by-step guide to plugging the machine in, but I've ALWAYS gotten parts replaced and the machine properly functioning in one business day (per our warranty terms). We have a few Compaq desktops, and I've been able to place trouble-tickets online and get resolution quickly too. Others have told me that they can't get satisfaction, but I just don't understand. I hope your luck will change.
Oh...and as for the Inspiron 7500...YES the hinges I've seen do wear out easily, but DAMN...that's one great LCD you got there!!!!
Slashdot Mirror
$2 Billion a year / 50 full time employees = $40 million per year average salary!
Sign me up!
...in his book, Down and Out in the Magic Kingdom. It's a great, short read. Freely downloadable from http://www.craphound.com/down/.
Confused about all this mess? Me too. Is this what (allegedly) happened?
/home/SCO/SysV/mysterycode.c /home/Linus/Linux
[root@unix]$ ls -ld SysV
drwxrwx--x 2 Novell Novell 512 1970-01-01 12:00 SysV
[Novell@unix]$ chown SCO:SCO SysV
[IBM@unix]$ cp
[SCO@unix]$ chown Caldera:Caldera SysV
[root@unix]$ usermod -l Tarentella SCO
[root@unix]$ usermod -l SCO Caldera
[root@unix]$ ls -ld Linux
drwxrwxrwx 2 Linus Linus 512 1991-09-17 12:00 Linux
[root@unix]$ userdel -r SCO
Bugzilla Etiquette
There's a number of faux pas you can commit when using Bugzilla. At the very least, these will make Mozilla contributors upset at you; if committed enough times they will cause those contributors to demand the disabling of your Bugzilla account. So, ignore this advice at your peril.
That said, Mozilla developers are generally a friendly bunch, and will be towards you as long as you follow these guidelines.
1. Commenting
This is the most important section.
1. No pointless comments. Unless you have something constructive and helpful to say, do not add a comment to a bug. In bugs where there is a heated debate going on, you should be even more inclined not to add a comment. Unless you have something new to contribute, then the bug owner is aware of all the issues, and will make a judgement as to what to do. If you agree the bug should be fixed, vote for it. Additional "I see this too" or "It works for me" comments are unnecessary unless they are on a different platform or a significantly different build.
2. No obligation. "Open Source" is not the same as "the developers must do my bidding." The only person who has any obligation to fix the bugs you want fixed is you. Never act as if you expect someone to fix a bug by a particular date or release. This is merely obnoxious, and is likely to get the bug ignored.
3. No personal abuse. Bugzilla is a window into the world of Mozilla development. The fact that we permit anyone with an account to add a comment does not mean you may harass, harangue or otherwise hassle contributors. Do not make weak threats like "I won't use Mozilla until this bug is fixed!" If a respected project contributor complains about your Bugzilla attitude, then you may have your account disabled. If you don't like this possibility, become a respected project contributor.
2. Changing Fields
1. No messing with other people's bugs. Unless you are the bug assignee, or have some say over the use of their time, never change the Priority or Target Milestone fields. If in doubt, do not change the fields of bugs you do not own - add a comment instead, suggesting the change.
2. No whining about decisions. If a respected project contributor has marked a bug as INVALID, then it is invalid. Someone filing another duplicate of it does not change this. Unless you have further important evidence, do not post a comment arguing that an INVALID or WONTFIX bug should be reopened.
3. Applicability
1. Some of these rules may not apply to you. If they do not, you will know exactly which ones do not, and why they do not apply. If you are not sure, then they definitely all apply to you.
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 this document. Flaming people publically in bugs just causes resentment. In the case of persistent offending you should report the matter to Gerv.
This entire document can be summed up in one sentence: do unto others as you would have them do unto you.
Other useful documents: The Bug Writing Guidelines.
FIrst post?
Working in helpdesk for a mid-sized software company... The VP of Consulting Operations let a cab back over his Dell Latitude CPi. The LCD was cracked, the keyboard did not work, but hook it up to external monitor, keyboard and mouse and there was NO PROBLEM!
I pulled out the HDD and stuck it in an identical machine for him. He was on his way in ten minutes.
I was dumfounded.
I even have his 80's "Fashion" stuff. I do miss the Spiders from Mars...
(sigh)
I've worked in internal IT Help Desk support for a mid sized company with 2000+ employees all using Dell laptops and desktops for 4 years now. I've seen lots of Dell hardware problems, specifically with the backlight in the laptop LCDs. I have NEVER failed to get parts replaced the next day following my call to tech. support. I've sometimes had to follow the dummy-mode step-by-step guide to plugging the machine in, but I've ALWAYS gotten parts replaced and the machine properly functioning in one business day (per our warranty terms). We have a few Compaq desktops, and I've been able to place trouble-tickets online and get resolution quickly too. Others have told me that they can't get satisfaction, but I just don't understand. I hope your luck will change. Oh...and as for the Inspiron 7500...YES the hinges I've seen do wear out easily, but DAMN...that's one great LCD you got there!!!!