DrKonqi improvement idea

[David Jarvie]

On Mon, March 12, 2012 10:36 am, Thomas Zander wrote:
> On Sunday 11 March 2012 11.26.53 Niko Sams wrote:
>> I'd like to talk about an idea on how DrKonqi
> []
>> What software could crashes.kde.org run? I'm not sure, maybe abugzilla
>> installation or somethingcustom written. Or some other bugtracking
>> software.
>
> I'd say this is a great idea, mostly because it means a lot more can
> be automated on lots of ends.

I like this idea too.

> I'd also make your webpage (or site) be mostly dumb in the handling of
> the data its being sent and then have a continues job on the machine
> to actually process and handle these crash reports.  So if we get
> loads of requests in, we just store the data to be processed when
> there is CPU available.
> The reason is that I think we get much more useful information out of
> this if we allow it to take more time than a webrequest would allow.
> And also this will make the site much more responsive and painless.
> It just scales better ;)

There would be an advantage in giving instant feedback to the user if
possible, but if that turns out to be impractical, Thomas's suggestion of
using background processing on the server could be sensible.


I think Niko's proposal points to a deficiency in the current bug
reporting system, in that the current system doesn't provide a facility to
present the user with a quick summary of actions to take to resolve/work
around the bug. True, it does have the 'version fixed in' field for bugs
which are fixed, but there's nowhere that the developer can enter
workarounds etc. without them being lost in the bug discussion.

I'd suggest an extra text field called 'User action summary' at the top of
the bug report, under 'version fixed in'. Its purpose would be to give a
brief summary of how to avoid the bug (upgrade to version x.y.z / any
workarounds / etc.) or what is required from users to investigate it (e.g.
a summary of information needed). Reference could be made in the summary
to individual comments in the bug report. The user action summary should
only be editable by the assignee, to prevent users taking it upon
themselves to enter mistaken information.

This field could serve two purposes:

1) It would enable users to see at a glance what the status of the bug is,
even in a bug report containing long winded discussion or lots of
duplicate reports.

2) It could be used when crash reporting, to provide the user-intelligible
feedback which Niko is proposing. In this case, of course, there would
need to be a link between any crashes.kde.org and bugs.kde.org.

-- 
David Jarvie.
KDE developer.
KAlarm author - http://www.astrojar.org.uk/kalarm