MozillaWiki

BugzillaImprovements

Revision as of 10:52, 15 June 2009 by Gerv (talk | contribs)

This is the collected input about changes community members would like to make to bugzilla.mozilla.org (June 2009).

Code

UI

Simpler Layout

Collapse all the non-required 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

  • Bug: none.

No default UI changes

I [am not suggesting we require] 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

  • Bug: none.

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

  • Bug 107306 - Smart midair collision handling with line-item overrides.
  • Bug 69447 - Make CC changes not cause midairs.
  • Bug 395970 - mid-air collision pages cry wolf.

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.

  • There is a WONTFIXed bug, but I can't find it right now.

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

Bug: none.

Multiple Statuses/Resolutions (Per Branch)

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 (endorsed by bsmedberg)

  • Bug 55970 - Bugzilla needs to deal better with branches.

(I get the impression the requirements for this are complex! -- gerv)

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

  • Bug 456743 - Add the ability to disable field values (mark them as inactive). Being worked on by ghendricks.

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; endorsed by Ron K)

  • Bug 386600 - JavaScript autocomplete for review request field (patch, July 2007)

Nicer Graphs

Nicer graphs would be good. -- dtownsend

Bug: too many to list. ;-)

Remove Severity Field

The "blocker" and "enhancement" severities actually mean something to us currently, but everything inbetween is basically "a bug of some sort" without much actionable difference. I think we should instead have a "blocking trunk" flag which we use to mark bugs which should close the mozilla-central tree, and an enhancement keyword to mark enhancement bugs. -- bsmedberg.

The Bugzilla project definitely uses this field -- mkanat.

Remove Platform/Hardware and OS

Remove platform and OS, use keywords for them instead (until the multi-value thing is resolved above) -- shaver (endorsed by bsmedberg)

According to the Bugzilla Survey (which will be published in the next few days, once I finish compiling all the data and writing it up), the single *most* common problem is that the op_sys or platform fields aren't applicable to what the users are doing with Bugzilla. -- mkanat.

  • Bug 449161 - op_sys and platform should be custom fields with an extension for auto-selecting.
  • Bug 160572 - You should be able to turn off URL, Platform, OS, Version fields in Bugzilla.

Another option is to remove them from the bug filing process, and have them default to All/All (or, better, new values: Unspecified/Unspecified - idea from Rich Gray).

Make More Field Visibilities Configurable Per Product

Would it be crazy to propose being able to vary the presence and default state of all the fields on a per-product basis? -- zw.


Accounts

Hide from Autocomplete

Relatedly, people should be able to hide their accounts from auto-completion or partial matching. -- shaver

  • Bug: none.

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

  • A JSON API already exists; need to assess completeness and level of documentation. "Bugzilla 3.6 will have a JSON-RPC API that duplicates the XML-RPC API." -- mkanat.

Access-Control-Allow-Origin header support for cross-site XML-RPC - asutherland.

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

  • Already implemented in Bugzilla 3.4.

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

  • Bug 209181 - Bounce on bug reporter email should be noted.

Charts

  • Make it possible to extract chart data without a login. -- dtownsend.
  • 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:

  • Bug 97956 - Give summary and URL of bugs added or removed from dependencies in bugmail (notification mail).
  • Bug 125888 - Give summary/URL of bugs marked as duplicates.


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. 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.


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!) 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


Bugs

  • Can't put an alias in a bookmarkable template.
Retrieved from "https://wiki.allizom.org/index.php?title=BugzillaImprovements&oldid=149209"