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.
Frank
-------------- 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