Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti
4,925
edits
BugzillaImprovements: Difference between revisions
Jump to navigation
Jump to search
no edit summary
(→UI) |
No edit summary |
||
| Line 1: | Line 1: | ||
This is the collected input about changes community members would like to make to bugzilla.mozilla.org (June 2009). | This is the collected input about changes community members would like to make to bugzilla.mozilla.org (June 2009). | ||
There are a number of older suggestions [[Bugzilla_Fixup|here]] | There are a number of older suggestions [[Bugzilla_Fixup|here]]. | ||
= Code = | = Code = | ||
| Line 264: | Line 264: | ||
At least 80% fewer components, and many fewer products. We have 8 different DOM components, but nowhere obvious to put postMessage; 7 Java-related components; 12 different layout components; SQL (not supported anywhere, and not related to our own sqlite use or APIs); 9 different widget components, etc. -- and that's just Core. Mostly these subdivisons seem to be used as ways to narrow queries or get bugmail people want, all of which I think would be done better through attribute-based notifications/queries instead of something between the reporter and the bug. (I routinely have to take an entire minute just to figure out what product+component I want to file a bug, and I usually already know what code it's in!) The problems are bug filing complexity, query complexity, choice paralysis, how quickly it gets out of date, the costs the bugzilla imposes for _removing_ components, the grotesque effects on the UI. I _know_ things about the kind of bug it is, just let me specify it in a way that doesn't make me read all the descriptions of the components. -- shaver | At least 80% fewer components, and many fewer products. We have 8 different DOM components, but nowhere obvious to put postMessage; 7 Java-related components; 12 different layout components; SQL (not supported anywhere, and not related to our own sqlite use or APIs); 9 different widget components, etc. -- and that's just Core. Mostly these subdivisons seem to be used as ways to narrow queries or get bugmail people want, all of which I think would be done better through attribute-based notifications/queries instead of something between the reporter and the bug. (I routinely have to take an entire minute just to figure out what product+component I want to file a bug, and I usually already know what code it's in!) The problems are bug filing complexity, query complexity, choice paralysis, how quickly it gets out of date, the costs the bugzilla imposes for _removing_ components, the grotesque effects on the UI. I _know_ things about the kind of bug it is, just let me specify it in a way that doesn't make me read all the descriptions of the components. -- shaver | ||
===Default-Uncheck Flag Assignment Acceptance=== | |||
b.m.o. has a local customization allowing people to define whether they are accepting flag assignments (e.g. review requests) for each flag. These should be default-unchecked rather than default-checked. Perhaps we could also have a flag day (groan) where we uncheck everyone's flags, then check them again for all people who have plussed a flag of that type in the past. This would be a good first guess at the set of people who actually accept such requests. | |||
Later, this acceptance data should be tied into the autocomplete system. | |||
= Bugs = | = Bugs = | ||
* Can't put an alias in a bookmarkable template. | * Can't put an alias in a bookmarkable template. | ||