Closed Bug 63239 Opened 24 years ago Closed 23 years ago

Remove `softui' keyword

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: bugzilla, Assigned: asa)

Details

The `softui' keyword should be removed.

Reasons:

* Only used in 11 bugs.
* Limited, highly specific description that isn't likely to apply to a large 
number of bugs (as keywords should).
adding matty@box.net.au and mpt@mailandnews.com who seem to be the primary users.

It looks like this keyword has a pretty small scope.  Do you think that there is
a good reason for it being a keyword rather than a status whiteboard flag.  I'm
looking at keywords as flags that should be meaningful to a large group of
people and require a consistent syntax and a published definition. 
Keywords were implemented to replace status whiteboard, description flags,
tracking bugs and all the other hacky solutions.  If someone wants a keyword,
leave it alone.

How many bugs have that keyword is irrelevant.

If you think there's too many keywords, put some sort of effort into improving
Bugzilla rather than trying to fix the symptoms.
What?  So any time anyone asks for a keyword, it should be added, no questions 
asked?  No, I'd say that's a very, very bad idea.  Do you know how many 
keywords we would have, then?

Keywords were indeed intended to alleviate the need to put inappropriate 
[PHRASES] and such in the status whiteboard and summary.  But they were also 
intended to represent a large class of related bugs that members of the 
community often need or want to track.  They were *not* intended to be added on 
a whim and used by 1-2 people in a couple of bugs, or they serve no useful 
purpose (if you want to track 5 bugs, and there's no other demand for such a 
keyword, write them on a post-it note).

> How many bugs have that keyword is irrelevant.

How do you figure?  Some of the keywords aren't on any bugs.  What useful 
purpose do they serve?  Keywords, as I said, are meant to track a significant 
amount of bugs that are related in a specific way (but don't necessarily fall 
under the same component).

> If you think there's too many keywords, put some sort of effort into improving
> Bugzilla rather than trying to fix the symptoms.

I don't understand this either.  In what way does Bugzilla need to be improved 
to reduce the number of keywords?  Yes, I am attacking the symptoms of the root 
problem (many keywords were added at the request of one person, but were never 
or hardly used); when I'm done, I intend on designing some keyword guidelines, 
and a process by which keywords can be nominated.

Please explain your reasoning for why anyone should be able to add any keyword 
they want, regardless of how many bugs will actually use it.
Keywords are diffent from status whiteboard comments in one big way.  They are
meant to be useful to a larger audience.
If the flag is only used to one person and doesn't need to be used by or
understood by others then it doesn't need the things that a keyword can offer
like only being able to enter it spelled correctly and having a public
definition.  These things are specifically built into keywords to make them
useful to a group of people.

Some people have talked about a future where in your prefs you can see the
entire list of keywords and mark only the ones you care about so that all others
are hidden from view in the keyword list, in the show_bug.cgi and bugmail would
not be sent for keywords you didn't care about (or something like that).  I'm
not sure this solves all our problems but it might solve some.  But we don't
have that functionality yet so I'm working to make the list we do have more
meaningful and more useful.

Is there some other functionality a keyword provides that a status whiteboard
comment doesn't that I'm missing here? 
I don't use this keyword. It could be replaced by a meta bug assigned to 
Matthew Tuck.
> What?  So any time anyone asks for a keyword, it should be added, no questions 
> asked?  No, I'd say that's a very, very bad idea.  Do you know how many 
> keywords we would have, then?

I never said what I felt about that either way.  In the original keywords bug
#11155 Terry and I felt that keywords should only be able to be created through
channels.  Hixie was a dissenting opinion.  My main rationale was that we'd find
a whole boat load of duplicate and otherwise redundant keywords, and going
through leger or whoever would prevent this.

At the time if I had ever thought we were going to be faced with a group of
people who wanted to avoid using keywords for useful purposes I would have
written off keywords as a bad idea - I don't want yet another system.  But
nowadays I think that Hixie was right.  We should treat keywords the same way as
bugs - that it's better to have a dupe and fix it than possibly not have it at
all.

> But they were also intended to represent a large class of related bugs that
> members of the community often need or want to track.  They were *not*
> intended to be added on a whim and used by 1-2 people in a couple of bugs

Whoa!  Where's the justification for this statement?  To my knowledge you were
not involved with the introduction of the keywords system at all.  If there was
some private chat somewhere then OK, but you definitely said nothing in the RFE
bugs.  Keywords were introduced to eradicate cross-feature tracking bugs and
whiteboard/description flags.  Totally.  To consolidate three different systems
into one, not introduce a fourth to further confuse the issue.

