Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti
4,925
edits
BugzillaImprovements: Difference between revisions
no edit summary
No edit summary |
No edit summary |
||
| Line 61: | Line 61: | ||
=== JavaScript Autocomplete === | === JavaScript Autocomplete === | ||
I would like to see someone finish (or rewrite) the patch I attached to - JavaScript autocomplete for review request field. For bonus points, the same backend code should be used anywhere else that you currently enter someone's bugmail in the UI. I waste an awful lot of time guessing at people's bugmail. -- ted (and requested by johnjbarton for CC) | I would like to see someone finish (or rewrite) the patch I attached to - JavaScript autocomplete for review request field. For bonus points, the same backend code should be used anywhere else that you currently enter someone's bugmail in the UI. I waste an awful lot of time guessing at people's bugmail. -- ted (and requested by johnjbarton for CC; endorsed by Ron K) | ||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=386600 Bug 386600] - JavaScript autocomplete for review request field (patch, July 2007) | * [https://bugzilla.mozilla.org/show_bug.cgi?id=386600 Bug 386600] - JavaScript autocomplete for review request field (patch, July 2007) | ||
| Line 137: | Line 137: | ||
* Make it possible to extract chart data without a login. -- dtownsend. | * Make it possible to extract chart data without a login. -- dtownsend. | ||
* Support for GROUP BY equivalent. -- dveditz (endorsed by axel). | * Support for GROUP BY equivalent. -- dveditz (endorsed by axel). | ||
===Search=== | |||
Improved search, both in criteria and in result output. [Make it so people don't use gmail search in preference to Bugzilla search.] -- shaver. | |||
===Hierarchical Components=== | |||
Let me pick "Page Behaviour" if I know it's a content-side problem, and then we can narrow to layout/DOM/script (or multiple, if it's a script<->DOM interaction!) later. I can "watch" Page Behaviour, or query on it, but the JS team can do that for script stuff more narrowly if they only care about that. -- shaver. | |||
===Proper Component Watching=== | |||
Following fake QA Contacts is hacky, and breaks when people don't reset the field when moving bugs. -- dolske. | |||
===Bugmail=== | |||
Steffen Wilberg says: | |||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=97956 Bug 97956] - Give summary and URL of bugs added or removed from dependencies in bugmail (notification mail). | |||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=125888 Bug 125888] - Give summary/URL of bugs marked as duplicates. | |||
== Speed == | == Speed == | ||
| Line 146: | Line 167: | ||
=== Caching === | === Caching === | ||
Intelligent caching of API and web-UI results, based on modification time for bugs; "generate on change" via the server side hooks would be a DIY option, certainly. -- shaver. Endorsed by axel. | Intelligent caching of API and web-UI results, based on modification time for bugs; "generate on change" via the server side hooks would be a DIY option, certainly. You can cache different versions based on relevant groups; Vary is | ||
analogous in HTTP, and this isn't a research problem in the web-application space. The vast majority of bugs have no group issues at all. Speed and other resource usage is very much the concern -- sending a 301 back instead of generating a pile of HTML is a win for everyone, especially as API use becomes more common. -- shaver. Endorsed by axel. | |||
| Line 153: | Line 175: | ||
=== Reduce Product and Component Count === | === Reduce Product and Component Count === | ||
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!) -- 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 | ||