Re: [Evolution-hackers] bugzilla keyword changes.

[Luis Villa <luis villa gmail com>]

Very fair point. Olav, what did you do with the current keywords? Just
import them as-is, dump them, or what?

FWIW, thanks (I believe) to Andrew Sobala, we have some scripts set up
at b.g.o so deleting keywords cleanly is easy- it might be easier to
do the import, then delete, than to do it in b.x.c.

Luis


On Thu, 31 Mar 2005 23:41:30 +0200, Andre Klapper <ak-47 gmx net> wrote:
> n'evening,
> 
> moving from bugzilla.ximian.com to bugzilla.gnome.org could be a nice
> opportunity to think about the keywords that currently exist in ximian's
> bugzilla.
> 
> at the moment, we have 79 keywords.
> i cannot condemn people submitting new bug reports to not read the list
> of keywords in order to add some of them, if it takes me five minutes to
> read through all of them (and that's the current state).
> 
> keywords i'd like to see dropped if they aren't used by other
> ximian/novell products are (i don't know anything about these):
> beta1 (0 bugs open),
> beta2 (1 bug open),
> beta3 (0 bugs open),
> contest (0 bugs open),
> costumer-1, costumer-2,
> EPR (4 bugs open),
> gcc3(0 bugs open),
> Hotlist (0 bugs open),
> lint (0 bugs open),
> new_upstream (only Ximian Desktop 2: 1 bug open),
> no_test_needed (only Mono: 1 bug open),
> notstone (0 bugs open),
> purify (0 bugs open),
> rc_ui (only red carpet: 4 bugs open),
> release_note (currently 1 bug open),
> should_go_upstream (mostly Ximian Desktop 2: 5 bugs open),
> torelease (1 bug open).
> 
> this would at least shorten the list a bit.
> 
> some existing keywords are nice, but just aren't used (that's why i
> would also drop them), namely:
> incoming (10 bugs open),
> outgoing (7 bugs open),
> lookandfeel (4 bugs open, isn't this nearly the same as UI? - ok, could
> be UI department only...)
> 
> ...but i like and want to keep the "identities" keyword for example,
> though there are only a few bugs open with that keyword - the idea
> behind the keyword is good. and we have also only 3 open bugs with
> "smime" keyword, but it also does make sense.
> 
> i also vote for two new keywords:
> 
> "spam", which would include everything that has to do with spam, junk,
> bulk or spamassassin (these are the words i have to use in bugzilla to
> search for them at the moment). these are at least 28 bugs.
> 
> "menuitems" (perhaps this would be the same as the current keyword
> "commands" - if one at least drops the "missing commands/functions" in
> the current summary of "commands" this would also work out): all issues
> that have to do with "i miss that function in the main/context menu" or
> any menu inconsistencies (about 50 bugs currently).
> dobey: you've got that list of bugs already, perhaps it would make the
> menu rewrite a bit easier if there is a keyword to search through the
> bug reports dealing with it.
> 
> i'd personally also love to see other keywords which wouldn't make sense
> (because there are too few bugs dealing with it), for example
> "label" (not in the sense of accessibility, but "important/work/to
> do/private/later"). it's just hard to find them at the moment because
> the term "label" is also used for the description of input fields, or
> "colours" for the issues dealing with colouring emails.
> to make it short: it sucks that some words are also used in other
> contexts - ever searched the bug database for "print" because the
> printing keyword did not work and half of the bugs include a "printf"
> from a stacktrace and have nothing to do with printing? you get what i
> mean.
> 
> i wonder which category keyboard shortcuts (about 20 bugs currently) are
> part of: accessibility? keynav?
> does key navigation mean the same as "working and getting along without
> a mouse" or does it mean "making my daily work easier by providing
> shortcuts"? then how is "accessibility" defined?!
> "accessibility" and "keynav" should be better differentiated, it's the
> same with "RFE" and "feature" which is a very marginal difference and
> can be also expressed by the "wishlist" priority/severity.
> 
> also, i'd vote for using the keyword "eplugin" not only for wishlist
> bugs that could be solved by coding an eplugin (that's the current state
> according to the keyword summary), but also for real bugs referring to
> existing eplugins. this can be easily distinguished by the
> priority/severity ("wishlist" vs anything else).
> 
> ...and i really like the thought of dropping the UI component, since its
> use by bug reporters just doesn't make sense so the existing keyword
> "UI" would be the way to go (hopefully i'm quoting jpr correctly here).
> 
> comments are welcome. :-)
> 
> cheers,
> andre
> 
> --
>  mailto:ak-47 gmx net | failed!
>  http://www.iomc.de
> 
> 
>