I think there should be a section on Mozilla to tell what people should do if no one is paying any attention to a particular bug and it is really important to them (yet they are not a developer). I was talking to someone in #mozilla on irc.mozilla.org expressing his displeasure over bugs not being fixed that is hurting his company. But he isn't a developer nor can assign one to the task of fixing these bugs. I think there should be a document outlining steps people can take if no one seems to be paying any attention to a bug. I would write this myself, but I don't think I'm qualified to unless someone sent me a rough copy. :-) I think it should also explain why some bugs go unfixed for a long period of time.
-> email@example.com Since he probably would be the most qualified to write this.
Assignee: rudman → asa
I don't know if I am quite qualified, per se =) But I am working on it...
Created attachment 106524 [details] Revision one First revision of this document. Comments? Concerns?
asa: comments? Gerv
Owen: Please also mention about not spamming a bug, calling the developers things like, lazy and stupid... or putting in advocacy comments with no content useful for development.
Owen: Basically, I liked it though although it should be looked over by a lot of the community.
As a quality assurance person for the Calendar project and Tech Evangelism project as well as a quality assurance person for OpenOffice.org, I would also have to say that clear, gramatically correct messages are nice. Messages such as: click the file thingy then the print thingy, after that hit the page thing and amke it 2 and pass enter are not very helpful. This (made-up) example is hard to follow (needs to be multiple single-steps that are numbered and on separate lines), not grammatically correct (notice the lowercase letters and the run-on), not technically correct (notice words such as "thingy" and "hit" (I know an end-user might not know the correct terms, but I think they could come up with better than that)), and has misspellings ("amke" instead of "make" and "pass" instead of "press"). I try to rewrite instructions following those guidelines so that the steps are easier to understand to the developer who eventually will fix the issue. As for what you have already written, it looks fine. Much seems like repetition of what can already be found throughout the mozilla.org Web site, but sometimes that is what it takes. I think more of the document could be linked to other documents via hypertext as well.
Stealing ownership; going to do more work on this in a bit =)
Assignee: asa → Malachi
see http://www.mozilla.org/wishlist-faq.html Owen, the page looks fine, but I think the contents should be merged into existing QA docs; with the limited resources we have with documentation, we should avoid duplicate contents and minimze the # of files to maintain
In most case, I think we shouldn't have duplicate information, except in the case where we really want people to read that. If they have to look through a QA document to find what we want them to see, they might miss it. Please also add "They said my bug is an invalid or wontfix, what do I do?" section . (Take it to the newsgroups, etc).
Owen: Is there a specific reason behind that *bugspam* thing? Or are you saying we should mention bugspam?
I have just read the attachment,and to be honest I was a bit diaappointet. I'll try and list the reasons 1. First step are really just common "bug care", and while it might attract some attention to a bug that is badly filed, does not really bugs that are just dormant. 2. After reading the initial bug description, step 7 comes close to being insulting. The purpose of this document is to help non-developers, and therefore it is not at all polite or contructive to have the last resort be "Try and fix it yourself". 3. I'm missing information regarding how to get a bug report (in mint condition) some attention, and if needed some driver involvement. Getting driver involment might not be relevant for the individual user, but lets say I'm the sys-admin of some place and said bug keeps me from deploying or cost alot of support.
Component: Web Developer → Mozilla Developer
QA Contact: rudman → stolenclover
Created attachment 138530 [details] Revision two Revision two >3. I'm missing information regarding how to get a bug report (in mint condition) >some attention, and if needed some driver involvement. AFAIK, driver approval is needed only when the trunk is in late beta stage. If the bug is critical or the patch not risky, you can ask for driver approval. Otherwise, you should wait for the next development cycle.
I'd like you to mention something for developers... That some bugs go unfixed because the main developers don't have time for it and that they could be asked through email by a volunteer with more time what to do. Also, if there is any information on the implementation of a bugfix (something many developers hold in their head but never mention in the bug), it should be written as a comment so that less experienced developers can pick up the bug and fix it.
Created attachment 157894 [details] Revision three (In reply to comment #5) > Owen: Please also mention about not spamming a bug, calling the developers > things like, lazy and stupid... or putting in advocacy comments with no content > useful for development. OK, added. > Please also add "They said my bug is an invalid or wontfix, what do I do?" > section . (Take it to the newsgroups, etc). OK, added (In reply to comment #13) > 1. First step are really just common "bug care", and while it might attract some > attention to a bug that is badly filed, does not really bugs that are just dormant. This is true. However, many of these steps are _very important_ to dormant bugs. IE, a bug is dormant due to lack of testcases, etc. > 2. After reading the initial bug description, step 7 comes close to being > insulting. The purpose of this document is to help non-developers, and therefore > it is not at all polite or contructive to have the last resort be "Try and fix > it yourself". You are right. Daniel pulled this, thanks. > 3. I'm missing information regarding how to get a bug report (in mint condition) > some attention, and if needed some driver involvement. Getting driver involment > might not be relevant for the individual user, but lets say I'm the sys-admin of > some place and said bug keeps me from deploying or cost alot of support. OK, added with comment 14 caveat. I am by no means done with this ;) My next plan is to go through and add links throughout the document to other sources of information that could be helpful. Sorry about creating irony by letting this bug lay dormant ;)
Attachment #138530 - Attachment is obsolete: true
Owen: Nice job. Can you please mention that advocacy or venting is in general better recieved on the Mozillazine Forums? Some people are just so pissed off by bugs they just need to vent. > When in doubt, ask someone. You can try getting on irc.mozilla.org. This might be the best place to do it, because I think it'd be better people go on the forums before going onto IRC. Also, can you please link to the Bugzilla Guidelines from the beginning of this guide?
Oh, and another thing... I think its a good idea to mention that people can set up their own private pages to discuss theirs and others' opinions about why a particular bug should be fixed.
re revision 3: - please add gerv as page maintainer - remove me as the author, and add (With thanks to Brian 'netdragon' Bober, Henrik Lynggaard Hansen, and Daniel Wang) at the bottom - please date the document > Check to be sure the bug is not a duplicate Check the bug is not a duplicate, ditto for "Check to be sure the bug exists in the latest build" > You just have to find it. link to http://www.mozilla.org/quality/help/beginning-duplicate-finding.html > If you lack the privledges to reassign it, CC the bug owner and QA contact, > or CC a privledged user and ask them to reassign it. typo: privileges and privileged gerv, don't all users have the ability to change owner/qa contact/product/component fields? > Check that the severity is set properly. this is asking people to abuse the severity field. This should be removed - and we should add "Please do not change bug fields (and create bugspams) just to get attention. Change fields and add comments only if the changes add value." > Provide a testcase. If possible, provide a testcase that allows the > developer to quickly reproduce the bug. If there aren't any testcases in > place, follow these steps. Detail the steps that you take to make the bug > appear. Or, if the bug affects a HTML page, go to the Bugathon page and > follow the instructions listed to make a simplified testcase. These tests > are invaluable tools that allow a developer to quickly spot and test your bug. -> Provide details. Provide details that allow the developer to quickly reproduce and identify the bug. Detail the steps (if the bug report doesn't have any) that you take to make the bug appear. Or, if the bug affects a HTML page, go to the Bugathon page and follow the instructions listed to make a simplified testcase. These tests are invaluable tools that allow a developer to quickly spot and test your bug. > Beware of @netscape.com or @formerly-netscape.com.tld owners. @netscape.com is for customers of Netscape the ISP. @formerly-netscape.com.tld is for former Netscape employees. > WONTFIX bugs can take many forms. INVALID bugs can take many forms. > If this happens, the best thing to do is to go to newsgroups link to www.mozilla.org/community/developer-forums.html > Don't advocate on the bug. Don't advocate in Bugzilla. > Voting has made developers highly interested in bugs, and has provided many > high-quality changes for Mozilla Voting has motivated developers and provided many quality changes for Mozilla
Maybe we should better define what advocating on a bug is.
Created attachment 184430 [details] Revision four Adds the changes suggested by Daniel to the file. Further opinions would be most welcome, of course...
Attachment #157894 - Attachment is obsolete: true
This dormant bug needs to find a new home, in a product that owns a web server. I'm going to wildly guess at www.m.o, rather than b.m.o. In either case, if you haven't lost interest by now, please find a reviewer, a place for it to live, and some things to link to it: bugspammers aren't going to read an attachment in a bug in a dead component.
Component: Mozilla Developer → www.mozilla.org
Product: Documentation → mozilla.org
QA Contact: danielwang → www-mozilla-org
Version: unspecified → other
Adding student-project keyword. This could be an interesting document to update and/or expand for someone who has just recently gone through the process of learning how the Mozilla development project works. Screencasts or other types of videos could be interesting additions to straight documentation.
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
This is a very very old bug. Can I close now?
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WONTFIX
Created attachment 9003504 [details] Bug 148557 - Pass triggeringPrincipal into openDialog for window opening code. r?Gijs
Created attachment 9003505 [details] Bug 1485577 - Pass triggeringPrincipal into openDialog for window opening code. r?Gijs
You need to log in before you can comment on or make changes to this bug.