canmove, Confirmed users
637
edits
BugzillaImprovements: Difference between revisions
→Make More Field Visibilities Configurable Per Product
(→UI) |
|||
| (28 intermediate revisions by 4 users not shown) | |||
| 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 7: | Line 7: | ||
== UI == | == UI == | ||
=== Simpler Layout === | === Simpler Bug 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 | 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 | ||
| Line 14: | Line 14: | ||
* Note that we are unlikely to add a user preference for this, but we might remember the shown/hidden state in a cookie. -mkanat | * Note that we are unlikely to add a user preference for this, but we might remember the shown/hidden state in a cookie. -mkanat | ||
Another option would be to have some of the key fields, plus the Commit button, as position:fixed at the top of the Window. This means that the general status of the bug is always visible, even if you visited a #comment-id link. And your muscle memory always knows where Commit is, as well. -- gerv | |||
=== Text Area Visible On Filing === | === Text Area Visible On Filing === | ||
| Line 24: | Line 20: | ||
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 | 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 | ||
* Essentially fixed in Bugzilla 3.4, because the bug entry page is simpler by default. | * Essentially fixed in Bugzilla 3.4, because the bug entry page is simpler by default. -- mkanat | ||
** Not if your screen is 1024x768 -- gerv. | |||
*** I see part of the Description field above the fold at that resolution, even including an extra toolbar from a plugin in my browser. That's enough that it can be clicked on. -mkanat | |||
=== Fix Mid-Air Collisions === | === Fix Mid-Air Collisions === | ||
| Line 38: | Line 36: | ||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=395970 Bug 395970] - mid-air collision pages cry wolf. | * [https://bugzilla.mozilla.org/show_bug.cgi?id=395970 Bug 395970] - mid-air collision pages cry wolf. | ||
* Note that this is somewhat difficult and unlikely to happen in any near-term Bugzilla release. -mkanat | * Note that this is somewhat difficult and unlikely to happen in any near-term Bugzilla release. -- mkanat | ||
** mkanat: can you point me at any technical analysis which has been done on the problem? -- gerv | |||
*** No, but I have a general idea of how it would be implemented, in my mind, if you want to talk about it. I think we should probably be looking at having a Bugzilla::ChangeSet object first (which we need for other things, also) -mkanat | |||
=== Historical Queries === | === Historical Queries === | ||
| Line 46: | Line 46: | ||
* There is a WONTFIXed bug, but I can't find it right now. | * There is a WONTFIXed bug, but I can't find it right now. | ||
* I think it would be better to just have charting system that can be understood and used by mere mortals. Also a charting system that can go back in time (perhaps a product separate from Bugzilla itself--some already exist). -mkanat | * I think it would be better to just have charting system that can be understood and used by mere mortals. Also a charting system that can go back in time (perhaps a product separate from Bugzilla itself--some already exist). -mkanat | ||
* the ability to ''share'' charts would help. Right now the datasets for the "new" charts are either set up by an admin, or personal and not shareable. Even though the data sets are not shareable they still bloat the drop-down. Charts don't help with historical data, unless you thought to set up the charts ''before'' you wanted the answer -- useless. But maybe if someone else has already asked the question you have a chance of using their data. I (dveditz) would like two changes: | |||
** Let me share my data sets the way I can share my named queries. | |||
** When I'm making a chart I only want to choose from the datasets you'll give me the data for, don't confuse me with the rest and then fail silently when I choose them. | |||
=== Flexible Fields === | === Flexible Fields === | ||
| Line 58: | Line 61: | ||
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) | 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) | ||
* There is an existing custom feature on b.m.o., but it is considered inadequate. (any solution that results in 118 "fixed" keywords and an equal number "verified" keywords is horrible, not to mention the stack of "blocking" flags cluttering up each bug.) | |||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=bz-branch Bug 55970] - Bugzilla needs to deal better with branches. | * [https://bugzilla.mozilla.org/show_bug.cgi?id=bz-branch Bug 55970] - Bugzilla needs to deal better with branches. | ||
* Despite the WONTFIX I still prefer the simpler [https://bugzilla.mozilla.org/show_bug.cgi?id=336790 Bug 336790] --dveditz | |||
** Of course, as extensively explained in that bug, while that might serve Mozilla's requirements, it would not serve the general requirements of all Bugzilla installations, and it also would not be very flexible once you wanted more and more things per-branch, or if you wanted to say things like "this is the same bug in two different products". -mkanat | |||
(I get the impression the requirements for this are complex! -- gerv) | (I get the impression the requirements for this are complex! -- gerv) | ||
| Line 84: | Line 90: | ||
Bug: too many to list. ;-) | Bug: too many to list. ;-) | ||
Repeating my (dveditz) earlier comment in the "historical data" section, the "new" charts need | |||
* the ability to make datasets public or shared with specific groups (like named queries). I mean user-created datasets, there do seem to be a few public ones I assume created by admins. | |||
* don't show 100's of datasets that the user isn't allowed to use. The clutter hides the ones I'm looking for, the interesting-looking names are a tease, and it's just overall frustrating. Just show me my own datasets, the public ones, and the ones that have been shared with me. | |||
** this one is [https://bugzilla.mozilla.org/show_bug.cgi?id=389396 bug 389396] | |||
=== Remove Severity Field === | === 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 "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. | |||
The Bugzilla project definitely uses this field -- mkanat. | * We should still split "enhancement" from "defects" rather than lumping them in the same severity field. In particular the current scheme means we cannot assign "severity" (importance?) to an enhancement, which can range from a minor polish thing to major new functionality. --dveditz | ||
** {{bug|9412}} | |||
=== Remove Platform/Hardware and OS === | === Remove Platform/Hardware and OS === | ||
| Line 110: | Line 122: | ||
No, it wouldn't, but it would require a fair bit of re-working that we're in-progress on, in terms of architecture, in Bugzilla. -mkanat | No, it wouldn't, but it would require a fair bit of re-working that we're in-progress on, in terms of architecture, in Bugzilla. -mkanat | ||
The ''presence'' of a field could be easily customized in each site's local CSS if we had a few tweaks to the bug layout: | |||
* each item must have an id. A lot of 'em do, but some the field itself has an id but its label does not, making it hard to style them as a group (e.g. target milestone and many others). | |||
* The body should have a product class in addition to the existing component class, that is "bz_product_Core" alongside "bz_component_JavaScript_Engine" <br>(dveditz) | |||
===Integrate Comments Into Bug History=== | ===Integrate Comments Into Bug History=== | ||
If I'm reading a bug report for the first time, and trying to familiarize myself with what has happened on the bug so far, it's hard to know what actions in the bug comments correspond with what action in the bug history (renaming, changing component, change of status, etc.). If you could incorporate bug history and bug comments[1], it would make it much easier to put the bug history and comments into context. -- Chris Ilias. (zomg +1 -- beltzner) | If I'm reading a bug report for the first time, and trying to familiarize myself with what has happened on the bug so far, it's hard to know what actions in the bug comments correspond with what action in the bug history (renaming, changing component, change of status, etc.). If you could incorporate bug history and bug comments[1], it would make it much easier to put the bug history and comments into context. -- Chris Ilias. (zomg +1 -- beltzner) (+1 -- dveditz, can't tell you the amount of time I spend on the history page trying to match state changes to explanatory comments) | ||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=11368 Bug 11368] - Move all bug activity onto main bug screen. | * [https://bugzilla.mozilla.org/show_bug.cgi?id=11368 Bug 11368] - Move all bug activity onto main bug screen. | ||
| Line 141: | Line 157: | ||
There have been several calls for greater linkage between Bugzilla and Hg, although there are different views about the appropriate extent of the scope, and the UI, for such linkage. The problem they are attempting to solve is easily finding the appropriate checkins for the bug. | There have been several calls for greater linkage between Bugzilla and Hg, although there are different views about the appropriate extent of the scope, and the UI, for such linkage. The problem they are attempting to solve is easily finding the appropriate checkins for the bug. | ||
===Editable Description/Summarization=== | |||
Sometimes it takes a while to hone in on what a bug really is, with several of the initial comments being overbroad or over-vague. Sometimes a bug is "mostly" fixed but left open, but you have to find comment 87 to figure out what the bug is still open for. It would be nice if a bug could be resummarized, and if it is the new summary would appear above the initial comment 0. Creating and editing this field would be restricted to the editbugs group, and if one is added it might have to be somewhat visually set off from the stream of comments starting with #c0. --dveditz | |||
A specific Bugzilla feature for this appears to be WONTFIX because supposedly there's enough support for this as a customization. [https://bugzilla.mozilla.org/show_bug.cgi?id=99240#c6 bug 99240]: | |||
::Since Bugzilla 3.1.2, you can create a custom textarea and then paste the bug description in it. We won't implement a specific "long summary" field as you are free to create one yourself when you need it. | |||
I'm not sure who the "you" is there, it certainly doesn't seem to be me. The same concept was also requested in [https://bugzilla.mozilla.org/show_bug.cgi?id=262087 bug 262087] | |||
== Accounts == | == Accounts == | ||
| Line 169: | Line 194: | ||
* 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. | * 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. | ||
Note that in order for this to be REST, Bugzilla has to move to Catalyst, a far-reaching rearchitecture that is in the Bugzilla 4.0 or 4.0+ timeframe. JSON-RPC will exist in Bugzilla 3.6, though. | Note that in order for this to be REST, Bugzilla has to move to Catalyst, a far-reaching rearchitecture that is in the Bugzilla 4.0 or 4.0+ timeframe. JSON-RPC will exist in Bugzilla 3.6, though. -- mkanat | ||
Access-Control-Allow-Origin header support for cross-site XML-RPC - asutherland. | Access-Control-Allow-Origin header support for cross-site XML-RPC - asutherland. | ||
* for public (no cookies) data only, I hope --dveditz | |||
=== Bounce Tracking === | === Bounce Tracking === | ||
| Line 197: | Line 211: | ||
* Support for GROUP BY equivalent. -- dveditz (endorsed by axel). | * Support for GROUP BY equivalent. -- dveditz (endorsed by axel). | ||
** I think what Axel wanted was just a way of getting the tabular data in a programmatic format, which we can already do (CSV). -mkanat | ** I think what Axel wanted was just a way of getting the tabular data in a programmatic format, which we can already do (CSV). -mkanat | ||
*** Yes, this is neat. Looked at reports and didn't understand the UI before, but now I get it. Including this into a JSON API would be nice for consistency. -Axel | |||
*** Yeah, that's what I wanted. Could do with support for grouping by flag/requests/requestee (and "fixed-in" if ever BMO gets to use that) but otherwise covers what I was thinking of. | |||
===Search=== | ===Search=== | ||
| Line 264: | Line 280: | ||
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. | |||
** This wouldn't work, because sometimes I want to request review from somebody who's not a reviewer--say, somebody who can tell me whether or not their problem is fixed, or some expert in some area that I'm working on, and if their flags defaulted to off, then I couldn't ask them. -mkanat | |||
* 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. | ||
* Add Core to the pretty picker {{bug|384603}} | |||
= Already Implemented = | |||
=== 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 | |||
* These already exist: http://www.bugzilla.org/docs/tip/en/html/api/Bugzilla/Hook.html -- more can be added as requested; hooks are only added that have use cases. Some rearchitecture is required before we can add hooks to performance-critical areas. (Can't find the bug, right now.) -mkanat | |||
=== Shorter Query URLs === | |||
Shorter query URLs by default. -- axel | |||
* Already implemented in Bugzilla 3.4. | |||
** meanwhile BMO users can use [https://www.squarefree.com/bookmarklets/mozilla.html#shorten_bug_query a bookmarklet] (admittedly an inconvenient extra step) | |||