As Martin says, we do all this already. I think all well-behaved
citizens would be entitled to protest if we did even more.
Nick
[email protected]
Martin Weiss
Just unsub and resub as described in
http://www.stata.com/support/faqs/res/statalist.html#howto, and you will
see
that the FAQ are given prominence for the newbies. Plus there is a link
at
the bottom of every post pointing to them
kokootchke
Nick, perhaps one thing that may help is to have the Stata listserve
send an
automated message to new users that summarizes the most important points
in
the FAQ or that asks the user to read the FAQ --- I joined a long time
ago
so I don't remember if new users already get a message like that... but
having a link to the FAQ online in an automated e-mail may actually help
lazy users (like me) to read the FAQ page before posting.
> From: [email protected]
> As maintainer of the FAQ, I don't think so -- although naturally I am
> open to any further expressions of opinion on the matter.
>
> Kit's point that Martin's code fails if variable abbreviation is
> disallowed is undoubtedly correct, but as yet this issue has not been
a
> source of much misunderstanding on this list. I don't think it is at
all
> practical to insist that code givers should never use variable
> abbreviation, not least because I wouldn't guarantee to do that
myself,
> for all that I agree that Kit has a strong argument.
>
> Also, I am reluctant to pad out the FAQ with minor details when there
is
> already much evidence that many people never read it, or read it
> through. That may look like idleness, but no doubt those concerned
> really feel that they are too busy or know that they should do it
soon,
> or some time.
>
> I remain much more exercised by how to get all members to pay
attention
> to much more frequent sources of confusion, irritation and wasted
> bandwidth:
>
> 1. Failure to read on-line documentation.
> 2. Formatted messages and/or attachments.
> 3. New posts that are replies to old threads.
> 4. Insufficient editing of previous posts.
> 5. Failure to search archives.
> 6. Out of office messages.
> 7. Poorly phrased questions.
> 8. Not saying exactly what you typed and what Stata did.
> 9. Not specifying out-of-date version being used.
> 10. Not specifying origin of user-written Stata commands.
> 11. Assuming universal understanding of arcane details.
> 12. Incomplete literature references, especially name (date).
> 13. Not specifying operating system when it is important.
> 14. Assuming everyone else is in the same country and even time zone.
>
> 15. Absent or dopey subject lines.
> 16. "Thanks in advance", which often looks disingenuous.
> 16. Failure to answer secondary questions.
> 17. Failure to close threads.
> 18. Repeated posts.
> 19. "What should I do next in my project?" Depends on what it is...
> 20. "Is this correct?" Depends on what you want to do...
> 21. "It did not work." Meaning precisely...
> 22. "STATA." Not read any documentation recently?
>
> But all that said, Statalist when it works as intended is free, fast,
> friendly (modulo marginal grumping), clear and correct, so who's
> grumbling?
>
*
* For searches and help try:
* http://www.stata.com/help.cgi?search
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
