Closed Bug 167289 (uid) Opened 22 years ago Closed 22 years ago

Remove `User Interface Design' component

Categories

(bugzilla.mozilla.org :: Administration, task)

Product:
bugzilla.mozilla.org
Component:
Administration
Type:
task
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: mpt, Assigned: timeless)

References

(
URL
)

Details

(Keywords: helpwanted) 

Build: 2002083017, Mac OS 9.2.2

The `Browser' > `User Interface Design' component in Bugzilla is more confusing
than useful. Many (if not most) bugs initially filed in it really belong
elsewhere, it requires a default assignee (which is bad), there is no-one both
knowledgable enough and authoritative enough to be that default assignee, the
probability of such a person appearing in the medium term (and lasting more than
a couple of months) is approximately zero, and the component doesn't scale to
multiple applications.

There are a number of possible solutions to this problem.
1.  Show a confirmation alert whenever a bug is filed in, or moved to, the
    component. (`Placing a bug in the User Interface Design component may cause
    it to be WONTFIXed if it suggests a Silly Feature. Click "Cancel" to
    continue, or "OK" to cancel.')
2.  Add tabs to it.
3.  Put it in a group box all by itself.
4.  Make it a pref. (That way you can please everybody!)
5.  Remove it.

I suggest the most usable option is #5.
Where's the following solution?

6. All of the above

I don't see it. Do I have to edit prefs.js manually to
enable it? I suggest the summary be modified to include
enabling said solution in Mozilla's UI so that a full
range of options is available. Seems to be a logical
extension of the existing five solutions.
Severity: normal → enhancement
OS: Mac System 9.x → All
Hardware: Macintosh → All
+------------------------------------------------------------------------------+
| Bugzilla Preferences                                                      [X]|
+------------------------------------------------------------------------------+
|                                                                              |
| +--------------------+--------- User Interface Design Component -------------+
| | User Accounts      |                                                       |
| | Databases          | Show UI Design component                              |
| | Voting             |    (*) In the Browser product ( ) In all products     |
| | Query page layout  |    [ ] In a pop-up window                             |
| |*UI Design component|                                                       |
| | Advanced           | [X] Change default assignee automatically             |
| |                    |     ( ) Daily                                         |
| |                    |     (*) Weekly                                        |
| |                    |     ( ) After [___] new bugs                          |
| |                    |     ( ) Surprise me!                                  |
| |                    |                                                       |
| |                    |     ( ) Cycle through these default assignees:        |
| |                    |         [_________________________] (comma-separated) |
| |                    |     (*) Cycle through all active Bugzilla accounts    |
| |                    |                                                       |
| |                    | [X] Show confirmation dialog before filing a bug      |
| |                    |     [ ] Only if summary contains "pref"               |
| |                    |     [ ] Only on Mondays                               |
| |                    |     [ ] Only if it's been more than [___] hours since |
| |                    |         mpt's last blog entry                         |
| |                    |                                                       |
| |                    | When a bug in this component has been WONTFIXed,      |
| |                    |     [ ] Reopen it                                     |
| |                    |     [X] File a new one                                |
| |                    |     [ ] File two new ones                             |
| |                    |     [ ] Any of the above                              |
| |                    |                                                       |
| |                    | Do you want to play another game?                     |
| |                    |     [X] No                                            |
| |                    |                                                       |
| +--------------------+-------------------------------------------------------|
|                                                                              |
|                                                     [ OK ] [ Cancel ] [Help] |
+------------------------------------------------------------------------------+
sounds like a fine idea to me. but component's can't just be removed. first they
have to be cleared of all their bugs. that means moving bugs to other components.
Allowing components to be disabled is coming up on the bugzilla agenda fairly soon..
All of the bugs *should* be reassigned, to the components where the issue
exists, so they can be triaged and resolved appropriately.
asa: i'll start sorting bugs out of UID, can you change the component to:
name: "needs new component"
description: "please do not file bugs here"
That could help decrease the number of new bugs that land in the component.

This is task number 5 for me in mozilla.org:components, so it may take me a week
to finish sorting.
Status: NEW → ASSIGNED
I'd be happy to help if someone can answer three dumb questions for me:

There is currently 1440 bugs in UID. I don't suppose there's a way to move 'em
to different components without creating enormous amounts of spam?

Would it be appropriate to add a comment when changing the component, or should
that be avoided to reduce spam?

Would it be appropriate to reassign the bugs to the default owner of their new
components, or should that be avoided to reduce spam?
i'd say that 
* if the current owner is neither marlon nor mpt and the owner appears to have
done something with the bug => only change qa.
* otherwise reassign.

as for spam, there are two approaches
1. be bloody detailed so that people can write filters to pick up the change and
ignore it
2. be transparent. (I use '.')

since these bugs are generally not dead (oh, that's another category), i'd prefer 2.

for bugs that have a status (i.e. not '---'), we need to avoid reassigning.
for bugs that are only resolved, we need to pick up new qa contacts in an effort
to get them verified.
it's probably best to use approach 1, i'd probably use something like: 
We're deleting the "User Interface Design" compontent, see bug 167289 for details.

This allows people to filter either positively or negatively for it (ideally qa
types will filter positively and people who don't like spam will filter negatively).

I suspect this will be done one bug at a time, mass changes tend to suck.  It's
probably best to coordinate triaging by ranges of numbered blocks (on irc).

Let's start by moving the unresolved bugs as the resolved bugs.
To summarize what I *think* you meant:

*** Open bugs ***
Change QA contact.
Reassign if current owner is mpt or marlon or current owner doesn't look like
he/she is up to fixing the bug.
Use approach 2.

*** Resolved bugs ***
Change QA contact.
Don't reassign.
Use approach 1.

*** Verified bugs ***
Don't change QA contact.
Don't reassign.
Use approach 2.

Is that correct?

Oh, and:

> Let's start by moving the unresolved bugs as the resolved bugs.

I *so* don't understand that sentence.
yes, and whoops
> Let's start by moving the unresolved bugs as the resolved bugs.
wow, i really messed that up... oh well, how about this:
Let's just start by moving the unresolved bugs.
Alias: uid
We're not going to move bugs "behind the scenes" to avoid the spam. We need the
record of what happened in the activity log. 
Make it easy for people to search and delete from their bugmail folders with
unique string in the comment. Make the changes quickly and as tightly grouped as
possible. Mass changes can help but you'll have to do several of them because of
limitations of the interface.
update: it's almost done (6 weeks behind schedule?) -- there are 13 bugs left.
I encountered two problems:
1st: it took 75mins for my mass change (bug 178153 filed)
2nd: i can't see the last 13 bugs, so i can't move them.

asa/dveditz/lchiang/sairuh/trudelle: can you please help me out here? they need
to be moved or declassified. (I don't even know what the classification is,
although I can guess).
Assignee: asa → timeless
URL: http://bugzilla.mozilla.org/buglist.c...
Status: ASSIGNED → NEW
Keywords: helpwanted
My search of the component shows 13 old (low-numbered) resolved bugs in the
"Netscape confidential" group. Most of them had Netscape-specific summaries (My
Netscape this, Netscape icon that) from the days before Bugscape.

About half of them have a February 2000 comment "Moving all UE/UI bugs to new
component: User Interface: Design Feedback UE/UI component will be deleted."  I
guess we could just move 'em all again.


Delete component of Browser
 
Part Value
Component: User Interface Design
Component description: This component is going away. Do not file or move bugs to
this component. File your UI issues on the appropriate code component.
Initial owner: mpt@myrealbox.com
Initial QA contact: zach@zachlipton.com
Component of product: Browser
Bugs none
Confirmation

Do you really want to delete this component?
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
verified component gone
(was using a component dropdown list of a bug to verify)
Status: RESOLVED → VERIFIED
Component: Bugzilla: Keywords & Components → Administration
Product: mozilla.org → bugzilla.mozilla.org
You need to log in before you can comment on or make changes to this bug.