Yeah, we need to nuke like 40 keywords.  Thanks for identifying an easy half
dozen or so.

For the evo-specific keywords, it'd be better to switch to using the status
whiteboard.  Keywords become useless if we have too many, and creating keywords
for small subsets of products and components is one of the common ways to get
way too many.

Basically, a keyword should be globally applicable _and_ regularly used in
queries (it seems that keywords often get added just for those that like to
categorize things in a certain way, but then no one actually uses them for
anything other than taking extra time to mark bugs appropriately), or it
shouldn't be a keyword.

In addition to the keywords you say should go away completely and the ones we've
previously discussed nuking even before the Evo bug import
(http://mail.gnome.org/archives/gnome-bugsquad/2005-January/msg00007.html and
http://mail.gnome.org/archives/gnome-bugsquad/2005-March/msg00009.html and
http://mail.gnome.org/archives/gnome-bugsquad/2005-March/msg00004.html), I think
we should also remove the following keywords:

evo-specific (use status whiteboard instead):
  addr_cal
  addr_mail
  cal_mail
  commands
  composer
  config
  connector
  eplugin
  filters
  folders
  groupwise
  HTML
  identities
  IMAP
  interop
  mbox
  migration
  MIME
  mostfreq (could just be deleted; we have special queries for this)
  NNTP
  packages
  POP
  S/MIME
  sendmail
  shortcuts
  SMTP
  vfolders

duplicate keywords
  API-doc (API)
  documentation (doc)
  easy_fix (gnome-love)
  RFE (feature)
  UI (usability/ui-review)

questionable
  blocking (only 4 uses; who actually queries on it?)
  build (relatively low uses, build are priority immediate anyway...)
  dogfood (who would query on this)
  feature (how is this different from severity=enhancement?)
  parity (only 9 uses; and who would actually query on it?)
  probabledup (who queries and checks for actual dups?)
  regression_test_needed (only 5 uses; doesn't seem like widespread need)
  theme (only 5 uses; who would query on it?)
  printing (wouldn't this mean the bug should be reassigned to gnome-print or
            some other product?)

Combined with the ones we should already possibly nuke (BLOCKED_BY_FREEZE,
HELPWANTED, PATCH, STACKTRACE (I don't think it's queried on), sun_patches (let
them use the status whiteboard like accessibility does), tracker (who queries
for tracker bugs--and who actually marks those bugs as such since we tend to use
TRACKER: in the summary?)), we could clean up the list by 40-50 bugs.  I'm not
saying we should nuke all these keywords (I'm sure someone will have a good
reason for at least a couple), but I think we should nuke almost all of them.

Another email regarding keywords:
http://lists.ximian.com/archives/public/evolution-hackers/2005-March/005322.html

For merging keywords, let me do that as it needs to be done in several places
(bugs_activity, bugs, keywords and keyworddefs).

Ping.. still want to know what keywords aren't needed.

How about I email d-d-l asking people to whine in this bug if they think any of
these are really important, and if we don't get any responses back then we nuke
all of the ones that Dan said should definitely go away as well as each and
every one from all three lists that I made?

Agreed with elijah's basic analysis. comments on the questionable ones (since
many are my fault :)

  blocking (only 4 uses; who actually queries on it?)
  build (relatively low uses, build are priority immediate anyway...)
  dogfood (who would query on this)

these three should definitely go away; any bug that has them would be 'urgent'
or 'immediate' in b.g.o. If there are any open bugs with these on them, just
mark them urgent and then we can ask the evo people to clean them up.

  feature (how is this different from severity=enhancement?)

It isn't; but remember that priority/severity were fucked in b.x.c. In the
transition, just mark them enhancement.

  parity (only 9 uses; and who would actually query on it?)

the answer to most of the 'who would query on it' was me, ettore, or jp. Nuke
this one.

  probabledup (who queries and checks for actual dups?)

The bug volunteers I had for evo, lo these many years ago.

  regression_test_needed (only 5 uses; doesn't seem like widespread need)

<sigh> It *should* be a widespread need- I'd love for this to become something
like please_write_ldtp_test or something like that, and once that project comes
up to speed, have people volunteer to track it. Though I suppose that could all
be done in the status whiteboard.

  theme (only 5 uses; who would query on it?)

Nuke it.

  printing (wouldn't this mean the bug should be reassigned to gnome-print or
            some other product?)

Depends. It was used to track cross-component bugs in evo's printing, so no, it
doesn't necessarily mean a gnome-print bug. I'd move it into the status
whiteboard as you've suggested with the others.

Also, should we consider namespacing the whiteboard bits to evo:foo?

Yeah, we should definitely namespace the whiteboard status stuff.  I also agree
that regression_test_needed could be a really cool keyword and would be a valid
one if someone was working on it, but no one is currently.  And I don't think we
should have it as a keyword until it is needed, unless someone is working hard
on making it become a need and they want the keyword to spur things on.

Personally, I'd keep the "build" keyword.
Anyways, tidying up the list recklessly is dearly needed. The vast amount of 
keywords ist just too scary; for my part looking up keywords is just too much of 
a hassle.
If we could limit to, say, 10-15, one would even be able to remember most.

Summing up, Elijah, go for it :)

Personally, I agree most (nearly all) of the evo-specific keywords need to be
nuked and the whiteboard be exploited better.
I do want the keyword tag information to be preserved by capturing it in the
whiteboard. Any ideas how this can be done better than 'pick-each-and-update' ?
By me, I am fine with Elija's nuke list above. 
Nagappan, are you okay with this ? Any exceptions requested from your team ?

Please don't nuke HELPWANTED, it is very useful to us.
I think easy_fix is still useful, even if it is sometimes abused.

Harish: Well there is the 'change all bugs at once' feature that may come in
handy, though a direct SQL update would be better since it avoids massive
amounts of bugzilla spam.  As Luis said, we'll try to namespace those things so
it'll enter the whiteboard in the form "evo:vfolders".  Is that okay, or would
you prefer something else like "evolution:vfolders"?

Bill: Adding the HELPWANTED keyword actually results in people coming to help? 
Well, that surprises me, but we can keep it.  Also, easy-fix was already renamed
to gnome-love before the evo bug import but then we got it back again (well,
with an underscore instead of a hyphen) after the import.  The current easy_fix
ones will be changed to gnome-love as well in an effort to prevent that abuse
(see also
http://mail.gnome.org/archives/desktop-devel-list/2005-March/msg00211.html).

Just reminding people that the easy way of deleting keywords (after the
turn-it-into-the-whiteboard SQL has been done) is the delete-keywords.pl file in
our CVS, which goes through all the hoops necessary to get rid of the things.

Why we keep track of keywords in 2 separate tables I don't know :)

>  probabledup (who queries and checks for actual dups?)

This is relatively new, since the Evolution Bugs import, and it would only be
used temporarily.  
I find it useful, especially if I dont have time to find the exact duplicate and
want to provide the reporter with a quick response.  
Others simply close bug reports without bothering to mark them as duplicates
because it is not worth the hassle.  This isn't terrible but I prefer having
this keyword and then cleaning things up properly.  

I'd also be happier if you kept the proper words where possible, feature rather
than RFE, usability rather than UI, et cetera.  

ok, since jpr told me to comment on this and finally put me into the cc list, i
cannot resist anymore to finally add my mustard to this (i like translating
german phrases word by word ;-)  ):

---probabledup---
i'm pretty used to search and also mark bugs as "probabledup". i use that when i
am *really* sure that i have already seen that request, and i do not use it when
i just think "hey, that's obvious, so probably somebody should have reported it
within the last five years". marking happens perhaps once a week, but i've been
triaging evo bugs for one and a half year now and *do* use this keyword. but
perhaps i'm the only one, so i wouldn't protest heavily if it would finally be
removed... :-)

