Bugreporting barrier is too low with the new Dr. Konqi

[Christophe Giboudeaux]

Hi,

On Tuesday 10 November 2009 02:53:04 Darío Andrés wrote:
> Another idea I got in order to reduce the noise to developers:
> 
> DrKonqi automatic reports should be filled under a (new) bugzilla
> product named "unassigned" (or something like that), with a null mail
> address (or may be a ML of bug triagers....) and with a special state
> (it may be NEEDSINFO/WAITINGFORAPPROVAL, or something like that).
> 
> Pros:
> * Developers will not get direct mails about untriaged (and possible
> duplicates) reports. Developers will only be involved with this kind
> of report if they would like to and/or have free time.
> * Triagers can look at this bug reports, and check their validity. If
> the reports are unique or if they contain unique information they are
> going to move them to the proper bugzilla product/assignee/status.
> * The DrKonqi mappings file will be deprecated as all the reports are
> going to be in only one product. This way I can't forget about this
> file or checking if some new application should be added..
> * We are gaining a pre-filter "system" for bug reports and
> information, without requiring a third server/application/database.
> * We don't need that much man power as we would need if we introduced
> a new tool/mechanism (to train people and to implement new methods,
> and/or to move information between the two systems)
> 
> Cons:
> * Bug reports should be reassigned to its product manually (this
> shouldn't be a real problem, most of the binary names has a similar
> bugzilla product, and triagers should already know the combinations)
> * I have been suggested that this may end up being as messy as the
> kmail-triage ML was (kmail reports being assigned to a triaging
> mailing address, so triagers would check and reassign the reports if
> they are valid)

Sorry but this was already experimented with the KMail reports and we had to 
stop the experiment.

How did it work:
- All the KMail bugs were assigned to the bugsquad-triage mailing list,
- After review/triage by the bugsquad, the reports were reassigned to the real 
email address.

The result after a few monthes:
- There were many bugs still assigned to the triage list for various reasons 
(lack of backtrace/feedback, unable to reproduce, lack of manpower to handle 
all the reports).
- The kdepim devs were not immediately aware of regressions in released 
versions (since most of the triage team was using a trunk build).


> * People may complain (I'm used to it..)
> 
> - Do you consider this could be an improvement? (I'm open to discussion)
> (Sorry about the noise, but the impossibility of fixing the mess I
> somehow created is frustrating me a lot..)
> 

No, instead of having the bug reports assigned to the correct person/list, you 
will have a growing 'untriaged' product.
The only benefit for the application maintainer will be that he receives less 
mail. That is not a valid reason.

Suggestions to save time when triaging:
1/ Use your favorite RSS reader. You may add a feed for almost every query.

I use 18 feeds to triage the 
akregator/kmail/korganizer/kontact/akonadi/kdepimlibs reports. For each 
product I have 3 feeds: wishes/normal/crash

and I get a new entry when a new bug is created/reopened/reassigned

2/ Use the aliases for recurrent reports. Instead of looking for bug 191589 
every time this crash is reported, I just write 'KIO::Slave::deref' in the dup 
number box, et voila.

Some BKO suggestions:
- Make it possible to disable the wish reports for a given product.
- Do not notify the assignee whether a wish report didn't get enough votes
- Disable reporting for older KDE versions (How many maintainers are really 
interested in KDE 3 or KDE < 4.3 reports ?)


Christophe.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20091110/bb953cc9/attachment.sig>
-------------- next part --------------
_______________________________________________
Bugsquad mailing list
Bugsquad-RoXCvvDuEio at public.gmane.org
https://mail.kde.org/mailman/listinfo/bugsquad