Proposal for a poll to users about bug triaging

[Ilmari Lauhakangas]

 From experience, priority & severity are nice-to-haves most of the 
time. In LibreOffice, they are the most useful in the case of crashes or 
hangs, where we use high/highest & major/critical.

Ilmari

On 28.02.2018 16:25, Scott Harvey wrote:
> 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 casualties.
> 
> 
> 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 
> <mailto: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.
> 
>     Ilmari
> 
>     On 28.02.2018 13:49, Gilles Caulier wrote:
> 
>         Hi,
> 
>         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 :
> 
>         https://bugs.kde.org/editcomponents.cgi?product=digikam&showbugcounts=1
>         <https://bugs.kde.org/editcomponents.cgi?product=digikam&showbugcounts=1>
> 
>         Best
> 
>         Gilles Caulier
> 
>         2018-02-28 12:35 GMT+01:00 Ilmari Lauhakangas
>         <ilmari.lauhakangas at libreoffice.org
>         <mailto:ilmari.lauhakangas at libreoffice.org>
>         <mailto:ilmari.lauhakangas at libreoffice.org
>         <mailto:ilmari.lauhakangas at libreoffice.org>>>:
> 
>              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
>              skills?"
> 
>              Ilmari
> 
> 
>