[Bugsquad] Bugreporting barrier is too low with the new Dr. Konqi

[Darío Andrés]

Re-sending because the mail subject got changed and it missed the
original thread

2009/11/12 Darío Andrés <andresbajotierra at gmail.com>:
> 2009/11/11 Darío Andrés <andresbajotierra at gmail.com>:
>> On Tue, Nov 10, 2009 at 6:23 AM, FiNeX <finex at finex.org> wrote:
>>> In data martedì 10 novembre 2009 02:53:04, Darío Andrés ha scritto:
>>>> Another idea I got in order to reduce the noise to developers:
>>>> [...]
>>>
>>> I like the idea: usually when I have some time for triaging bugs I pick up the
>>> latest N bug reported and I read them all. Usually bugs reported from drkonqui
>>> are dups or "NEEDSINFO". Anyway they are mostly filled under the right
>>> product. Why not set a flag "automatically submitted" so developers can filter
>>> them out and triagers can filter them in?
>>>
>>> Something like "waiting for human check" ?
>>>
>>
>> May be I start liking this idea. Creating the bug report under the
>> corresponding product but with a special status
>> NEEDSINFO/WAITINGFORAPPROVAL or a special keyword would allow:
>> - Developers will get notified about them, but they should be able to
>> ignore them if they like to. (just exclude such reports from your
>> query searches, and ignore your mails if they have "Reported using
>> DrKonqi")
>> - Reports will be under the right product from the start (I will look
>> forward implementing the online mapping feature)
>> - Open bug reports count will not increase until the triagers confirm
>> that they are valid issues (pre-filter system)
>> - Having a keyword or a special state makes searching for the
>> untriaged bugs a lot easier too.
>>
>> + Improving duplicate handling in DrKonqi itself
>>
>> All the discussions about changing bugtracking system are a bit beyond
>> me so I won't suggest anything yet...
>> BTW, thanks to all for the feedback about the current system, it is
>> greatly appreciated and I will look forward improving the situation.
>>
>> @FiNeX: this discussion comes from kde-core-devel, so be sure to send
>> your replies to that list too so everyone can see them.
>>
>
> Mh, it seems that bugzilla won't accept entering bugs with a closed
> state. We could implement a patch or use a keyword instead (something
> like "automatic_unverified_report"). What do you think ? Devs can
> ignore reports with that keyword in their queries, too bad we can't
> fix the statistics :-\ (or may be we can fix them, patching them)
>
> I have been also wondering if we could implement a remote agnostic
> interface, so DrKonqi will be able to communicate with bugs.kde.org
> system regardless of the bugtracking system (useful if we ever migrate
> to another system, and to write a better implementation to retrieve
> the bugs' data  (parsing HTTP after POST/GET HTTP requests is ~nasty~
> (current way)).
> With a custom (and own) interface we could provide a stable remote API
> for DrKonqi even for stable (not trunk) KDE versions (bugzilla xmlrpc
> is unstable API, we can't rely on it, bugzilla upgrades will break
> it).
>
>> Cheers
>> Darío A.
>>
>