BugzillaImprovements
Code
UI
Simpler Layout
Collapse all the non-requried and less-frequently used fields by default. This would simplify the layout of bug reports and make it less daunting for new participants. Allow user prefs to control what gets expanded and collapsed by default for each user. More familiar, easier for new users, streamline navigation. -- chofmann
No default UI changes
I don't want any changes to the bugzilla UI. Firefox's needs are clearly sufficiently different from the rest of the world's that accommodating them is painful and invasive. I just want the tools to build a UI and workflow that suits us. -- shaver
Text Area Visible On Filing
When I'm filing a bug, the text area in which I am to describe the bug should be above the fold. Everything else (including the component it's in) is subsidiary to the bug description itself, and should be farther down (or invisible -- why do I care who the default CC: is? why would I ever change the QA contact?) -- shaver
Fix Mid-Air Collisions
Fixed mid-air collision handling, such that:
- there are no more false positives (mid-airs that don't actually over-write)
- changes to unrelated fields do not conflict
- changes to related fields are resolved "humanely" (if I added a dependency, and someone else removed another, those are not hard to reconcile)
-- shaver
Historical Queries
Ability to do historical queries on bug attributes ("what were all the bugs with blocking-firefox3.5+ on Friday?") so that people can stop scraping daily queries or trying to figure out the charting system.
Flexible Fields
No mandatory fields; all fields should be able to be multi-valued (this would let us solve the resolved-vs-fixed-keyword problem, as well as "vista and win7 but not win XP", and would let us have bugs in multiple components, multiple assignees for bugs, etc. -- we can argue about whether we want to permit that in different parts of our product as a matter of policy, but the mechanism should be there) -- shaver
Deprecation
Ability to orphan components/bugs/flags/etc. without a ton of noise. I should be able to make "fixed1.4.1" never show up in the keyword autocomplete without having to do a pile of bug-munging. -- shaver
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
- Bug 386600 - JavaScript autocomplete for review request field (patch, July 2007)
Multiple Statuses/Resolutions
I guess that finding out a better way to have "fixed here, but needs fixing somewhere else" would be cool, and support for that in queries. -- axel
Nicer Graphs
Nicer graphs would be good. -- dtownsend
Accounts
Hide from autocomplete
Relatedly, people should be able to hide their accounts from auto-completion or partial matching. -- shaver
Server
API
A full REST+JSON API, so that anything currently possible through the bugzilla web UI (read or write) can be done through another program on another server. -- shaver
Including chart data. -- dtownsend
Server-Side Hooks
Server-side hooks for basically every action, so that f.e. I could write something that did component watching the way I want without having to even discuss it with upstream, let alone make it sufficiently general to be accepted. -- shaver
Shorter Query URLs
Shorter query URLs by default. -- axel
Bounce Tracking
Bug 209181 will save lots of time when processing a lot of bugs and you need to know if reporter mail has not bounced. -- Nikolay Shopik
Speed
Parallelization
Support for parallelizing queries across multiple servers, since mining this data will become increasingly resource-intensive. -- shaver
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.
Configuration
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
Remove Platform and OS
Remove platform and OS, use keywords for them instead (until the multi-value thing is resolved above) -- shaver