Re: [Ubuntu-bugcontrol] I have written a draft for the Reporting Bugs guide

[C de-Avillez]

On Sun, 28 May 2017 16:54:45 +0200
Alberto Salvia Novella  wrote:

> About:
> (https://help.ubuntu.com/community/ReportingBugs)
> (https://wiki.ubuntu.com/es20490446e/Reporting%20bugs)

OK, let's get thru the proposed page.

I will be copying text from the proposed Reporting Bugs so that I can
comment. The version I am using is #32, timestamped 2017-05-27 22:38:52.

Text copied will have the usual "> " we see on replies (well, at least
*I* see on my text emails. I do not know what/how it is shown on
HTML/richText).

* 1. Etiquette

> If you care about an Ubuntu release not having bugs, test the daily
>  image five months before launch. So developers have time to fix it.

Why 5 months before? Our release cycle is *still* 6 months. If we test
an image 5 months before release, we will be testing pre-alpha code.

* how are people -- non-technical people -- going to test it?
  Something that is, 5 months before release, pre-alpha?
* should they only test the code as is 5 months before release?

> If writing more doesn't make a tangible difference, write less.

We need context. If fact, the sentence above is a good example of why
writing *less* does not always help.

> If you have any doubt, you can ask any time.

I absolutely agree. 100%. All for it. Always.

But...

My issue here is the word "ask", above, is a link to mailing to the
ubuntu-quality ML. Nothing else. But the ubuntu-quality mailing list is
NOT the only resource available for people in doubt. There are also:

* IRC
* The Ubuntu fora (https://ubuntuforums.org)
* AskUbuntu (https://askubuntu.com/)
* the answers section on Launchpad (https://answers.launchpad.net/)
* the ubuntu-users mailing list
* the Ubuntu documentation (https://help.ubuntu.com/)
* and MANY other mailing lists.

To limit to ONE source for answers really does not help. At all. And it
is not even the most important source for bugs/issues/support.

2. Not Bugs

> Reporting misspells

But a misspell *is* a bug. Why wouldn't a mispell be reported?

3. Reporting windowed aplications

> In the Terminal application enter:
> 
> ubuntu-bug -w

Ah, OK. And then this ubuntu-bug thingie will magically find the bug I
want to report, right? Oh, it will not? what should I do then?

4. Reporting non windowed applications

> 1. Using the Synaptic application and the list of common packages,
> determine which software package is the most likely to be affected.

But synaptic is no longer installed by default. How is a casual user
going to *know* that, and how would this casual user get synaptic
installed? Are there other options? What are they?

5. Reporting unusable systems

Now we have, as far as I am concerned, a real issue. As I have already
stated, we do not simply need more bugs, we need *good*, *workable*,
bugs. Our experience with free bug entry was horrible. many of the bugs
entered were unworkable. This was why the free bug entry was removed
from view. 

-x-x-x-x-x-x-x-x-

This is one reason of why reporting bugs is so complicated. It is not
*easy* to report a bug. Keep in mind that a bug report is a *technical*
report of a software defect.

If one does not know what a bug is (hint: a bug is a defect in a
program/package), why should one be able to enter *anything* as a bug?

If one does not know if the bad experience just had is, or is not, a
bug, then one would be better served by going to the community support
areas I pointed above. If necessary, after being helped by somebody else
in the community -- and if determined to be a bug -- then a bug may be
opened. But know, at least, we have a good chance of knowing the correct
package name, and  other important details to be reported.

Cheers,

..C..






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

Re: [Ubuntu-bugcontrol] I have written a draft for the Reporting Bugs guide

[Fabio Marconi]

Hi Alby
What ..C.. just say to you shown the great admiration he has for U.
We all thanks U for your effort in this community, and pls, keep his replies as 
 suggestions to be a better man.
Thank U, Alby.
Thank U, ..C..


Inviato da BlueMail
Il giorno 28 mag 2017, alle ore 17:27, C de-Avillez 
> ha scritto:

On Sun, 28 May 2017 16:54:45 +0200
Alberto Salvia Novella  wrote:

NB: I have not yet *read* the new proposal. I am just discussing the
approach here.

 About:
 (https://help.ubuntu.com/community/ReportingBugs)
 (https://wiki.ubuntu.com/es20490446e/Reporting%20bugs)

 Sorry, but I'm absolutely convinced that the latest draft I've
 written is really what's needed.

Alberto, during this thread you were asked why would you want to have a
discussion of the changes in private conversations. You stated
something suggesting "I can then submit something more complete [to be
discussed by the community].

Now you come back absolutely convinced whatever you did (keep in mind I
did not read it yet, I am just discussing form and approach) is THE
ANSWER.

I do not know if it is or not. But I can say you are approaching it in
a less than ideal way.

 The sections clearly reflect every use case, and they are organised
 in a logical way. The writing style is conversational and easy to
 understand.

 The content is exactly what the user is looking for, and adding
 something else won't ease their job nor change their behaviour. If
 there's something useful to somebody else, it should go somewhere
 else.

Just a question: and what it is we -- the community of bug
triagers/solvers/developers are looking for? Are our requirements
fulfilled? Remember, there are *always* [at least] two sides involved.

You "exactly what the user is looking for". Great. What is it we --
maintainers/developers  -- are looking for? Are our requirements/needs
addressed?

 The imagery suggests the page is easygoing, softens it, and makes it
 more memorable. There's nothing impolite about it, neither gives the
 wrong image of Ubuntu.

 The community isn't targeted to super professionals but to all kinds
 of people, many of which are student in their teens.

 So either you take it as it is, or you leave what you have. I will
 wait till Sunday the 4th, to let you decide yourselves. I will take
 that resolution as hard fact on what to expect in the future.

The above sounds like "either you pay me the ransom, or I will kill the
hostages." A perfect example of ultimatum.

 I'm looking forward to work only with people who are in complete
 sympathy and harmony with my purpose, which is "easy and
 straightforward over correct".

This is the wrong approach. This is the absolutely WRONG approach.

What you are saying here is equivalent to "I am looking forward to
work only with people that /think like I think/."

This will not happen. This will *never* happen. Everybody has a
(perhaps just slightly) different approach/view/way of
coping/interest/whatever.

Even more importantly, if I am surrounded only with people that think
like I think, all I have is reinforcing of my own bias and prejudices.

Yes, there will also be reinforcing of the *good* ideas, but there is
no way to KNOW if they are good or not, since nobody in the group will
have a different view.

 Thank you.

and thank you.

..C..



Mailing list: https://launchpad.net/~ubuntu-bugcontrol
Post to : ubuntu-bugcont...@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-bugcontrol
More help   : https://help.launchpad.net/ListHelp
-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Re: [Ubuntu-bugcontrol] I have written a draft for the Reporting Bugs guide

[Vej]

Hello Alberto,

I really like the idea of a shorter manual for Bug Triaging, because the 
current one was hard to follow as a newbie. But I really dislike the way how 
you try to press others in accepting it as it is without modifications when 
writing this:

Am 28.05.2017 um 16:54 schrieb Alberto Salvia Novella:
> So either you take it as it is, or you leave what you have. I will wait till 
> Sunday the 4th, to let you decide yourselves. I will take that resolution as 
> hard fact on what to expect in the future.
This is not a good way to communicate with a team of volunteers. It also goes 
against the Ubuntu Code of Conduct [1]. So please sit back take a breath, drop 
that "everything or nothing"-approach and open yourself for discussion how to 
realize a clear manual without loosing details that some of us might need for 
their work (think about the Kernel Team as one example). I feel this is the 
only way your great goal of an easier manual might become reality.

Best Regards

Vej



[1] "Our work will be used by other people, and we in turn will depend on the 
work of others. Any decision we take will affect users and colleagues, and we 
should consider them when making decisions." (Cited from the
"Ubuntu Code of Conduct v2.0"

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