> or they serve no useful 
> purpose (if you want to track 5 bugs, and there's no other demand for such a 
> keyword, write them on a post-it note).

I don't particularly see what "serve no useful purpose" has to do with the
number of bugs.  Please enlighten me.

> How do you figure?  Some of the keywords aren't on any bugs.  What useful 
> purpose do they serve? 

Sorry, I left out what I thought to be obvious.  Clearly, obsoleted or unused
keywords should be removed.  A keyword that permanently has < 2 bugs on it
shouldn't be a keyword.  But that's not the case here.

> I don't understand this either.  In what way does Bugzilla need to be improved
> to reduce the number of keywords?

This is what I mean by attacking the symptoms.  There are _lots_ of things that
could be done to make keywords scale.  I will follow up with a list, but I need
time to prepare it, including filing a few bugs.  The keyword system is pretty
busted.

> Please explain your reasoning for why anyone should be able to add any keyword 
> they want, regardless of how many bugs will actually use it.

Keywords are intended to replace all other systems.  Hence, it is not up to me
to say why there is no r'ship between keyword benefit and number of bugs, it is
up to you to say that there is.

But allow me to agree that there is a r'ship between keyword benefit and number
of bugs.  Keywords with a lower number of bugs are of more benefit because they
introduce clutter onto less bugs.

I would agree that there is a r'ship between keyword benefit and number of
keyword users, but disagree that we need to eradicate those with lower ratio.

> Keywords are diffent from status whiteboard comments in one big way.  They are
> meant to be useful to a larger audience.

No they aren't, this is just something you made up to try and satisfy your
practical concerns.  Keywords are for all designations that aren't logically
satisfied by other features (eg components), and the status whiteboard is for
the status in English text.  Unfortunately the latter has turned into a dumping
ground for pretty much anything that doesn't fit elsewhere like keywords and
scheduling information.

> If the flag is only used to one person and doesn't need to be used by or
> understood by others then it doesn't need the things that a keyword can offer
> like only being able to enter it spelled correctly and having a public
> definition.  These things are specifically built into keywords to make them
> useful to a group of people.

I partially agree.  Long term, I would like to see private keywords and such,
but within the current system I would never allow private keywords given that
folders of bookmarks work almost as well.  Same for private tracking bugs.

I never created softui to be my private keyword, far from it.  I had a definite
need to combat a brigade of "just let the user hack the XUL" people, who I
wanted to show softui features to.  This need has diminished partially and we're
seeing more softui features being implemented, but it hasn't gone away.  So
maybe I'll decide the keyword is unneeded at some point in the future, but I
haven't yet.

> mark only the ones you care about so that all others
> are hidden from view in the keyword list, in the show_bug.cgi and bugmail
> would not be sent for keywords you didn't care about (or something like
> that). I'm not sure this solves all our problems but it might solve some.

No it doesn't solve all problems, but this is one of the solutions.  There are
plenty of others though.  I hadn't thought of preventing them appearing on the
bug form, and I'm not entirely sure about that, but we will definitely want to
allow notifications to only be sent about certain keywords.

> But we don't
> have that functionality yet so I'm working to make the list we do have more
> meaningful and more useful.

I agree.  So please leave the useful keywords alone.  I'll agree in earnest with
any effort to clean up obsolete, redundant or otherwise unused keywords, just
like I would with bugs.  But once the effort strays into removing useful
keywords, I can't agree, in the same way as I wouldn't agree with resolving bugs
that so-and-so thought were useful but not useful enough to be cluttering up
people's bug lists.

> Is there some other functionality a keyword provides that a status whiteboard
> comment doesn't that I'm missing here?

It doesn't clutter where it shouldn't.
It's easier to search.
You don't get misspellings and stuff causing bugs to drop off a search.
It was designed for this purpose, and hence makes logical sense, whereas the
other systems don't.

> It could be replaced by a meta bug assigned to Matthew Tuck.

It will be no such thing.  It was originally a tracking bug that I disposed of,
and I'm not going back to that world.  I will sooner see it be deleted and have
people know they're interfering with my optimal use of the system.
matty finds this keyword useful.  won'tfix.


>It's easier to search.
How is it easier to search?
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WONTFIX
mark verified won't fix.
Status: RESOLVED → VERIFIED
reopenign for further consideration.
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
Just kill it then.  I'm sick of worrying about the keyword nazis.
fixed
Status: REOPENED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED
vrfy fixed
Status: RESOLVED → VERIFIED
QA Contact: lchiang → timeless
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.