BugzillaImprovements
Code
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
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
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
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
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
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
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
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