[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: The number of unassigned bugs is worrisome
From:       Dirk Stoecker <kde () dstoecker ! de>
Date:       2006-01-13 11:02:14
Message-ID: Pine.LNX.4.63.0601131146360.1578 () dirkwork ! site
[Download RAW message or body]

On Thu, 12 Jan 2006, Thiago Macieira wrote:

> David Jarvie wrote:
> >In light of this, in the meantime people should take the status of many
> > bugs with a pinch of salt.
> 
> This "meantime" means "until we clean up the database, bug by bug".
> 
> Take a look at the list of Konqueror's bugs. As I said, I'd bet a great 
> portion is no longer valid and is forgotten, by the developers and the 
> users who reported it. Another good portion has been fixed as khtml 
> improved and will continue to be fixed.

Let me note about this:
In April I filed this bug report: 
https://bugs.kde.org/show_bug.cgi?id=104259

It is easy to reproduce and also has been reproduced by others and 
has been rereported. It is still UNCONFIRMED.

For me this reads a following: No developer ever had a look at this 
report. As making good bug-reports is really lots of work you discourage 
bug reporters to report bugs, because:

a) You need a login for reporting bugs
b) For a good report you need to describe reproducable procedure. This 
   means multiple testings and good description.

Doing lot's of work and nobody having a look at it --> There will be no 
second bug report. This results in a loss of good reports. You will get 
only the bad fast reports, which do not help at all. I do lots of 
development and bug reports for more than 15 years now and recently also 
bug-fixing in KDE. I really know both sides. A good bug reports means 1 
hour to fix a bug. A bad one means days of work.

The bug-report guideline I usually follow (not yet for KDE):
1) UNCONFIRMED bugs should be tested fast (really fast, no intensive 
   testing). If confirmed, set confirmed.
2) If not confirmable, ask for more information. After a timeout (e.g. 2 
   weeks) without additional information set to CLOSED/INVALID.

A state NEEDINFO would be good after step 1, as exists in other bug 
trackers.

This means after a short time every bug either gets confirmed or is 
closed. The users are much happier if they know the bug is recogniced. 
Ignoring their work discourages them.

Every developer doing one or more randomly choosen bug report in his 
projects per KDE-working day...

Ciao
-- 
http://www.dstoecker.de/ (PGP key available)
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]