---feature,RFE---
to me, this is covered by "enhancement". so please remove it.

---mostfreq---
covered by other bugzilla algorithms, so remove it.

---patch---
this was evo specific. we should make sure that all bugs with keyword "patch"
can definitely be found when searching for patches the "normal" way (attachments
that were marked as patches when uploading them). after that, we should remove it.

---printing---
please do NOT remove it, move it to the evo whiteboard. i remember that also
other people than me are really(TM) using it, e.g. guys at redhat iirc.

---evo-specific ones---
of course there can be a few evo-specific keywords removed, keywords with less
than ten open bugs or stuff like that (cannot check currently, because i am not
online when writing this here).
but please do NOT destroy meta data by removing stuff instead of putting it into
the evo whiteboard. it really wasn't fun and took quite some time to search for
bug reports to put the "printing" keyword on, when you have to look for "print"
and read through many stacktraces containing "printf". also other keywords like
"vfolders" or "filters" are definitely in use, and should be pretty much
complete so there shouldn't be many bugs dealing with that *without* that
keywords. it would be much more complicated to get an overview of that bug area
without those keywords.

---general---
of course it's necessary to reduce the amount of keywords dramatically, so
somebody filing a bug report does not need to read through tons of keywords to
finally give it up and to not use keywords at all when filing a new bug report.
we need a fair number of keywords to encourage bug reporters to take a look into
the keyword list and really *use* them when filing the bug!
i guess i shouldn't have to say sth about merging obviously ones, e.g.
"gnome-love" and "easy_fix" or "usability" and "UI". that's clear to everybody
and has been already mentioned.

