Stata The Stata listserver
[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

st: Acronyms in subject fields; separate Statalists?

From   "Nick Cox" <[email protected]>
To   <[email protected]>
Subject   st: Acronyms in subject fields; separate Statalists?
Date   Thu, 10 Jun 2004 20:22:16 +0100

You have raised quite different issues, so 
I've changed the header. 

Acronyms in subject fields

I personally appreciate the spirit of the suggestion, 
but I just don't think it's workable. 

It depends on people learning 
the codes and remembering to use them and 
what they mean. The sad fact is, as 
can be seen by a glance at the archives, 
that many people do not read the FAQ
and/or do not follow its suggestions, 
or even follow general internet etiquette, 
on much simpler points of procedure, 
so adding even a little complication 
like this is expecting too much.

Thus a large fraction of postings 
already carry (1) no titles (2) 
uninformative titles (3) irrelevant 
titles, etc. even though it should 
be apparent either from other lists 
or from a little reflection that 
a good choice of title is an important
detail. So expecting other people to 
learn and use this system is pretty 
optimistic, I'm afraid to say. 

A case in point is the largely British 
list allstat, which does have such 
a code system. By and large, most people
forget to use it. By and large, those 
who do _also_ provide good titles, 
so that either it's absent or it's 

Separate Statalists

Anyone who wants to organise a separate 
Statalist is at perfect liberty to try. 

I am pessimistic, however. I suspect
that we would get the worst of both 
worlds with either questions asked 
on one list which had just been answered 
on another, or people cross-posting to 
both or all lists (apologising while they 
did so). This would only need to be occasional 
to be very irritating and it would be 
the cause of all sorts of minor rows 
or tensions. 

A separate list would make sense to the 
extent that there is a really distinct 
subset of questions, so that which list 
is best to post to is obvious. I don't think 
this is true of Statalist, quite apart 
from the key question of who would do 
the work. Of course everyone has their 
own private criterion -- interesting or 
useful to me... 

[email protected] 

> I have one additional proposal.  Maybe someone can organize an
> MS-Statalist or a GUI-Statalist, for all those questions 
> concerning "Can
> -blah-blah- be done via the -da-da-da-da-da- menu?" and such. 
>  These kinds
> of questions are becoming a larger and larger part of the 
> statalist, and
> my concern is their rising incidence is going to drive users who can
> answer more . . ., ahem, statistical/programming/technical 
> questions off
> the list.
> Maybe an alternative would be for users to voluntary use a 
> short acronym
> at the start of the "Subject" field to clue users in to the 
> area of the
> question.
> STAT -- A statistical question
> MACR -- A question about a macro or macro programming
> GUI -- Graphical User Interface questions
> MS -- Microsoft/Stata compatability questions
> EDIT -- Editor questions
> UNIX -- Unix questions
> UPDA -- Questions about updating one's stata
> I imagine one could come up with more, but I also figure the 
> list should
> be short and need not reference every command that might be 
> discussed in
> the query.  A set of large categories to help people 
> immediately know if
> the question is one that concerns them, and whether they 
> could answer it,
> is what I was shooting for.
> This is not meant to disparage any type of question.  It is, 
> however, to
> recognize that the content on the list is changing, and those 
> changes may
> lead some of the more experienced members of the list to de-subscribe.
> We all have an interest in having a large and knowledge list to
> maximize the chance our as yet unknown query will be 
> answered.  Thus, I
> hope this proposal will be received in the spirit of maintaining that
> resource.

*   For searches and help try:

© Copyright 1996–2024 StataCorp LLC   |   Terms of use   |   Privacy   |   Contact us   |   What's new   |   Site index