Closed Bug 148557 Opened 22 years ago Closed 11 years ago

Make a page or page-section "So A Bug Is A Huge Problem For You and No One is Fixing It?"

Categories

(www.mozilla.org :: General, enhancement, P5)

Product:
www.mozilla.org
Component:
General
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: netdragon, Assigned: owen.marshall+bmo)

Details

(Keywords: student-project)

Attachments

(1 file, 5 obsolete files)

Revision four
11.86 KB, text/html
Details 
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.
-> asa@mozilla.org 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...
Attached file Revision one (obsolete) — 
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).
*bugspam*
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
Attached file Revision two (obsolete) — 
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.
Attachment #106524 - Attachment is obsolete: true
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.
Attached file Revision three (obsolete) — 
(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.
Attached file 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
Product: mozilla.org → Websites
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.
Keywords: student-project
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
Priority: -- → P5
This is a very very old bug. Can I close now?
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
Attachment #9003504 - Attachment is obsolete: true
Attachment #9003505 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: