As well as the mechanism for automatically resolving some UNCONFIRMED bugs, mentioned in an earlier blogpost, we have some other ideas for trying to improve Bugzilla before the Firefox/Thunderbird 1.0 hurricane hits us.
- Build a “feedback webtool”, like Netscape’s, which feeds directly into a newsgroup or forum. This is to try and divert rants, support requests and other non-bugs away from Bugzilla. Asa and Kerz are working on this.
- Build a “Report a broken site” webtool which aggregates problem URLs and produces lists and reports, rather than having one bug per report. Robert Accettura is doing the hard work for us here.
- Redesign the b.m.o. front page to include links to these two tools and a better community link. I’ve done this; it’ll go live when the two webtools are online.
- Redo Bugzilla Helper to be clearer and have less text. Stop accepting bugs in anything other than the latest release.
- Change the search people do before filing bugs to search all bugs (including resolved ones) filed in the last two months, and use Myk’s “find a specific bug” feature to get better relevance.
- We currently have much more active people in the forums than Bugzilla. Try and convert more forum participants into QA triagers. Suggestions for how to do this are welcome. I think we need a good document which we can publicise. This one is OK but needs work.
- Give more people the “canconfirm” privilege by publicising how to get it more widely. Get triagers to suggest candidates based on good bug reports they’ve seen. (Some have suggested giving it to everyone by default.)
- Get some of the webtool-writing crew Blake recruited to to write tools to mine the database and suggest likely duplicates.
- Add a READY state which goes between NEW and ASSIGNED. Bugs move to READY when they could be picked up and fixed without further work. So they are clear, have steps to reproduce, and a testcase if applicable.
- Reorder the product list page to put Firefox and Thunderbird at the top.
- Check the b.m.o. Referer logs to see who links to us, and get the top ones to relink directly to the support pages.
What do you think? I’ve numbered them this time for ease of reference :-)
Other suggestions are welcome – please give them a number too, starting after mine. Remember, we are looking for low effort, low disruption, high impact. So blue-sky Bugzilla feature suggestions probably won’t fly.
I’ll add one:
We need a GOOD support page. One with minimal words, that puts people in the right place. All these tools are wonderful, but we need to direct users to the right channels.
We need to move the developer oriented tools, such as bugzilla, away from end-users (keep mentioning of it minimal unless it’s towards developers.
Personally, I think the Help menu is a big place to start. I’m hoping we can add the “report this site” link in there in the near future when my little tool is done.
I’ll add another item that is fairly important (in my mind): redesign b.m.o.
Honestly, the thing is hideous and hard to use for most “average” users. It’s intimidating trying to work with something that’s that horribly designed. Yes, I know, it’s meant for work, not looks. But a bit of polishing here and there can *really* help (ala https://bugzilla.redhat.com/bugzilla/index.cgi).
Note: this may not help until b.m.o upgrades to bugzilla 2.18 because of bug 240093 (“Unable to confirm other people’s bugs, even with the canconfirm permission”) (Which itself is a reason for higher UNCONFIRMED rates.)
12. Create a bmo interface specific for Firefox bugs. The average user will be completely lost for choosing a product or a component to fill in the bugs. A simplified interface, that will present only the fields relevant to Firefox will help a lot! The same can be done for Thunderbird.
Re #7 Re geka
canconfirm definately should not be on by default, (it would be abused, imo). I have not yet had a problem with canconfirm on me with b.m.o (that I have been aware of).
I have heard talk about a possible “wizard” interface to the helper, which would be a big help when choosing some of the “top” products.
Not sure how much work is involved in this one, but some sort of “warning/lockout” system (user-variable/bit) where people who continuously enter un-helpful information as a comment to a bug, flame or otherwise disrupt the actual bug-triage/fixing process can be eventually locked.
Bugzilla user (youruser) has been warned.
One of our [insert some management sounding title]
have expressed a concern regarding your comment #x on Bug #x ([link /]) If you continue with this trend you risk loosing all of your rights with bugzilla.mozilla.org. There is no need to reply to this message.
He/She left the following message in addition:
[[[ Please do not try to have a conversation on a bug, if it does not pertain directly to this bug. Debates and conversations of that nature can be taken to the appropriate source (link to support page), you are allowed to post a link to the thread/a note to check [x] newsgroup entry for a thread on the issue if it does pertain to the bug. ]]] (prior entered by warner)
(This will be shown to you on your next entry to Bugzilla.)
~The Mozilla.org [QA] team.
(Please do not reply to this automated message)
That was a bit lengthy, though hope it sparks some thought.
Redo Bugzilla Helper to be clearer and have less text. Stop accepting bugs in anything other than the latest release.
I don’t agree on that one. The foundation said that 1.0, then 1.4 then 1.7 where long term stable release, which should be used by other vendors to make their product. How can those vendors report bugs in bugzilla if the foundation does not support older releases ?
Assuming that we have layout bug, just the typical reflow thingie.
1. Step Select Product: Firefox
as thats the product what you have.
2. Step Select a component: hmmm nothing fits so probably General would be a good guess
3. step Arrrgh, we added another unco to the wrong component
repeat the same procedure with FF selection and bugzilla helper. again Arrrgh
I am not sure whether this will be prevented when one does not have confirm privilegs, but once you have selected ff you will certainly file this bug in the wrong component.
I recently had the feeling that the amount of layout bugs flowing in dropped, this might explain it, they simply go to ff general or some other arbitrary component.
Re Bernd’s comment: This is why I filed https://bugzilla.mozilla.org/show_bug.cgi?id=221306 some time ago. :)
Re #4: What do you think of http://bugzilla.gnome.org/simple-bug-guide.cgi (you need to register a bugzilla account to test this)? Also it (mostly) only splits up the steps in single pages, i find this concept quite good. I’ve uploaded some screenshots for this, see
Note the single pages change when selecting for example another kind of bug (enhancement gives you a different bug form than when filling a normal bug).
I don`t no if it fully applies to this and maybe it already has been discussed, planned or been worked on:
14) Take the m.o page stuff out of b.m.o asap. For this you `d need a decent CMS of course. And then applying privilges to the different paages/areas.
“Bugs” in m.o weppage should then reported via something that`s connected to the CMS. (Well if the CMS fails there should be reports to that in b.m.o maybe)
I know that the CVS/Bugzilla machanism has worked so far, but I think with the things happening and the things that are to come this improvment could really help.
Re: 9 – this seems like the wrong place to put the extra state to me. The criteria for “ready” sounds like bugs which are currently “new”, so implementing that involves moving many UNCOs to NEW (for example, those layout bugs without testcases that were mentioned in the previous entry), and moving many NEW bugs to READY. Would it be better to add the stage between UNCO and NEW instead? (I’m not actually sure – just a thought)
Re: 10 – we don’t really want to emphasise Firefox any more. If anything, we should emphasise Browser more (as Firefox only covers the UI, and everything else goes under Browser…). More Browser bugs are already filed under Firefox than vice versa.
@Ludivic – vendors basing products a stable branch would hopefully be able to find someone with sufficient status to bypass the bugzilla helper. The helper is aimed at end-users; people with more experience can use the unrestricted new bug form.
Robert: My new b.m.o. front page is intended to be such a resource. I suppose there’s an argument that it’s already too close to Bugzilla… What about http://www.mozilla.org/support/?
Max: Maybe in the future (and the Bugzilla team is working on a new look), but that doesn’t IMO meet the “bang for the buck” criteria.
Which fields on the enter bug form are not relevant to Firefox?
That’s a massive can of worms. Who gets to warn? What’s to prevent people maliciously warning and locking out useful contributors because they disagree with them? Who has to arbitrate? If people are abusing Bugzilla, they should be mailing an admin (e.g. me). I currently get less than one report a month. If there’s widespread abuse going on, I want to know about it. Only when this mechanism doesn’t work should we look at something else.
Apologies; I wasn’t clear enough here. This restriction would only apply to the guided form. And if vendors themselves are filing bugs, they won’t be using that form.
Bernd mentioned bugs getting filed in the wrong component. We agree this is a big problem, and the solution is the component reorganisation, which we want to as soon as Firefox and Thunderbird 1.0 are out of the door.
Currently, I suspect far more bugs are filed in Browser when they should be in Firefox than the other way around. Can anyone else confirm or deny this? I can check when I get home.
mcsmurf: what advantage does the Gnome wizard give you over our single-page form, apart from eliminating some unnecessary fields for enhancements?
jm.one: I can’t see how changing what backend we use for http://www.mozilla.org will help with the problems we are trying to solve. Can you elaborate?
Maybe in your component ;-) It’s becoming increasingly clear to me that the Layout component is weird – you guys do things differently (and, in many ways, better) over there. But it’s dangerous to take what’s true in Layout and apply it to all of Bugzilla. (And, fair point, it’s dangerous to do the reverse.)
The component reorg will change things quite substantially. But do you have any hard evidence for your second assertion? I’m interested in the levels of misfilings.
By the way, everyone, most HTML works in comments, including <blockquote> and <b>. I just wish MT had threaded comments…
I don’t have any evidence that more Browser bugs go into Firefox than the other way around – that’s just my impression from browsing some bugs and, in particular, watching the bot on #firefox which announces changes to firefox bugs (including changing product).
Maybe you could try and do a query on that? (although that would only tell you how many bugs have actually been corrected rather than how many are/were misfiled in total – my impression is formed on that possibly skewed basis as well)
I’m not sure what the latest plans for the component reoragisation are but one solution to this problem would be to create a bunch of components under ‘Firefox’ which are only used for filing new bugs e.g. Firefox : Page Display. From here bugs would be moved into the appropriate ‘real’ category – in the example that would probably be either layout or tech evangelism.
Additionally, the simplest way of filing bugs (the helper) would only give access to the Firefox product. The primary job of people doing initial triage would be to move bugs out of the dummy Firefox components and into their actual components, (of course some components would/could be ‘real’ components like bookmarks or, alternatively, one could create a ‘Firefox Unconfirmed’ product that contained only new bug reports). Obviously, it would also be good to filter out obvious dupes and try to confirm as many bugs as possible at this stage.
The same idea would apply equally well to Thunderbird.
The advantage of a multipage wizard is that the user only has to focus their attention on a single step at a time so they are less likely to miss a step and less intimidated by the complexity of the process. I would also suggest that a multipage approach makes it more likely that the user will file a good report; dividing the explanatory text into small chunks means it’s more likely to be read and dividing up the data entry means each step will be given more time.
Has anyone considred using XUL to produce the helper? Apart from providing a nice easy to use native interface, it would also be a nice demonstration of the abilities of (remote) XUL and, hopefully, be a win from a marketing point of view.
I think it’s just better, it really guides you through bug creation, leaves out unnecessary steps, you don’t have one single long step. Just try it, you’ll see it’s better IMO :)
#4 “Stop accepting bugs in anything other than the latest release.”
Bugzilla had an alert before saying that the current build is too old to report a bug, but that can too easily be dismissed.
How about that when the user visits the page with a too old build, that you are shown a page informing you where to get a newer build?
And if the user still wants to submit the bug, he has to check a checkbox with a text saying something like “I have tested this with a nightly build but are not currently on that computer” + submit to come to the page where you enter the bug.
The page where you report the bug should also have a checkbox where you confirm that you are able to reproduce the bug with a clean profile and no extensions running. There could be a link showing with images how this can be done (creating a new profile).
Many bugs are also more of a question bug, like this doent work, how do I fix it, instead of an actual bug report. I guess this is # 3? Where people are encoureged to use the mozillazine forms to ask before filing those kind of bugs.
>ff vs browser bug filing:
After searching for table, form or div inside the firefox general unconfirmed I believe it supports my theory that the current bugzilla organisation encourages bugs in the wrong component. The first bug after searching for table https://bugzilla.mozilla.org/show_bug.cgi?id=247176 is even more disturbing: three people comment in the bug, instead of moving the thing into the right component it gets moved from Web Site to FF-General. Do our triagers not know what to do? Maybe we need to explain the procedures internally also.
That query page needs to be intelligible by normal humans; using it shouldn’t be an art.
For example it needs to be possible to generate a list of unfixed blocking-aviary1.0 normal-or-higher Firefox bugs in about 30 seconds.
IMO I think bugzilla is kinda old and trying to fix all these things will help, but I just think there should be a new bug monitering program. I like phpBugTracker (see http://phpbt.sourceforge.net/.)It’s a much nicer interface, IMO
Justin Wood (Callek) wrote:
I could have been clearer. Bug 240093 occurs for users that only have canconfirm permission, and do not have editbugs permission. The bug doesn’t occur for Justin, who has editbugs permission (and so can also do things like resolve other people’s bugs as duplicate), but would occur for those bugzilla 2.17.x users who were just given canconfirm privilege as proposed.
On point 4, that one alarms me for a slightly different reason.
What do you consider “the latest release”?
There are stable branches (1.7.x), milestones (1.8a), final versions (the forthcoming 1.8) and nightlies to consider. Under all of these, the “latest release” has different meanings.
Furthermore, the more a stable branch ages, features will land in milestones and nightlies that will not appear in a stable branch at all. People using them will have to wait for the next stable branch. I’ve seen this happen before. So a bug which is perfectly valid for a stable branch but will never get fixed on the branch may be WORKSFORME on a milestone, for example. How would you propose to handle that?
One suggestion would be to exclude the stable branch entirely after about 3 to 6 months, but that gives the impression that the stable branch isn’t one you care about…
Absolutely. We agree with you 100%. And we will fix this :-)
The “find a specific bug” form is supposed to help people for whom the advanced search page is too complex. It has to be fairly complex, because it’s powerful. But I agree, the interface for searching for flags such as blocking-aviary-1.0 could be improved.
Yeah. Old software is always really bad. I mean that Linux thing, it’s 10 years old now, and everyone’s stopping using it. Right? :-)
Fair question. It’s open to discussion. Remember that this restriction would only apply to people using the guided form. Having said that, I’d say anything on the current stable branch (i.e. 1.7.0 onwards), the latest final release (1.7 again, at the moment) and also anything since the last stable release on the trunk (so 1.8apre onwards.)
Possibly, but what are the chances that a random person without canconfirm finds a bug in 1.7 that hasn’t been found by anyone else, can’t be reproduced in a more recent build, and that we want to fix on the 1.7 branch? Pretty small, I’d say.
I think bug reporters should be more encourage to write good testcases.
I believe that is one of the most important part of a bug report. A bug report without a testcase is not useful.
I think it would be useful, if there was a page which would very simple describe how to make a testcase, and how to submit it.
I think most of the improvements you mention are really great ideas!
I am just glad you guys are working on it. Bugzilla needs to be more user-friendly. I am sure, you guys know it!. Keep up the good work!!
Gerv, what happened to:
14. Split “Browser” into “SeaMonkey” (or “Mozilla Suite”) and “Core”.
This doesn’t involve doing anything other than creating the new product and moving some components into it. No need to change any assignees or anything like that… From my point of view, it seems like a lot less work than most of the suggestions, and would go a long ways towards reducing confusion… Or am I missing something?
How about restricting the filing of bugs to any official release (e.g. 1.0, 1.4, 1.7) plus pre-next-release (e.g. 1.7+/1.8a) versions?
Re: Boris, (that should be #15)
Re Gerv on #13
I agree it is a “can of worms” so to speak, I would propose only staff, or others who staff deem are “capable” of handleing the responsability. I personally have no clue how much if any problems occur with such users. And from your response the work required for this may not (imo is not) [be] worth it (right now).
Though you must agree when and if this comes up (which will be more apparant as more of the “haxor” folk, who I have experienced in majority to be lude/rude in near-public fora. Though that is my opinion and from my experiences elsewhere.
Splitting Seamonkey out is good, I like.
Boris: that’s the Component reorg, and it’s very important, but Asa is adamant that we shouldn’t do that before we release Firefox and Thunderbird 1.0. Our intention is to do it immediately after both of those products are out the door.
So, I didn’t put it on the list, because there is already enough stuff there to discuss :-)
Gerv, I guess I just don’t understand why we’re considering more time-consuming and potentially more disruptive things while being adamant about not splitting up Browser.
Note that this is NOT the “component reorg” that’s been talked about for a year now. This is a much more modest and less scary proposal. I do wonder whether people are getting this, given that they keep calling it “the component reorg”.
You need to convince Asa, not me. I’d be happy to do whatever level of reorg most people felt comfortable with.
Bernd: I’m not quite following you, but this looks like a different idea. Why not email me about it? :-)
Boris – while that’s not “the” component reorg, doing that is part of that plan, AIUI. That particular bit is, as you say, lower impact and possible to do in isolation.
As to why “we” are “considering” doing other “things” – I think it depends who/what you include in that. I would imagine that much of the stuff in the list here has no chance of being seriously considered until after the reorg, if at all.
I was taking this as a discussion of things that might be nice to do at some time in the future…
Would it be too much load on the server if Bugzilla had gzip output added? Reason for this is that some of the bugs can get pretty massive (bug #18574 for example, a pageload there is over 0.5MB – not fun on 56k :( ), and a lot of the content is ASCII text anyway.