Features for the new bugzilla?

Frank Osterfeld frank.osterfeld at gmx.de
Fri Sep 8 19:34:56 BST 2006

On Friday 08 September 2006 18:56, Thomas Zander wrote:
> On Friday 8 September 2006 18:22, Thiago Macieira wrote:
> > >I second that, keywords would be especially useful for
> > > "cross-sectional" issues like usability, accessbility or
> > > internationalization. Basically everywhere where assigning to a
> > > single component is not enough.
> >
> > And since we're on it, I'd like to see the Version: item split in two:
> >
> > Version found
> > Version fixed (or target to be fixed)
> This, together with various other extentions proposed in this thread mean
> more work and more complexity for the app-maintainers.

I don't think that's true for the keyword feature. Adding a keyword manually 
or selecting one from a list isn't more work than adding "[i18n]" to the 
title. And if the UI is good, listing tagged items would be much more 
convenient than changing the query to search title for [i18n] in it.

> Elsewhere on this thread a request was made to make bugzilla more friendly
> for reporters. Adding more data on screen and adding more status fields
> has the opposite effect.

Most of the suggested features wouldn't be presented to the user when entering 
a bug. Neither bug status nor keywords will be set by the reporter. 
The status fields should cover the most common cases, so rarely used 
resolutions like LATER and REMIND (around 400-500 reports each) could be 
merged or removed completely (there seems not a single bug report with MOVED 
status, whatever it should be used for). NEEDINFO is very common and 
different from INVALID, so adding it would make sense.

> If any changes have to be made; I'd say it has to be in the direction of
> simplicity.

Simplicity is a worthwile goal, indeed. The reporting process is much too 
tedious, I would probably rarely report a bug if I was a user without access 
to enter_bug.cgi. OTOH, some apps have hundreds or even more than thousand 
bug reports. There we need powerful and quick ways to manage these reports, 
to group them, find duplicates etc.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060908/f9321fbf/attachment.sig>

More information about the kde-core-devel mailing list