Bugreporting barrier is too low with the new Dr. Konqi

[Darío Andrés]

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)
* 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..)

Regards

Darío A.

2009/11/9 Darío Andrés <andresbajotierra at gmail.com>:
> I will work on a patch to disable DrKonqi reporting from the server
> (rejecting the automated reports and asking the user to report
> manually), to implement at least for KDE 4.3 reports.
> Hopefully the situation on 4.4 will be improved.
>
> Regards
>