How to give effective problem reports

Please post any bugs you have found
Post Reply
Message
Author
User avatar
paulh177
Posts: 975
Joined: Tue 22 Aug 2006, 20:41

How to give effective problem reports

#1 Post by paulh177 »

"Doesn't work" is a report of a problem, not a problem report ...

Simon Tatham has some good advice which, if followed by newbie and old hand alike, would make offering support much easier:

http://www.chiark.greenend.org.uk/~sgtatham/bugs.html

tempestuous
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

#2 Post by tempestuous »

Thank you for this post, paulh177.
Sadly, it will disappear into the informational ether of the forum.

It's important to note that we experienced users are trying to assist people with their problems by "remote control". The computer hardware under discussion is not in front of the person giving the answer, so it's obviously counterproductive if the person with the query does not accurately describe the problem.
Further, it's disrespectful. Without basic information such as the Puppy version being used (a frequent and glaring oversight) and the exact details of the hardware, the person giving the answer is forced to spend more of their (donated) time and analysis than would otherwise be necessary.

An even worse situation is explained in the link as such -
Simon Tatham wrote:I worked with another programmer once, who kept finding bugs in his own code and trying to fix them. Every so often he'd hit a bug he couldn't solve, and he'd call me over to help. "What's gone wrong?" I'd ask. He would reply by telling me his current opinion of what needed to be fixed.
...
But quite often he was wrong. We would work for some time trying to figure out why some particular part of the program was producing incorrect data, and eventually we would discover that it wasn't, that we'd been investigating a perfectly good piece of code for half an hour, and that the actual problem was somewhere else.

I'm sure he wouldn't do that to a doctor. "Doctor, I need a prescription for Hydroyoyodyne." People know not to say that to a doctor: you describe the symptoms, the actual discomforts and aches and pains and rashes and fevers, and you let the doctor do the diagnosis of what the problem is and what to do about it. Otherwise the doctor dismisses you as a hypochondriac or crackpot, and quite rightly so.
In other words; users should NEVER frame their question within a PRESUMED SOLUTION.
Experienced users can potentially waste their (donated) time and effort troubleshooting the PRESUMED SOLUTION when this is not the answer at all.
I recall some confused newbie on the forum once asked for detailed instructions on how to install the "linux-wlan-ng" driver (prism2_usb) and it eventually emerged that this had absolutely no relevance to their hardware. How much easier would it have been for that person to simply ask: "How do I setup my brand xx model yy rev zz device in Puppy ver xx"?

Another infamous example on the forum is "where can I obtain an updated driver for my xxx" with the blithe assumption that Puppy does not already contain an optimum driver for that device, or that configuration might play a factor, or there could be some other issue (completely unrelated to a driver) which is relevant.

There is even a forum thread here which dares to suggest that the Puppy Linux forum is somehow remiss for leaving a certain number of threads unanswered! Bizarre.
http://www.murga-linux.com/puppy/viewtopic.php?t=35502
koolie summed it up for me -
koolie wrote:Give them all a refund, I say, and a free 12-month subscription to the forum. Cost be damned.
Personally, I choose to answer posts only which interest me (apparently I have a right to choose what interests me) typically on subjects which advance the "science" of Puppy. For example; bluetooth support, touchscreen support etc.
So I browse quickly past the tedious questions which have been answered a million times before, such as "what's a tar.gz", "why can't I use make" etc.

I end this post on a light-hearted note with a classic example of a silly post -
http://www.murga-linux.com/puppy/viewtopic.php?t=30025
But then, that's Ubuntu. Check the Ubuntu forum and you will see thousands of examples of the blind leading the blind.

User avatar
paulh177
Posts: 975
Joined: Tue 22 Aug 2006, 20:41

#3 Post by paulh177 »

tempestuous wrote:Sadly, it will disappear into the informational ether of the forum.
Well, I see a moderator has seen fit to make this it a sticky in the Bugs subsection, so perhaps not!

paul

glassparrot
Posts: 286
Joined: Sun 01 Jun 2008, 16:07
Location: Durango, Colorado - USA
Contact:

#4 Post by glassparrot »

