Proposal for a poll to users about bug triaging
bundito at gmail.com
Wed Feb 28 14:25:24 UTC 2018
As the former manager of an IT help desk (back in the olden days), my input
on some of this. I'm only a junior developer who's offered up a few minor
patches thus far and have done a bit of bug triaging.
We need to back up and remember the definition of the word triage:
(in medical use) the assignment of degrees of urgency to wounds or
> illnesses to decide the order of treatment of a large number of patients or
The former help desk manager in me says that's the key and that's what's
not happening - severity sorting. An ordinary user will be able to help
tell you if a bug can be reproduced, but it'll take someone more
experienced to set the priority. Twenty years ago, I was sorting help desk
tickets for Novell Groupwise and Windows 95. My staff of techs needed to be
told what takes priority. As in, if the company preident's secretary can't
access her email, head to the 6th floor immediately. That person with the
sticky spacebar can tough it out a bit longer.
Those of you who are high-level developers or maintainers are still going
to need to do this. An ordinary user who's "triaging" bugs can only tell
you if they can reproduce a specific problem. It's going to be up to the
gurus to shuffle things by priority. Someone like me, who's maybe more
experienced than some - at age 48 - can help out a bit and retry a problem
scenario, but I don't have the familiarity with the code, the frameworks,
not even C++, to tell you what's top priority and what's not. Sure, if
duplicating a bug brings down my whole system like the bug report says, I'm
going to get someone's attention. But in between that and a minor
annoyance... I can't decide that.
-Scott, graybeard wannabe junior developer
On Wed, Feb 28, 2018 at 7:54 AM, Ilmari Lauhakangas <
ilmari.lauhakangas at libreoffice.org> wrote:
> I would argue this is not the most important thing, at least not before
> recruiting a proper QA team for your application. It does help with
> noticing duplicate reports, but it is quite work-intensive. In LibreOffice
> we currently have 657 meta reports to categorise everything. Yet, we also
> have 20-30 active QA persons shuffling things around.
> Assigning correct components can very well be done gradually by
> increasingly educated and experienced non-developer QA contributors.
> Having a lot of components makes it obvious that the Bugzilla interface
> needs some tweaking, at least Advanced search. The component selection
> field in there feels cramped and its width does not even resize to show the
> longer component names.
> Red Hat has customised their BZ and added sub-components (so you have
> Product -> Component -> Sub-component). Their code is not yet public.
> I think when wanting to have a fine-grained categorisation, it would be
> better to have only a handful of components and then a lot of *optional*
> sub-components. Bug reporters not knowing what to pick could skip the
> sub-component step.
> I do not advise KDE to copy the LibreOffice model of meta reports. Meta
> reports don't live in the bug creation/search interface and are thus
> difficult to discover.
> On 28.02.2018 13:49, Gilles Caulier wrote:
>> Instead to start to talk with users about bugzilla, I recommend to
>> separate well the project with bugzilla sub-components.
>> In digiKam, i pass a lots of time to create sub-sections. This is the
>> most important task to do before triaging.
>> Remember that users are not developers. Some sections can be relevant of
>> some technical info from source code, so the developers must prepare the
>> sections before to delegate triaging to users. If users process a wrong
>> re-routage, this will be complex later to maintain a project.
>> See the sections created in bugzilla about digiKam project for example :
>> Gilles Caulier
>> 2018-02-28 12:35 GMT+01:00 Ilmari Lauhakangas <
>> ilmari.lauhakangas at libreoffice.org <mailto:ilmari.lauhakangas at lib
>> I am personally convinced that users do not know bug triaging is a
>> thing and certainly not how much they could help developers by doing
>> it. It would be very useful to test this by running a poll on
>> https://blogs.kde.org/ or somewhere.
>> Questions could be something along the lines of
>> "Did you know you can help KDE by analysing bug reports?"
>> "Did you know you can analyse most bug reports with regular user
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the kde-community