An invalidated bug. Should it have really been invalidated?

[C de-Avillez]

On Sun, 11 Aug 2013 06:13:09 +0100
Phil Wyett <one.ukit at gmail.com> wrote:

> I have read the whole document now after not reading it for a few
> years. It seems many changes and caveats have been introduced and now
> we have many flaws in the whole bug reporting process. What should be
> a simple process for new/inexperienced users (not me as a dev), has
> actually turned into a spiders web of iffy software and processes to
> perform the overall task with the addition of many 'do nots'
> introduced by contributors.

Well. Let's keep in mind that bug reports are *technical* reports. On
commercial systems, an end-user opens an incident, help-desk/L1-support
looks at it and then -- if needed -- upgrades the incident to a bug
(and involves L2/L3, as needed).

(my personal view is that end-users [1] should never directly open a
bug.)

For any of us working with the developer/maintainer hat, it is a waste
of time to look at conflated/confused/incomplete/incoherent LP bugs. We
end up spending a LOT more time on one single "bug"... and this causes
a series of other (perhaps better-written, perhaps more critical) bugs
to be left aside.

So, yes, bugs processes have gotten more complex. But this is not an
unneeded complexity, I hope (of course, as time goes by chaos creeps
in, and we should review the processes every so often).

The crux here, to my understanding, is that end-users -- to say,
non-expert, casual, users -- should NOT open a bug by hand.

(for example, there is one LP user that insists in manually opening
his/her bugs, always against 'Ubuntu'. I gave up asking to use
'ubuntu-bug', and I now leave all his/her new bugs aside. Also, most of
her/his bugs are actually user issues, not package/code bugs.)

Specifically for hardware-related bugs, the rules of thumb are: if you
are not a developer/expert, (1) open a new bug; (2) use
'ubuntu-bug' to open the bug; (3) at most add a link to the existing
bug you think may be related; (4) do NOT comment on other bugs.

> 
> Is there anyway the bug squad can hold a review in conjunction with
> the quality people and look at the whole process once more? As one
> example to why. If the whole notion of one bug per person per
> hardware combo and no posting to others reports is the way to go. We
> should really be using the duplication method on launchpad and the "
> This bug affects 'x' people. Does this bug affect you? Edit" with
> this affecting bug heat is essentially redundant.

We really should review the whole triage process every so often; if any
of us think there is room for improvement, then, by all means,
propose/justify it. This is a *group* process.

And, by that, I also mean that my opinion is just that -- an opinion.
The objective is to better triage bugs, not to cater to inflated
opinions of anybody, myself included.

Thank you for starting the process :-)

..C.. 


[1] by "end-users" I am refering to any and all non-subject-expert
users.

-- 
ab alio expectes alteri quod feceris