craigwhite@azapple.com wrote:
pardon the html...trying to keep long line together...
stick this in a google search
"rmdir when directory is not empty" site:https://www.redhat.com/archives/fedora-list/
Craig
Thanks Craig. I didn't know that Google trick.
My $.02 on the main topic of this thread. Requests for assistance should:
1) Have a clear concise statement of the problem as the subject.
2) Should start off with a re-statement of what the problem is that expands on the subject.
3) If necessary, include the steps the poster has already taken or other pertinent information.
This tends to allow verbose posts to get answered since people who have some idea of the solution can understand the problem without having to wade through a lot of material. My time is limited (and I'm guessing so is everybody else) so I like to be able to *quickly* determine whether I can help with a particular problem or not.
It would be nice if the Fedora web site were to have an easy to find "getting help" section that, besides pointing to this list, also included some hints such as the above for searching and maybe even some basic stuff like using "man -k" and other tools such as grep to RTFM successfully.
Cheers, Dave
craigwhite@azapple.com wrote:
pardon the html...trying to keep long line together...
stick this in a google search
"rmdir when directory is not empty" site:https://www.redhat.com/archives/fedora-list/
Craig
Thanks Craig. I didn't know that Google trick.
My $.02 on the main topic of this thread. Requests for assistance should:
Have a clear concise statement of the problem as the subject.
Should start off with a re-statement of what the problem is that
expands on the subject.
- If necessary, include the steps the poster has already taken or other
pertinent information.
This tends to allow verbose posts to get answered since people who have some idea of the solution can understand the problem without having to wade through a lot of material. My time is limited (and I'm guessing so is everybody else) so I like to be able to *quickly* determine whether I can help with a particular problem or not.
Dave, I agree on all 3 steps. I also agree with Craig that verbosity is not a good thing when posting for help (so I guess I am wrong when I try to give as much information as I think will help)....
However...the more things I've tried before posting leads to a "wordier" post when I finally do ask for help if I'm going to try and avoid a bunch of "I tried that, it didn't work."
So how do we balance the amount of information we give vs. avoiding verbosity vs. "Oh, I see the OP has already tried what I was going to suggest." vs. getting the problem solved?
On Thursday 29 December 2005 11:12, Charles Howse wrote:
So how do we balance the amount of information we give vs. avoiding verbosity vs. "Oh, I see the OP has already tried what I was going to suggest." vs. getting the problem solved?
I doubt you'll find a magic formula. Think "conversation".
In general, pretend you're on the other end of the conversation and are answering someone else's identical question. Give as much information as you think you'd need to answer it.
If we find your question isn't detailed enough, we'll likely ask you for more info or point to where you can find more information regarding your question, including the manual, if that's all we can think of at the time.
Regards, Mike Klinke
On Thu, 29 Dec 2005, Mike Klinke wrote:
On Thursday 29 December 2005 11:12, Charles Howse wrote:
So how do we balance the amount of information we give vs. avoiding verbosity vs. "Oh, I see the OP has already tried what I was going to suggest." vs. getting the problem solved?
I doubt you'll find a magic formula. Think "conversation".
In general, pretend you're on the other end of the conversation and are answering someone else's identical question. Give as much information as you think you'd need to answer it.
If we find your question isn't detailed enough, we'll likely ask you for more info or point to where you can find more information regarding your question, including the manual, if that's all we can think of at the time.
Many times when I ask a question, I get the response "just Google(tm) for it".
Most of the time when i do, I find plenty of people asking the same question, but none of them getting any answers. (That actually solve the problem.)
The only way that people will find answers on Google is if people start answering the questions in the first place.
David G. Miller (aka DaveAtFraud) wrote:
craigwhite@azapple.com wrote:
pardon the html...trying to keep long line together...
stick this in a google search
"rmdir when directory is not empty" site:https://www.redhat.com/archives/fedora-list/
Craig
Thanks Craig. I didn't know that Google trick.
My $.02 on the main topic of this thread. Requests for assistance should:
Have a clear concise statement of the problem as the subject.
Should start off with a re-statement of what the problem is that
expands on the subject.
- If necessary, include the steps the poster has already taken or other
pertinent information.
This tends to allow verbose posts to get answered since people who have some idea of the solution can understand the problem without having to wade through a lot of material. My time is limited (and I'm guessing so is everybody else) so I like to be able to *quickly* determine whether I can help with a particular problem or not.
All sound advice.
It would, I guess, be too much to ask responders to seek clarification instead of guessing that the problem is. Often, I think a Q is the only sensible reply, and I see others assuming they know what the OP means by "my computer won't boot," or some other vague description of a problem.
It would be nice if the Fedora web site were to have an easy to find "getting help" section that, besides pointing to this list, also included some hints such as the above for searching and maybe even some basic stuff like using "man -k" and other tools such as grep to RTFM successfully.
an introduction to the info command too! I've been using Linux for eight years or so and I still detest that command, mostly because I don't understand the UI, it seems arcane, different from everything else....
pinfo is better, but not always part of the install set.
Mostly $_ info info | less works.
But also, a guide to asking questions that will attract good answers.
Charles Howse wrote:
I agree on all 3 steps. I also agree with Craig that verbosity is not a good thing when posting for help (so I guess I am wrong when I try to give as much information as I think will help)....
However...the more things I've tried before posting leads to a "wordier" post when I finally do ask for help if I'm going to try and avoid a bunch of "I tried that, it didn't work."
So how do we balance the amount of information we give vs. avoiding verbosity vs. "Oh, I see the OP has already tried what I was going to suggest." vs. getting the problem solved?
I'd suggest newspaper-style reporting: include the important stuff first, and give less important stuff later.
If you think about the way you read a newspaper, you might scan the headlines for something that looks interesting. When you find an article that looks intriguing, you read the first paragraph or so to see if it does interest you. If it doesn't, you'll either skim the rest or ignore it.
So newspapers put the most important stuff first, then put the added points, *then* go back and tell the story from the beginning. It helps catch the reader's attention, and doesn't make them read long articles to see if they're interested.
It's the same way with reading mailing lists. Mostly, I can tell if I'm going to be interested in an e-mail from the subject and the first few lines. I can also tell if I'm likely to respond. If I'm interested, or I'm likely to respond (maybe I've got a hunch), *then* I'll want to read the rest to see if my hunch was right. That's when I'll want to know what else you tried.
Some of us even sort the mailing list based on keywords in the subject.
So, for example, I might suggest:
Headline (subject line): what's wrong
First paragraph: repeat what's wrong in one or two sentences, including why you think something is wrong, and what you might expect to happen.
Next paragraph or so: this is where you go into details about the problem. This is where it's appropriate to suggest theories. If you think your troubleshooting has closed off major lines of enquiry (e.g. "it works under Windows so it's not hardware"), you might mention this here. If you have particular reasons for suspecting a particular area, you can say so here. You should also post what you consider to be the most relevant data.
Rest of the e-mail: what else you've tried, package / hardware details (if appropriate).
James.
On Wed, 2006-01-04 at 17:27 +0000, James Wilkinson wrote:
Charles Howse wrote:
I agree on all 3 steps. I also agree with Craig that verbosity is not a good thing when posting for help (so I guess I am wrong when I try to give as much information as I think will help)....
However...the more things I've tried before posting leads to a "wordier" post when I finally do ask for help if I'm going to try and avoid a bunch of "I tried that, it didn't work."
So how do we balance the amount of information we give vs. avoiding verbosity vs. "Oh, I see the OP has already tried what I was going to suggest." vs. getting the problem solved?
I'd suggest newspaper-style reporting: include the important stuff first, and give less important stuff later.
If you think about the way you read a newspaper, you might scan the headlines for something that looks interesting. When you find an article that looks intriguing, you read the first paragraph or so to see if it does interest you. If it doesn't, you'll either skim the rest or ignore it.
So newspapers put the most important stuff first, then put the added points, *then* go back and tell the story from the beginning. It helps catch the reader's attention, and doesn't make them read long articles to see if they're interested.
<rant> If the "journalist" writer is being honest!!! Too often nowdays the headline and the first few paragraphs give the negative point of view and the bottom of the article contain the facts that make it a 'so what' story. </rant> The theory is correct but the facts are often not in journalism. I like your approach and it does fit what i use as well.
It's the same way with reading mailing lists. Mostly, I can tell if I'm going to be interested in an e-mail from the subject and the first few lines. I can also tell if I'm likely to respond. If I'm interested, or I'm likely to respond (maybe I've got a hunch), *then* I'll want to read the rest to see if my hunch was right. That's when I'll want to know what else you tried.
Some of us even sort the mailing list based on keywords in the subject.
So, for example, I might suggest:
Headline (subject line): what's wrong
First paragraph: repeat what's wrong in one or two sentences, including why you think something is wrong, and what you might expect to happen.
Next paragraph or so: this is where you go into details about the problem. This is where it's appropriate to suggest theories. If you think your troubleshooting has closed off major lines of enquiry (e.g. "it works under Windows so it's not hardware"), you might mention this here. If you have particular reasons for suspecting a particular area, you can say so here. You should also post what you consider to be the most relevant data.
Rest of the e-mail: what else you've tried, package / hardware details (if appropriate).
James.
E-mail address: james | "!" sez I. And "?". After a few speechless seconds @westexe.demon.co.uk | I come out with "%^&*". Unless I come up with | something plausible soon I'm going to run out of | special characters. -- Ben at lspace.org
Hi;
I agree with the journalist approach. Unfortunately it seems journalists have such a poor reputation these days that the approach is likely to be dismissed.
On Wed, 2006-01-04 at 20:13 -0600, Jeff Vian wrote:
On Wed, 2006-01-04 at 17:27 +0000, James Wilkinson wrote:
Charles Howse wrote:
However...the more things I've tried before posting leads to a "wordier" post when I finally do ask for help if I'm going to try and avoid a bunch of "I tried that, it didn't work."
So how do we balance the amount of information we give vs. avoiding verbosity vs. "Oh, I see the OP has already tried what I was going to suggest." vs. getting the problem solved?
I'd suggest newspaper-style reporting: include the important stuff first, and give less important stuff later.
[snip]
<rant> If the "journalist" writer is being honest!!! Too often nowdays the headline and the first few paragraphs give the negative point of view and the bottom of the article contain the facts that make it a 'so what' story. </rant>
[snip]
Headline (subject line): what's wrong
First paragraph: repeat what's wrong in one or two sentences, including why you think something is wrong, and what you might expect to happen.
Next paragraph or so: this is where you go into details about the problem. This is where it's appropriate to suggest theories. If you think your troubleshooting has closed off major lines of enquiry (e.g. "it works under Windows so it's not hardware"), you might mention this here. If you have particular reasons for suspecting a particular area, you can say so here. You should also post what you consider to be the most relevant data.
Rest of the e-mail: what else you've tried, package / hardware details (if appropriate).
I appreciate the help I have gotten from this mailing list and others (particularly direct help from members of my local LUG). I have started to -- and it seems to be working -- using mail in the manner suggested above: * a meaningful headline -- they seem to get more responses than 'sexy' or 'cute' or 'meaningless' subject lines -- I have tried all kinds; * a short first paragraph that succinctly outlines the problem and ends with a specific request for a defined type of help; * a Post-amble. A Post-amble, to me, is what might logically go into a preamble. I even label the last section as Post-amble to warn the potential responder that he is entering a free flowing description of what I see as the problem, how it seems to have come about and what I have tried.
I believe by using the Post-amble format, I am striking a kind of deal with a potential responder that says "I have started in a manner that makes it easier for you to decide to help or not. Now, in the Post-amble, I am proceeding in a way that makes it easier for me to explain my situation." I think that's fair.
By the way, I think its only polite that if you don't want to respond, don't respond. If its locatable in a manual, state the manual; if its easy to google for, state or suggest some search criteria. In fact, as a learning experience, suggested criteria can be more helpful in the long run than a direct URL.
Regards Bill
-
Alan -
Bill Case -
Charles Howse -
David G. Miller (aka DaveAtFraud) -
James Wilkinson -
Jeff Vian -
John Summerfield -
Mike Klinke