On Fri, 12 May 2017 11:57:33 +0200
Alberto Salvia Novella <es204904...@gmail.com> wrote:

> Persons could have lot of experience, but the question is "would the 
> current guide allow most people to report bugs?"

This is a more difficult question to answer.

Let's try to define a few terms, first of all. I will be talking, here,
mostly about software.

* a BUG is a *defect*. It may be expressed in code, documentation,
  spelling, wrong output, whatever. But it is a *defect*.

Defects (or bugs) come in many forms. It may be as clear as a segfault
in a program, or as obscure as a wrong sentence in a manual (or
occasional, "magical" issues).

* a DEFECT is defined, in the Cambridge dictionary, as "something that
  is lacking or that is not exactly right in someone or something".

This is important, even being vague: "not exactly right" is as vague as
possible, but it passes the idea.

* a bug is EXPRESSED when we notice the defect. This does not mean the
  bug did not exist until being expressed. The bug *was* there for a
  while (at least), but we did not know about it.

* a bug REPORT is a *technical* description of the defect.

Notice that I stress "technical". Maintainers and developers will have
to read the bug reports, and zero in the issue. So, vague bugs reports
Are Not Good(TM). They waste our time. Usually maintainers/developers
will not waste time with a visibly vague bug report.

The above, I think, is pretty much what anyone would expect. Now...

* if there is no defect, then there is no bug.

This means that issues like "I do not know how to print a file" are
*NOT* bugs -- a priori. These are typical "customer support" questions.
"I do not know how to <fill in>" is NOT a bug. It is ignorance. It has
NO place in a bug control system. Now, it might happen that someone may
not know how to <whatever> because the manual is incomplete... THEN the
incomplete manual *IS* a bug.

* LP/bugs is a repository of *bugs*. It is NOT a repository of customer
  questions.

So, with the above in mind. 

We have been trying to move customers to open BUGS using ubuntu-bug and
similar. There is a reason for that: we were tired of having bugs with
NO useful data ("I cannot boot", as the description and title of the
bug, for example). This means that we *knowingly* made it more
difficult for a casual user to directly open a bug in LP.

There are many other venues -- which should be made clear in the wiki
-- that cater for casual user's issues (AskUbuntu, IRC, the Ubuntu Users
mailing list, and many, many others). IF an user, after passing thru
one (or more) of the user support offerings, ends up with a real bug...
then a LP/bugs entry is warranted.

BUT NOT BEFORE.
 
We do not want more people to open bugs. We want more people to open
*good* bugs reports. Reports that can be worked out by triagers,
maintainers, developers. This means the reports must be more on the
complete side. More on the technical side. Less on the "it did not
work". The triagers will complete the details. 

But I can guarantee you that a extremely vague bug will be left aside.
Which, BTW, I think is wrong: it should be closed INVALID (no actual
data provided).

> 
> And the second question is "would the proposed draft allow most
> people to report bugs?"

Yes, it will. And therein lies the danger. It is NOT easy to write an
usable bug report. Why should it be easy to write a bad one?

Cheers,

..C..

Attachment: pgpMgdfb2wJMg.pgp
Description: OpenPGP digital signature

-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Reply via email to