Granularity

[Myk Melez]

Gervase Markham wrote:

> Are you talking about flag types here? Where is the demonstrated need 
> for component-level specificity?

There are (at least) two:

The "mozilla.org" product, "CVS Account Requests" component requires 
users to vouch for other users requesting CVS access.  A "vouch" flag 
type would work well in this situation, but only if it can be restricted 
to that component.

Some Mozilla modules, like the JS Engine, no longer require 
super-review, so components in Bugzilla specific to those modules 
shouldn't display the "super-review" flag.

> This particular specificity is causing problems (see the bug I cited 
> earlier.)

Not at all.  There's no reason why flags should have to be confirmed. 
 The current system, which works just like the system it replaced 
(attachment statuses), works fine: either the flag type exists in the 
new product/component combination, in which case the flag remains on the 
bug, or it doesn't, in which case the flag gets deleted.

Nothing more complicated needs to be implemented, particularly not an 
additional confirmation screen, since 1. repeatedly requesting 
confirmation from the user is frustratingly bad UI design (we should be 
getting rid of our current confirmation screen, with JS if necessary, 
not adding to it); 2. it's obvious a user wants consistent bug data when 
moving a bug to a new product/component; 3. and the likelihood of a user 
canceling a move because flags would be deleted is incredibly minimal.

Good UI design should assume users intend to do what they ask to do and 
what they do most of the time, while providing a way for users to undo 
their action in the rare case when the UI guesses wrong, which is what 
the current system provides.

> Indeed. My proposal was not to eliminate global parameters :-) It was 
> more to suggest that we make "per-product" and "global" the only two 
> valid values for a specificity.

And I am (once again) dismayed at the Bugzilla community's proclivity to 
establish rules for Bugzilla development whose significant effect will 
be to make it unnecessarily less flexible.

-myk