|
|  |
[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]
Re: st: RE: A wish list for Statalist
Sam,
If we created a wiki for Stata, then it wouldn't be Statacorp created
the online manual. Rather, it'd be the users of the Stata-listserv
most likely.
I think it's a great idea. The decision mainly is which wiki
software to use. Once that's decided, I suspect you'll see it grow
rapidly.
scott
On Jan 3, 2007, at 11:24 PM, SamL wrote:
You know, I have found this emerging discussion on whether or not to
change the list, add a wiki, include HTML, and such, all very
mystifying.
Stata is a statistical package. It does most things more elegantly
than
many other packages, and it has in place an infrastructure that
speeds the
implementation of new models and statistical insights. That's why
most of
us use it--not because it has a nice looking manual or web-page.
True to
that capability and elegance, it is straightforward, relatively
simple,
and more or less logical in its formatting of commands (written by
stata
employees). Although it is moving towards presentation quality
(e.g., the
graphics are very good, but from what I hear, it is not yet *there*
when
it comes to tabular results, though it is making progress), the major
comparative advantage of stata is in statistical application, not
presentation graphics, statistical explanation (use textbooks,
JASA, and
such), and not some other things, either (e.g., editing).
Hence, I won't speak for how other people on the list like to use
their
time, for I respect that if anyone wants to make an HTML version of
a list
or anything like that, more power to them. But, as for me, I'd much
prefer statacorp employees spend their time working on new models
than on
prettyfying the technical manual, the FAQ, the statalist or any
offshoots
thereof, or any other resources.
In that connection, my statistical wishlist for stata would include:
1)Multi-level model capability for qualitative variables (e.g.,
logits,
probits, and such) that is seamlessly integrated into stata.
2)The ability to use a single switch on the simulate command to easily
output the statistical results for each replication from the
simulation
command rather than requiring users to program the estimator to
provide
anything other than a mean.
There are other "wishes" I have, but that's two, and I offer them
in the
spirit of the New Year, a time when all seems (more or less, for
better or
worse) possible.
Happy New Year!
Sam
On Wed, 3 Jan 2007, David Elliott wrote:
I have been finding the various discussions, arguments, etc., being
tossed around regarding the possible transition of Statalist to a
forum format highly interesting. I'd like to summarize some of the
pros and cons. You will have to excuse the formatting since I can't
use the quick bulletin board coding (bbcode) to put [code] [/code]
tags around my text and have it appear in monospaced format.
Forum: Status quo:
Topic areas no
Congruent threads no
Announcements in "Sticky threads" What's a "sticky thread?"
Decreased access Universal access
Requires logon and browsing* Can see new messages as they arrive**
Richer tools for response Simpler tools for response
More work to set up/maintain Its working now and ain't broke
* The forum I administer can send eMails of new posts immediately or
as short interval digests, daily digests or weekly digests.
** For those of us using web mail we still have to logon to see
messages
On the wiki front, I see it as a FAQ on steroids. As it stands
now we
have wonderfully comprehensive manuals on one hand and the list on
the
other. Some subscribe to the Stata Journal and from what I have seen
it, it is a valuable resource that lies more in the middle. What
role
I see a wiki fulfilling would be something the extremely practical
"33
Tips" booklet to which a number of listers have contributed.
There is
an information niche between manual and list that could become slowly
populated with tips that are provided over and over again. This
wouldn't prevent all RTFM-type questions, but could provide an
increasingly comprehensive resource.
I'd like to reflect on a number of impressions that people have. It
is not right to equate HTML eMail and an HTML forum application -
they
are different applications. HTML email with "stationary" and lots of
graphics is an abuse of bandwidth and I side with people who rail
against it. That being said, limited html in emails can be used to
good effect and adds very little to the message overhead. HTML in
forums can be limited to some very basic formatting tags, all under
administrator control. Most commonly forums use bbcode, a form of
pseudo markup that is filtered and translated into real markup. This
limits codes and helps prevent inadvertant or malicious use of codes
that might "break" the page rendering or worse still, compromise the
underlying database.
While we are on the subject of bandwidth. I didn't strip the
repeated
message quoting that shows up below, but I suspect that eMails from a
forum which maintains thread congruency and sequencing would require
less bandwidth than the list currently generates. And further on the
congruency issue, at this time I count no less than 6 threads titled
"A wish list for Statalist." It is hard to know who is responding to
whom and I have seen it become a source of misunderstanding on many
occasions.
On the subject of time commitment. No-one has a lot of time on their
hands, including the hardworking StataCorp employees. Still, I think
StataCorp should look at the business case for hosting and
maintaining
the backend for a web forum. Many hardware and software
manufacturers
have support forums for their userbase. I have participated both
as a
questioner and a responder and can confirm that they can be of great
help.
DCE
On 1/3/07, Nick Cox <[email protected]> wrote:
I don't think Statalist is perfect, but I want to make
just three comments on Roy's suggestions.
1. Brainstorming about what does not work very well
and what might work better is all interesting and worthwhile,
but the suggestions I have seen so far involve
other people doing more work -- and no volunteers to help --
indeed explicit denials of intention to get more involved.
2. The comments here about StataCorp are to me unclear and
unconvincing. I can see absolutely no benefit in StataCorp
disengaging from Statalist and much loss. Note that StataCorp
hosts the Statalist FAQ, for example. In the several years that
I have been maintaining the FAQ page that hosting has been
objected to once that I know of -- as a matter of principle --
by someone no longer a member of the list. But the benefits of
that hosting are considerable, as a few moments' thought should
indicate. My own IT set-up certainly rules out my hosting the FAQ
-- I don't even enjoy free access to my "own" webpage --
nor would Marcello welcome the imposition of yet another
responsibility.
3. The name Statalist has been grabbed, but no one should feel in
any
way inhibited or prohibited from setting up their own list/forum/
blog
for discussion of Stata in their own way. Show us!
Nick
[email protected]
roy wada
It has been over a year since Statalist was taken off the Yahoo
Group
listings. My delivery of Statalist Digest has been erratic,
sometimes
missing up to 90% of the postings. Judging by the recent drop
in postings,
other people might be experiencing similar problems.
Reading through the Digest is not as fun as it used to be.
Too much to go
through before getting to the point.
Here is my personal wish list for Statlist.
1. Make HTML as the default
With free online accounts, most people should be able to
access HTML. We
really should move on and make do without the HTML gibberish
and the many
reminders not to use it.
2. Updated forum format
There are "canned" solutions for setting up a web-based
forum. These forums
are easy to use, easy on the eyes, and easy to understand. I
really would
like to see Statalist upgraded into one of these web-based
format for forums
(HTML-based, mind you). If you don't know what I am talking
about, see these
examples:
http://www.easternuswx.com/bb/index.php?showforum=15
http://forums.slickdeals.net/
With the updated format, the administrator could, for example,
set up
several sub-topics, such as installation, programming, data
cleaning,
estimation and inference, and advanced statistics. If someone
wants to see
everything in one place, as is currently the case, you should
set up such a
sub-topic (except it shows everything).
In these forums, the newest postings appeas at the top and
still keep the
thread intact.
The administator can also place the existing guide to
Statalist in the form
of a "sticky" at the very top of the forum, where it might
actually be read
by someone. These forums usually have a few designated moderators
(volunteers) who can occasionally clean up threads, fix
errors, discourage
trolls, etc.
Such set ups are much kinder to the new users who have in the
past tended to
get left behind. The new users usually have problems with
data cleaning, so
that's where they should be found within the forums, away
from those who
might not be well disposed towards that sort of thing and
spare us the
clutter.
It is also much easier to post on these types of forums
without having to go
through email accounts, fixing the subject heading (something
I usually
forget), and cross your (my) fingers that no mistake was made
because I
can't come back and fix it.
As Statalist currently exists, the posters cannot even change
their own
thread titles and it just doesn't look good. Statalist
currently works more
like a BB (bulletin board) where everyone is shouting to
everyone else. It's
messy, too noisy. Archiving of every errors and typos is
unsightly. Valuable
information is in there, but not in a useful format. I have
hundreds of old
Statalist Digests sitting in my email account untouched and
unread, I am
going to erase them soon.
The HTML-based forums can usually accomodate anonymized
accounts, which
minimizes abuse. I currently get much more spams when I post
on Statalist.
3. The Stata Corp should be "in" or "out"
Statalist has been a valuable resource for the Stata Corp.
Getting people to
donate their own time and effort towards helping other users
what more can a
company ask for. As it has been previously pointed out,
having Statalist
hosted on the Stata Corp website presents a serious conflict
of interest.
People are less likely to volunteer information when it appears (as
sometimes is the case) it is something the Stata Corps should
have handled
by itself. It also presents a dilution of responsibility
because the line of
responsibiliy isn't clear.
I personally would like to see the Stata Corp to either be
actively involved
in the management of Statalist, including setting up a
user-friendly forum
mentioned above, or completely be disengaged from Statalist
by having it
hosted on somewhere else. It should be in or out, without
giving a murky
signal that it may come to the rescue should something go
wrong. If the
Stata Corp chooses to stay out, there's always a space
somewhere, especially
among the academic domains. The bandwidth requirement for Statalist
shouldn't be too big.
Of course, Statalist has been maintained in the past by a
number of generous
people. There are good reasons for doing it this way or that way. I
personally would prefer to see something less demanding, a
little more
organized, and a bit more egalitarian. I suppose someone
could go set it up,
but it would be nice if Statalist did all that.
*
* For searches and help try:
* http://www.stata.com/support/faqs/res/findit.html
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
--
David Elliott
*
* For searches and help try:
* http://www.stata.com/support/faqs/res/findit.html
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
*
* For searches and help try:
* http://www.stata.com/support/faqs/res/findit.html
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
*
* For searches and help try:
* http://www.stata.com/support/faqs/res/findit.html
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
