Features for the new bugzilla?
philip.rodrigues at chch.ox.ac.uk
Fri Sep 8 20:37:40 BST 2006
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 see most bugs which should be closed as 'notabug' or 'wontfix', judging
> from comment being closed with normal status 'fixed'. App-maintainers
> don't care, bugreporters don't care.
This is kind of why I opened this thread - I can think of 1001 different
things that would be "nice to have" in bugzilla, but if app maintainers
wouldn't find them useful or would just ignore them, then they're probably
At the same time, there *are* changes that will result in a better
experience for users of bugzilla (reporters, developers, triagers), and so
we should discuss them and decide which ones are worth the cost in extra
> 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.
> If any changes have to be made; I'd say it has to be in the direction of
Were you thinking of anything in particular that could be made simpler?
KDE Documentation Team: http://i18n.kde.org/doc
KDE Documentation Online: http://docs.kde.org
More information about the kde-core-devel