Re: Proposal for a poll to users about bug triaging

[Jaroslaw Staniek]

On 28 February 2018 at 16:04, Ilmari Lauhakangas <
ilmari.lauhakan...@libreoffice.org> wrote:

> On 28.02.2018 16:21, Jaroslaw Staniek wrote:
>
>> My story is, more rules, more scared users ignore the BKO. A single thing
>> worth having is not too many rules but editing feature for *wrong* or
>> outdated bug comments that make understanding the report so hard. Many
>> years have passed since the first request and this feature still requires
>> physical SQL access to the database or so, not regular user skills :)
>> Consequence is that I avoid BKO for own reports and go for fully editable
>> Phabricator tasks.
>>
>
> Comment tags are a great way to keep the comment track clean:
> https://wiki.mozilla.org/BMO/comment_tagging
> Bugzilla admins can define tags that make the comment automatically
> hidden. Here are the tags that we use in LibreOffice:
> https://wiki.documentfoundation.org/QA/BugTriage#Comment_tags
>
> They can also act as useful pointers like "repro-steps" to highlight a
> useful comment.
>
> The next release of BZ will have comment editing:
> https://bugzilla.mozilla.org/show_bug.cgi?id=540#c207
>
> Note also the UX roadmaps:
> https://github.com/mozilla-bteam/bugzilla-ux/wiki/Bugzilla-6-Roadmap
> https://github.com/mozilla-bteam/bugzilla-ux/wiki/Bugzilla-7-Roadmap
>
>
​​Ilmari, these are wonderful news to me :)​


-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
KEXI:
: A visual database apps builder - http://calligra.org/kexi
  http://twitter.com/kexi_project https://facebook.com/kexi.project
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek

Re: Proposal for a poll to users about bug triaging

[Ilmari Lauhakangas]

On 28.02.2018 16:21, Jaroslaw Staniek wrote:
My story is, more rules, more scared users ignore the BKO. A single 
thing worth having is not too many rules but editing feature for *wrong* 
or outdated bug comments that make understanding the report so hard. 
Many years have passed since the first request and this feature still 
requires physical SQL access to the database or so, not regular user 
skills :)
Consequence is that I avoid BKO for own reports and go for fully 
editable Phabricator tasks.


Comment tags are a great way to keep the comment track clean: 
https://wiki.mozilla.org/BMO/comment_tagging
Bugzilla admins can define tags that make the comment automatically 
hidden. Here are the tags that we use in LibreOffice: 
https://wiki.documentfoundation.org/QA/BugTriage#Comment_tags


They can also act as useful pointers like "repro-steps" to highlight a 
useful comment.


The next release of BZ will have comment editing: 
https://bugzilla.mozilla.org/show_bug.cgi?id=540#c207


Note also the UX roadmaps:
https://github.com/mozilla-bteam/bugzilla-ux/wiki/Bugzilla-6-Roadmap
https://github.com/mozilla-bteam/bugzilla-ux/wiki/Bugzilla-7-Roadmap

Ilmari

Re: 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 
> 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=1



Best

Gilles Caulier

2018-02-28 12:35 GMT+01:00 Ilmari Lauhakangas

>>:

     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.

     

Re: Proposal for a poll to users about bug triaging

[Scott Harvey]

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.lauhakan...@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=1
>>
>> Best
>>
>> Gilles Caulier
>>
>> 2018-02-28 12:35 GMT+01:00 Ilmari Lauhakangas <
>> ilmari.lauhakan...@libreoffice.org > reoffice.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
>>
>>
>>

Re: Proposal for a poll to users about bug triaging

[Jaroslaw Staniek]

On 28 February 2018 at 12:35, Ilmari Lauhakangas <
ilmari.lauhakan...@libreoffice.org> wrote:

> 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
>

My story is, more rules, more scared users ignore the BKO. A single thing
worth having is not too many rules but editing feature for *wrong* or
outdated bug comments that make understanding the report so hard. Many
years have passed since the first request and this feature still requires
physical SQL access to the database or so, not regular user skills :)
Consequence is that I avoid BKO for own reports and go for fully editable
Phabricator tasks.

-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
KEXI:
: A visual database apps builder - http://calligra.org/kexi
  http://twitter.com/kexi_project https://facebook.com/kexi.project
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek

Re: Proposal for a poll to users about bug triaging

[Ilmari Lauhakangas]

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=1

Best

Gilles Caulier

2018-02-28 12:35 GMT+01:00 Ilmari Lauhakangas 
>:


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

Re: Proposal for a poll to users about bug triaging

[Gilles Caulier]

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=1

Best

Gilles Caulier

2018-02-28 12:35 GMT+01:00 Ilmari Lauhakangas <
ilmari.lauhakan...@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
>

Proposal for a poll to users about bug triaging

[Ilmari Lauhakangas]

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