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
Attachment:
signature.asc
Description: This is a digitally signed message part