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

[Alberto Salvia Novella]

On one hand we have meritocracies, like GNOME, where some people have 
the final saying about what things are going to be.


On the other we have democracies, like Debian, where all the decisions 
shall be agreed before taken on.


The first one has the drawback of usually ignoring individual needs, and 
favoring some people's agendas over the others. The second one usually 
ends in long discussions, some clueless people included in brain 
surgery, and eventually in very little job done.


What I'm proposing is that we take an hybrid approach. That we come and 
agree in what the output of the work should be, and what's important for 
everyone. But that we trust that the person in charge of that will come 
with a solution themselves.


Once the work is done we can simply see if it fits the agreed output 
well enough to start with. And if it doesn't to correct it till it does.


After that we can polish the small details with real world feedback. We 
can provide a link to ask to the Quality mailing list, and if someone 
seems to have recurring trouble with something in the manual, just 
correct it immediately.



Have third opinions if you wish:

- Steve Jobs, founder of Apple:
  (https://youtu.be/f60dheI4ARg)

- Richard Branson, founder of Virgin:
  (https://youtu.be/VH35Iz9veM0?t=3m2s)

- 37 Signals, creators of Ruby on Rails:
  (https://goo.gl/q5K1Iv)

- Robert Kiyosaki, rich and author of the bestseller "Rich Dad Poor Dad"
  (https://youtu.be/xyY5YMV2woU)



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

[flocculant]

On 31/05/17 01:43, C de-Avillez wrote:

...

I will simply keep those as short as possible. And instead of making
a monologue, with all the information, I would simulate an actual
conversation. Usually with 10-20 seconds answers.

(https://youtu.be/L45EqUl2q4M)

I will not listen to it. If you can *talk* your points, you can as well
*listen* to your own speech, and transcribe it. Then you put the
transcription in an email and, lo and behold, you have written text.

Cheers,

..C..


Another point here is - that is incredibly easy to question points in a 
text simply by inserting the question.


I'll not listen to your video's either - if I have questions how do I go 
about it then?


At 0m25s you said something - what was that - couldn't understand what 
you said?


At 1m15s I couldn't hear you for the dog in the background - what did 
you say?


Seems to me you are deliberately putting roadblocks in the way of 
getting this dealt with - or hoping that people get bored and you can 
just do what you want.


Personally I think that perhaps the best way to deal with this is move 
it out of where it lives currently and let the docs team look after it.

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

[Alberto Salvia Novella]

Sorry but I spend an hour writing an answer to these emails, but even 
then I ended with something extra long that I think nobody will read or 
understand.


In fact that's what usually happens when I answer in text. On the other 
hand when I use video in a couple of minutes I'm usually done.


I will simply keep those as short as possible. And instead of making a 
monologue, with all the information, I would simulate an actual 
conversation. Usually with 10-20 seconds answers.


(https://youtu.be/L45EqUl2q4M)


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

[C de-Avillez]

On Tue, 30 May 2017 20:33:34 +0200
Alberto Salvia Novella  wrote:

> Sorry but I spend an hour writing an answer to these emails, but even 
> then I ended with something extra long that I think nobody will read
> or understand.

Writing is easy. Anybody can write. But *good* writing is difficult. We
have to try. We have to re-work what was written. We have to change
sequence of ideas. We have, at the worst, to consider that all we had
written bad enough to be thrown away, and re-start. And, if we publish,
we have to be willing to read the critics, and try to improve.

But, if we do not try, and persevere, we will never be able to write
something that can be understood. 

I have already, in a previous email in this thread, given you some
ideas on how to write. Try them. Research for other tips. Try them.
Listen to critics (which, usually, will be a written text). Respond in
writing.

> In fact that's what usually happens when I answer in text. On the
> other hand when I use video in a couple of minutes I'm usually done.

But you are *writing* a wiki page. How will you be able to write it if
you cannot justify your proposal in writing (H/T to Gunnar
Hjalmarsson, good point).

[in fact the hat tip above comes to show that *others* can have good
insights. I am not infallible. Nobody is.]

> I will simply keep those as short as possible. And instead of making
> a monologue, with all the information, I would simulate an actual 
> conversation. Usually with 10-20 seconds answers.
> 
> (https://youtu.be/L45EqUl2q4M)

I will not listen to it. If you can *talk* your points, you can as well
*listen* to your own speech, and transcribe it. Then you put the
transcription in an email and, lo and behold, you have written text.

Cheers,

..C..


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

[Dario Ruellan]

Something I'm missing on those tutorials is the recommendation for search
for updates before reporting the bug, just in case the problem is already
fixed.

Seem important for me, but I like to hear a second opinion about it.

On May 29, 2017 10:50 PM, "C de-Avillez"  wrote:

> 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..
>
>
>
>
>
> --
> Ubuntu-quality mailing list
> Ubuntu-quality@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/ubuntu-quality
>
>
-- 
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

[Gunnar Hjalmarsson]

On 2017-05-30 20:33, Alberto Salvia Novella wrote:

Sorry but I spend an hour writing an answer to these emails, but even
then I ended with something extra long that I think nobody will read
or understand.


If you are not able to justify your proposed changes in written text, 
why would we trust you as a driver of substantial changes to the bugs 
reporting guide, which consists of written text?


--
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj

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

[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

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:

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


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