Closed Bug 15971 Opened 26 years ago Closed 26 years ago

Change bug description on http://bugzilla.mozilla.org/

Categories

(mozilla.org :: Miscellaneous, task, P3)

Other
Other

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: BenB, Assigned: endico)

References

()

Details

Bugzilla is not only used for bugs, the description should reflect that.
Assignee: mitchell → endico
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → WONTFIX
Can't find the page on the new homepage anymore.
This is still a problem with the main Bugzilla page.
Status: RESOLVED → REOPENED
Summary: Change bug description on products page → Change bug description on http://bugzilla.mozilla.org/
Matty, you're talking about <URL:http://bugzilla.mozilla.org/>? This should really go away, too :-): "If your browser uses the blue N logo, your bug report should go there." Changing topic and reopening.
Resolution: WONTFIX → ---
Yes I am. The mozilla.org sidepane also says "Submit A Bug" as a link. This would be better as Submit A Bug/Enhancement Request, even if it has to take two lines. It is important that it is obvious that RFEs are placed in the bug system at every point users might arrive.
Status: REOPENED → RESOLVED
Closed: 26 years ago26 years ago
Resolution: --- → FIXED
Matty, endico asked me on IRC about this. Adding "Enhancements" would be useful only for people not having read bug pages on www.m.o. They should not use bugzilla at all. Note, that endico changed the page and added links to the bug pages, what makes much more sense. Having read the bug pages, it should be clear, that "bug" used at the Mozilla community may mean "bug" or "enhancement". (Maybe we should think about a new name.) She also changed the wording of the Navigator instructions, which should be clearer, too. I'm marking this fixed.
My point is that many people are not aware Bugzilla is for enhancements. They're often not going to read "bug" pages to learn "bug" doesn't mean "bug" if they don't want to submit a bug! The first link is the _most_ important place for this to specify it's for enhancements. So basically, arriving at www.mozilla.org, they think it's only for bugs, since that's what it says, go straight to netscape.com and submit their enhancements there. Then they're redirected back to mozilla.org, wherein they find - guess what ? - moz.wishlist. They post there and then I or someone else has to submit them to the bug system. This is very possible and it needs to be streamlined.
Matty, The first link is surely www.m.o, not bugzilla.m.o. On the left is a link to "Feedback". <quote src="Feedback"> If you have a suggestion about some feature you'd like to see added to the client, post to the appropriate newsgroup or to the wishlist group. </quote> Feature suggestions is what wishlist is for, isn't it? I think, the reason was exactly, that someone like goes through the wishlist and sorts out duplicates, invalids etc. *bofore* they reach the developpers to save them time. (For this reason, *I* would even remove the "appropriate newsgroup".)
d/like If someone really comes to bugzilla.w.o first, he isn't even aware, that bugzilla is also used for RFEs nad will go to www.m.o for them...
OK, the last argumentation was a little broken, I just stood up... :-) 2. Try: If someone somes to bugzilla.m.o., this is most likely because he wanted to report a bug and was directed there. Maybe he just reads the "Bug Writing Guildlines" and doesn't know, that bugzilla is used for RFEs, so he goes to www.m.o for them... If he reads the bugs pages, he gets to know, that bugzilla is used for RFEs w/o knowing of wishlist, which is bad IMO. But the bottomline, where we will propably disagree, is, that usual "users" shouldn't even know, that bugzilla is used for RFEs, but go to wishlist instead.
The problem with wishlist is that it is one big bit bucket. If it weren't for me and a couple of other people the suggestions would be all ignored. Mozilla.org should direct all enhancements into Bugzilla where they can be considered. There are already good facilities in place to filter duplicates, and they can be tweaked. A newsgroup can't have these facilities, and that's why wishlist failed dismally. There may be a feedback link, and that's fine, but there's also a "Submit A Bug" link, which you would look at before "Feedback", because it's exactly what you want (more specific). Therefore I interpret "Feedback" as meaning site feedback and would ignore it.
The purpose of the wishlist is to have a place for people to brainstorm ideas for the browser. Few if any, of these ideas are either unique or polished enough to submit as rfe's without discussion first. I think the current model of letting people hash out ideas and occasionally adding the good ideas to bugzilla is a good one. I think it would be a mistake to press bugzilla's use as a RFE handling system. We're still learning to come to terms with huge numbers of people submitting bug reports. The bug reports alone are already stressing our ability to cope. While we have processes in place to deal with high volumes, noise, and duplicates, we clearly have a lot more work to do in this area. Its already a huge amount of work just going through normal bug reports. Our developers' focus right now is on getting a product shipped. Let's not deter them from that. I think it would be helpful to have a wishlist faq that contains a list of frequently-asked-for features and a list of features that people ask for that are already implemented. Matty, are you interested in maintaining that?
> The purpose of the wishlist is to have a place for people to brainstorm > ideas for the browser. Few if any, of these ideas are either unique or > polished enough to submit as rfe's without discussion first. I think you seriously underestimate the value of the ideas in wishlist. There's a lot of chaff, sure, but there are also a lot of good ideas. I personally think the bug system is a better place to discuss an RFE than a newsgroup. > I think the current model of letting people hash out ideas and > occasionally adding the good ideas to bugzilla is a good one. It's not occasional. Ideas that come from wishlist are usually not marked as such. > I think it would be a mistake to press bugzilla's use as a RFE > handling system. We're still learning to come to terms with huge > numbers of people submitting bug reports. The bug reports alone are > already stressing our ability to cope. While we have processes in > place to deal with high volumes, noise, and duplicates, we clearly > have a lot more work to do in this area. Its already a huge amount > of work just going through normal bug reports. Our developers' focus > right now is on getting a product shipped. Let's not deter them from > that. I already am dealing with this, how does it differ if it's in the bug system? Anything worthwhile will get routed to Bugzilla anyway, and anything not worthwhile I already help to filter. I would be happy to transfer effort on this into Bugzilla, which I already do to a degree. Furthermore, the wishlist has a small amount of traffic compared to the bug system anyway. > I think it would be helpful to have a wishlist faq that contains a list > of frequently-asked-for features and a list of features that people ask > for that are already implemented. Matty, are you interested in > maintaining that? Well if you remember, I was developing a FAQ, and it already had this in it. I passed that onto Pat to incorporate into the FAQ, but I have no idea what will be added and what won't. It may well be a good idea to maintain this separately, in which case I would be happy to. If you're going to leave wishlist as is, it sure would be good to link to this list on the community page, which is where I suspect most people find it (and anywhere else they might find it). Pat, maybe include this section as a question on the FAQ and link to the page which I could maintain?
I suspect there's more than enough material for the wishlist to have its own faq. Linking to it from the writeup for the wishlist group on the community page is a good idea. Why don't you mail me what you have.
OK, but it was only a section in a draft, so it didn't have that many. Give me a couple of days, and I'll scour the resources to work out what to put in there. Seems like this could be a good basis for enhancement reporting guidelines.
v
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.