What makes a perfect newbie?

[JMJ_coder]

Hello,

Yes, I would stress patience. Usually, a little extra patience in doing your own research will save a novice user the embarrassment of asking an easy question. I know that more than once, being impatiently flustered, I asked a silly question only to find the answer five minutes later on my own. And oh, how sheepish I feel then.

Of course, one should not be ashamed of asking a question that you truly cannot grapple on your own - even if it is the easiest and oldest question in the book.

[TerryP]

patience is also a great thing for the skillful to have.

I remember (on another forum) where someone practically able to write there own print driver was trying to help a newbie set up their printer.


The young'in tried to follow the instructions but couldn't understand things like the common commands needing an argument or path if you didn't want the CWDs contents. When ever they were left out of the instructions, he wasn't a CLI user (and probably not a genius), he didn't make the connection between it.

Instead of pointing the kid to the manual, a resource to learn more about such things, or explaining the most basic, he eventually gave up with a headache lol.

[eine]

Hi, This is my first post on this forum..and as a newbie, i'm agree with JMJ_coder. Patience is number one, but then i want to stress another point : always have a newbie's curiosity, and never think you've passed the "newbie" level..because in my opinion, true pro always never think they've reached the top of everything

i wish i spelled it right..i'm a little confused between how to translate my mind, and write it down

[scottro]