In my opinion, if you're going to submit a bug report, you'd better have a pretty good understanding of the nature of the problem. You have to be able to replicate it reliably. On the other hand, if you're bemused and are going to ask for help over in the beginner's forum - or from any technical support person - the best policy is to play dumb.

You make a lot of great points, tempestuous... but I don't think that you will get people to act in the manner you want them to by saying what you just did to them. In fact, in most cases, those folks who say "how do I install the latest driver for peripheral x.x.x" are those people who are earnestly trying to follow your advice. They think that the more technical information they can blurt out at first, the better chance they have of getting help.

Me, I will never give out hardware details on my machine until someone has expressed an interest in helping me... and then only if I honestly think it would be relevant to the problem that I'm querying them about.

A person asking for help with a dilemma needs to cast as wide a net as they can in order to increase the chances of someone answering their concern on a forum. That means they should post their question simply, and as you said, technosaurus - without putting their problem into the frame of reference of a proposed solution.

Those of us who have used puppy linux a lot have enough experience at these various hurdle points, that newbies' question will ring a bell for one of us, and we can give them a simple solution to their problem. Easy questions are wonderful because they are easy to answer... and you can feel instant gratification that you've solved someone's problem. And the great thing about this being on a bulletin board, rather than a chat room... is that time we invest in walking someone through a solution has value for others who wish to search the forum for a quick answer before they go the distance to ask their question, where they would have to wait several hours or days for someone to answer.

I do think that as a community, we should give due diligence to give at least one response to every person with a problem, to the extent we have the stamina and the time. Even if I don't have an answer - it's helpful to give moral support, and it bumps the question up so that someone else who might know the answer has the chance to see it.

But certainly asking for help is not the same thing as submitting a bug report. As I mentioned in the first paragraph - I believe that those who report bugs should be pretty certain about what they're looking at before they pipe up.

_______________

Thanks for posting that very helpful bit of prose by Simon Tathan by the way, Paul. It's a very good read, indeed.

Bruce B

#5 Post by Bruce B »

Even if you all made excellent points, what difference does it make if there is no bug list?

User avatar
paulh177
Posts: 975
Joined: Tue 22 Aug 2006, 20:41

#6 Post by paulh177 »

I originally posted this because Simon's excellent article makes lots of points which are helpful to bear in mind when giving "problem" reports or making requests for help. I have lost count of the number of forum posts which inadequately describe a problem, as must you Bruce (as you patiently deal with some of them).

If someone were to create a Puppy "bug list" , then what he has to say becomes even more directly applicable.

Bruce B

#7 Post by Bruce B »

paulh177 wrote: If someone were to create a Puppy "bug list" , then what he has to say becomes even more directly applicable.
The bug list would have to be at the project level. Don't you think?

Here is a link to a project which has one, just to show you and others.

http://gparted.sourceforge.net/bugs.php

I think the Gnome Parted Editor is a project of enormous undertaking, considering all it wants to be.

The fact of the bug list tells me they are serious about bugs, not just concepts and features also bugs.

Please don't take my comments as criticism of anything posted. If any developer takes it as an unwarranted criticism, that's okay with me. But not if you do.

Regards,


Bruce

User avatar
Béèm
Posts: 11763
Joined: Wed 22 Nov 2006, 00:47
Location: Brussels IBM Thinkpad R40, 256MB, 20GB, WiFi ipw2100. Frugal Lin'N'Win

#8 Post by Béèm »

Bugzilla is a good way of handling and following up bugs.
Time savers:
Find packages in a snap and install using Puppy Package Manager (Menu).
[url=http://puppylinux.org/wikka/HomePage]Consult Wikka[/url]
Use peppyy's [url=http://wellminded.com/puppy/pupsearch.html]puppysearch[/url]

y@s
Posts: 4
Joined: Sat 04 Apr 2009, 14:47
Location: Japan.

#9 Post by y@s »

Béèm wrote:Bugzilla is a good way of handling and following up bugs.
Bugzilla is good. And I think that also the MANTIS is good.
Because problem is color classified, it's easy to understand.
http://www.mantisbt.org/

Post Reply