my suggestion would be: first of all move all evo-specific keywords to the
whiteboard (hmm - i should get to know that, haven't used it so far since i'm
only triaging evo bugs), and nuke some of the remaining general keywords so
people filing bugs get encouraged to use keywords again. perhaps there should
also be another sentence in the bug report form to please use keywords.
after that, we should remove some of the evo whiteboard keywords.
i don't know if it's complex and takes a lot of time to move the keywords to the
whiteboard. if it isn't that easy as /me without any knowledge of the bugzilla
background currently assumes, then it would of course make sense to remove evo
keywords first and then move the remaining evo-specific ones to the whiteboard.
sigh...

my two cents for now,
thanks, andre

Okay, here's the summary of what it sounds like we (one of the bugmasters,
because this is probably better done with SQL access, and we can make use of
Andrew's script for part of it--Olav, any chance you could handle this?) need to
do with the keywords:

Leave alone:
  printing
  HELPWANTED

Special handling:
  RFE, feature (mark all such bugs as enhancement, then nuke the keywords)

Remove after making use of another keyword:
  API-doc (documentation)
  doc (documentation)
  easy_fix (gnome-love)
  UI (usability)

Move to the status whiteboard without evo namespacing (though I'd still like to
namespace them in some form, because I think all status whiteboard stuff should
be--suggestions?  We could hold off on these two until we have a better answer
if needed since it's just two in the list):
  probabledup
  regression_test_needed?

Nuke:
  beta_customer
  connector-beta
  customer-2
  NTS
  sales
  task
  mostfreq
  blocking
  dogfood
  build
  parity
  theme
  PATCH
  tracker

Move to status whiteboard in form "evolution:<word>"
  addr_cal
  addr_mail
  cal_mail
  commands
  composer
  config
  connector
  eplugin
  filters
  folders
  groupwise
  HTML
  identities
  IMAP
  interop
  mbox
  migration
  MIME
  NNTP
  packages
  POP
  S/MIME
  sendmail
  shortcuts
  SMTP
  vfolders

After this is done, there are probably a few others I'd like to bring up but
let's not worry about those until we have this list taken care of.

> Olav, any chance you could handle this

Fine. I assume we will do another announcement period before actually removing
these? e.g. p.g.o, d-d-l + top of the pages?

Sweet, thanks Olav!  I think we should announce on the appropriate evo list
since they are most affected.  If you also want to announce elsewhere that's
fine too, though I think the objecting period should be considered over (it's
too bad that decision announcements are sometimes treated as RFCs *cough*).

I was about to say that I thought we had addressed all objections, but it looks
like I forgot Christian's--and I think I realized why the build keyword could
actually be useful... Christian, is your reasoning for the build keyword to make
it easier for those having build problems to search for issues (closed or open)
with potential workarounds?  Before, I was thinking of it in terms of marking
with that keyword so that people could search for open problems and fix them,
which is somewhat of a different use case.  If I understand your use case now, I
have sympathy for that, though if we want it used that way someone should
probably make a big push (announce on gnome-love list, maybe d-d-l too, and
search for build issues periodically that others have filed and add the keyword
to them)

Olav, Elijah,

I suggest we commence the keyword removal in the near future.
I have seen newbies using deprecated keywords.

Do you want to ask the lists now for their last oppportunity to call a veto?

No, their last opportunity is long since past; the only point for announcing now
is so we don't get as many questions and everyone knows what the new
alternatives are where necessary.  It's just a matter of time right now.  I
don't have a whole lot of time to write the necessary scripts for some of this
right now, but I took care of the outright nuke list with Andrew's script.

Okay, I finally got around to making a little script that will change the usage
of one keyword in all bugs to a different keyword (substitute-keyword-usage.pl
in cvs now).  I used it followed by delete-keyword.pl to get rid of the four
duplicate keywords in the list.

That leaves the RFE and feature keywords, plus all keywords that need to be
moved into the status whiteboard.  I'll try to get to them while this info is
fresh on my mind, but no promises...  :)

Done, YAAAY!

I didn't handle probabledup or regression_test_needed, but I got the rest. 
(There's now a move-keyword-to-status-whiteboard.pl on the server which I ought
to check into CVS--also, someone with a clue needs to tell me whether I should
have locked the tables  ;-)  Anyway, let's mark this as fixed for now; we still
should make an effort to shorten the list more but it's much more
manageable--just take a look at http://bugzilla.gnome.org/describekeywords.cgi
and breathe a sigh of relief.

Wahoo!

the keywords are used in form "evolution[keyword]" actually, just for the
records and any later successors/evolution bug triagers.