Your spelling isn't bad (though I'm not sure if you meant to say phrasing). Either way, your manner of writing is rather poetic. (That isn't sarcastic.)

Also, in English, when using I as a pronoun, it should always be capitalized.(Although you'll see many native English speakers here fail to do that, it just makes the writer look a bit silly and makes their posts harder to understand.)

Back to the topic at hand, you're quite right. Always keep your curiosity. Stop learning, you start dying.

[eine]

haha, thanks for telling me scottro. i'll try to repair my english...and again, it's true, if you stop learning, you start dying..and remember that dying is off course worse than die itself...

[BuSerD]

Thanks for the outline. The only thing I am ready tap out on is mailing lists. I'll get it sooner or later but dmesg output seems long for a forum post. Is it better to grep out the lines of interest or as a noob is it better practice to post all of it?

[BSDfan666]

Originally Posted by BuSerD

Thanks for the outline. The only thing I am ready tap out on is mailing lists. I'll get it sooner or later but dmesg output seems long for a forum post. Is it better to grep out the lines of interest or as a noob is it better practice to post all of it?

It's quite fine to post dmesg output, some people here would actually find it useful.. just be sure to contain it inside of [code][/code] bbcode.

External text hosts, pastebin etc, are actually a bit more inconvenient.

[ai-danno]

I agree. We're all a bunch of geeks here, so posting the whole dmesg isn't an issue.

[ocicat]

Originally Posted by BuSerD

Is it better to grep out the lines of interest or as a noob is it better practice to post all of it?

One of the truisms in troubleshooting (especially if it is remote troubleshooting...) is gather all information upfront. Perhaps the person asking for support has knowledge of this particular area & maybe they don't. Maybe they have been at it for awhile & have developed their own framework & mindset for what might or might not be wrong.

As an independent & unbiased troubleshooter, it is better to arrive at your own conclusions as opposed to allowing your interpretation of the situation be influenced by the logic of those asking for support. Information which at the beginning may have appeared innocuous may later prove crucial. It is far better to post everything.

[hitest]

Originally Posted by scottro

Back to the topic at hand, you're quite right. Always keep your curiosity. Stop learning, you start dying.

Well-said, scottro. I'm a FreeBSD newcomer. I've been away from the forums for quite some time. I'm glad I found this forum, there are a lot of familiar faces here.
You've always been helpful to me in the past. It is good to be back.

[Turophile]

I believe this works as long as we remember Weinberg's The Psychology of Computer Programming (or this summary).

It's really a two way street (and without getting bogged down in entry level philosophy and psychology)...

For suggestions see the quote, edits in red...

Originally Posted by jggimi

The Perfect Newbies...

1. ...Do their homework...
   
   1. They read the Project's documentation: the FAQ or Handbook. They read it more than once or ask politely for someone to explain what it means.
   2. They read man pages. They follow the SEE ALSO suggestions in man pages to discover additional information or ask politely for someone to explain what it means.
   3. They know how to search the Problem Report database at the Project website, and they do so or will ask politely when the feature is obscured by "standards compliant" web design.
   4. They keep bookmarks to their favorite Project mailing list archives in their browsers. They search the archives frequently.
   5. They know how to use Internet search engines, and use them.
   6. They search daemonforum, too.
   7. They read books. Books on Unix. Books on BSD. That they ask for suggestions on what to read or where to borrow them.
2. ...Describe their problems...
   
   1. They describe problem situations as clearly as their knowledge and understanding permits.
   2. They post actual error messages they've seen.
   3. They post the actual commands they used, and the output of those commands that they didn't understand, or that confused them.
   4. They might ask, if it occurs to them, what they should supply for support in debugging.
   5. That they might comply with simple, non-intrusive requests.
   6. That they might politely reply if they feel the request is intrusive to their security.
3. ...Disclose their situations...
   
   1. They tell us what architecture they are using.
   2. They tell us what release and flavor they are using.
   3. If they are using a custom kernel, they say so.
   4. They post their dmesg. (This covers c1, c2, and c3, by the way.)
   5. They post the content of applicable configuration files.
   6. They provide "pictures" of their network layouts when applicable.
4. ...Communicate...
   
   1. They respect the forum membership, in return.
   2. They understand that this forum is not a Help Desk, and that the people who are trying to help them are volunteers.
   3. They respond to suggestions and recommendations from the people who are trying to help them, letting their helpers know what worked and what didn't.
   4. They post the information helpers request, with redactions of private information, such as public IP addresses (see (c6)).
5. ...Keep a positive attitude.
   
   1. They approach each problem as a learning opportunity. "What knowledge do I lack?" rather than "It's broke. Fix it for me."
   2. They expect nothing. They know their helpers are only other BSD users, and that we will refer people to project mailing lists or bug reporting facilities when necessary.

It's a damn good list but the reason(s) for the change(s) are...

Seriously, should toss this around a bit more, work out what the community agrees and push to get a man page included "man newbie" would be fantastic.

And dead seriously, I think it would be an AWESOME boon to the community, even if it was just the BSD community, if OpenBSD and FreeBSD included this in the manual/docs. People NEED to read it. Of course then we'd need the "What makes a perfect helper?" guide too

[ocicat]

Originally Posted by Turophile

Seriously, should toss this around a bit more, work out what the community agrees and push to get a man page included "man newbie" would be fantastic.

Although your exuberance is commendable, the cultures of the various *BSD projects are different. Each deals with newbies in different ways. In general, the various projects focus at development issues as they should. Providing help to newbies may be important, but its prioritization is eclipsed by more pressing development matters. If newbies can fill any void which may be present, great. If they can't, there are other alternatives in operating systems. The *BSD projects are simply not big enough to have the infrastructure in place to deal with such collateral issues.

However, if there is a role that independent forum sites like this one can fill, helping newbies could be a cornerstone to our existence. Whether we actually fill that role is a different question.

Nevertheless, a number of us try.

People NEED to it.

There are a number of variations on this theme which have been available for a much longer time. One of the more notable examples is the following:

http://www.catb.org/~esr/faqs/smart-questions.html

Yes, it would be good if people had better & more mature troubleshooting skills, but the reality is otherwise. As a wise member of this site has told me, "You can lead someone to the water, but you cannot make them think..." We are a resource. If people take advantage of what we collectively can offer, great, but we cannot force anything on anyone.

Of course then we'd need the "What makes a perfect helper?" guide too

Already done.

http://daemonforums.org/showthread.php?t=1455

[Turophile]

Aye, noted the guide (hence the ) but the problem is that people often look at the docs then ignore it. Sadly catb's guide is also oft ignored. My suggestion was to throw something like that into the docs or [old] BSD license it and throw it around forums...

This is probably the only forum I've been on in a long time that hasn't been:
a) Ubuntu-centric
b) isn't terribly arrogant (and if it is I'll find out later, don't disillusion me :P)

My enthusiasm is more that people here genuinely seem to want to contribute and follow the "10 commandments of non-egotistical programming" on the forum (which I guess is the inverse of this guide).

I don't know, I've had a few rude responses from devs in the past when I was polite about it and I've certainly seen a few newbies give them grief back and it just seems like a vicious cycle; we really need both thrown at the people involved - though idea of a TOS for an OS irks me in a way, maybe for mailinglists ...