After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 61507 - Bell settings are confusing
Bell settings are confusing
Status: RESOLVED FIXED
Product: gnome-control-center
Classification: Core
Component: Keyboard
1.5.x
Other Linux
: High minor
: ---
Assigned To: Control-Center Maintainers
Control-Center Maintainers
Depends on:
Blocks:
 
 
Reported: 2001-10-01 18:52 UTC by Seth Nickell
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Seth Nickell 2001-10-01 18:52:31 UTC
The bell settings under keyboard should be in sound, or at least better
explained (it took us a while to figure out what the heck that tab was
for). Better yet, the bell tab should be removed altogether or moved into
the cracklets section of the control center.
Comment 1 Joakim Ziegler 2001-10-01 19:43:18 UTC
Setting priority to Enhancement.
Comment 2 Seth Nickell 2001-10-01 19:53:41 UTC
You are of course free to use bugzilla as you see fit (re: marking
this as an enhancement), but the usability project currently has this
marked this a critical or blocking change for the release of GNOME2.
Comment 3 Luis Villa 2001-10-04 01:23:49 UTC
seth: a suggestion from someone who does a /lot/ of triage: throwing
around words like 'critical' and 'blocking' without very carefully
considering what you are saying is counterproductive, especially for a
'leading from behind' project like the UI project, which provides no
resources for fixing of the problems that they identify.

Note: I'm not passing judgement on this particular bug; just pointing
out that it would be very wise to use blocker, etc. as sparingly as
possible. 

Two other long term suggestions: 
(1) use a keyword like 'usability_blocker' or some such to identify
and track every thing you feel are blockers; this way as we get closer
to a 2.0 release you can go back through and find the ones that you
feel are important but have been neglected or re-triaged by
developers, and perhaps raise the issue again.
(2) this may be more of an issue for gnome-hackers, but the reason
that there are both priority and severity fields is to differentiate
between 'silly' enhancements (say, 'make gnomecc do my coffee') and
things that are important/urgent but still technically enhancements.
I'm resetting this to High, mainly as a demonstration of how I think
this should work.
And a third, again [and this one is speaking purely personally, not as
a Ximian employee] I can't stress enough that without providing
resources, the gnome-ui stuff occupies a very, very backseat driver
role, with limited capital. It is in your best interests to focus
those resources and capital only on the most important of issues, and
as those issues are resolved, and people begin to say 'hey, these UI
guys have some really good ideas', /then/ move on to other things that
may be 'blocker' but generally appear less important to the average
hacker.

Good luck... GNOME needs you guys, probably worse than it realizes-
Luis 
Comment 4 Luis Villa 2002-01-24 17:12:06 UTC
Heh... setting this to minor :) Priority still High; Seth, we should
probably sit down and talk briefly (perhaps with gnome2release team as
well) about how prioritization for usability issues will be handled.
Comment 5 Luis Villa 2002-01-24 18:35:19 UTC
Just doing some tagging of files I've already triaged. Filter on 'luis doing
GNOME2 work' to get rid of the spam.
Comment 6 Seth Nickell 2002-03-01 03:11:07 UTC
The explanation in the new keyboard capplet isn't great, but its
adequate that this isn't a serious problem. Marking fixed.