[MUD-Dev] META: Making the list public?

[clawrenc at cup.hp.com]

In <33CCD580.41C67EA6 at iname.com>, on 07/16/97 
   at 08:40 AM, Shawn Halpenny <malachai at iname.com> said:

>clawrenc at cup.hp.com wrote:

>> For a variety of reasons and with considerable encouragement I'm
>> considering taking the list public.  Mainly this will consist of
>> advertising it in r.g.m.announce and setting up a supporting web page.
>> I'm interested in arguments for, against, and surrounding this motion.
>> I'm especially interested in concerns, predicted problems, or possible
>> ideas for heading off problems.
>> 
>> A)  Should the archives be requestable or browsable by non-members?
>> Note that this effectively makes ever poster's email address open.

>Were I a non-member interested in some of the things that are
>discussed on the list, but not interested in becoming a member, this
>would be welcome.  I'm not sure that configuration is even
>possible...

I can make the archives browsable easily enough.  I have no real
interest however in supporting or encouraging non-contributing peope
with the list's traffic.  The list survives on the contributions of
its members.  I have little driving interest in spreading that benefit
to those who don't contribute.

>I particularly like the idea of having the archives browsable by list
>members.  I haven't the space requirements to store every article
>that comes up on the list, so I find myself hanging on to the ones of
>particular interest to me.  The drawback, of course, is that there
>are occasionally times when I need to check that one, three-sentence
>argument clincher a few articles back in the thread and discover that
>I no longer have the article.

Possible solutions:

  Searchable archives on a web page.

  Browsable archives on a web page.

  Email requestable archives.  

  Automatic distribution of archives (see earlier reply on seperate
subscription list or blast-o-gram to all current members).

Side question:  Should last year's traffic be archived?

>> B)  Should the list be echoed (one way) to a newsgroup?  If it is
>> echoed to a newsgroup should that group be a private group on a
>> private newsserver, or should I create a moderated alt.mud.development
>> group?
>
>My concern with this is the distribution of the newsgroup.  I read
>posts to the list while at work and reply to them when I have spare
>time.  I do not know how receptive the newsserver admins would be to
>picking up the new group (it being mud-related and potentially
>detracting from work).  Even if they did, since I'm a contractor,
>I've no guarantee of being at this place of work for a definitive
>time, meaning I have to make sure the next location I am at carries
>the group.  The alternative is to only participate on the list, but
>since the group is one way (a must, I think, if that route were
>chosen), any discussion that doesn't filter back to the list from the
>group is inaccessible to me.

Were I to port the list to a newsgroup, several things would be true:

  1) It would be a one way port.  Users could not post to the
newsgroup and have their articles appear on the list.

  2) It would be a moderated group that refused all postings (I'd be
the moderator, and I'd bounce all submissions).  This is to prevent
dilution of the list, and migration of list threads to open newsgroups
(resulting in attrition of the list).

  3) It would *NOT* be ported to one of the already existant r.g.m.*
groups, as the net result would be that thread traffic would migrate
from the list to the newsgroups.

What it would be:

  A moderated group that contained copies ofall list traffic, to which
nobody could post.

>Perhaps echoing to an existing newsgroup with decent distribution is
>an option?

See above.

>> C) Should the list be split into seperate lists, divided by topic?
>> What should the topic splits be?  (Note: I'm not keen on this motion.
>> Convince me)

>Definitely not.  If the list were split into, say, game design issues
>(social, political, economic, world-building stuff, etc.) and the
>technical nuts-and-bolts of implementation, I would almost
>exclusively read the technical list, regardless of the importance of
>the non-technical.  Having the two lists combined makes me think
>about things that I would probably not consider or come up with on my
>own--from both sides.  Splitting the list would also hamper the
>possibility of overlap between the two, something useful and which
>I've seen occur a number of times on the current list.

This is my primary concern on this point.  Currently I'm very against
dividing the list in any way.

>> E) How should new membership be handled?
>> 
>>   Possible membership options:
>> 
>>     1) Publicise the list but only allow membership by application.
>> ie New members would have to apply, stating *why* they should be
>> considered as members.  These applications would be posted to the list
>> as well as my decisions on them.  (I'm not fond of this approach for
>> the overhead it puts on me).

>I think we can assume that we are intelligent enough to judge a
>person on his or her own merits where contributions to the list are
>considered, meaning I think the current method of membership is fine.
>The posting of the applications to the list would be more wasteful
>noise than signal.

The problem is that once the list is publicised, how does
BubbaPotentialMember having found out about the list manage to become
a member?

>>     2) Publicise the fact of the list, but leave membership by
>> invitation only.  Require any new member to be sponsored by an
>> existant member.

>This I like, though it seems somewhat at odds with publicizing the
>list: how do people who don't know anyone on the list join?

Precisely.

>>     3) Variation on #2: require the sponsor to also be an actively
>> posting member.

>Have to determine what constitutes an actively posting member.  Also,
>what if Bubba, who is not a frequent contributor to the list, but
>reads everything that comes across it, has friend Boffo who has
>tonnes of ideas and wants to join the list?  Does Bubba have to ask
>one of the actively posting members to bring in his friend Bubba? 
>Probably not a problem, but it seems like a layer of needless hassle.

Agreed.  It is an option however.

>>     4) Make membership uncontrolled.

>I think we'd attract some number of zealots who would then
>subsequently be dismembered from the list (too bad the context for
>that word was incorrect) after their evangelizing.  Not good, not
>bad, but a hassle.

There's a potential for the noise-stomping activities to overwhelm the
rest of the list's traffic.  It has me concerned.  

cf comp.lang.c at the start of every school year.  Freshmen "do my
homework for me" posts go thru the roof.  Traffic goes thru the roof. 
Flames go thru the roof.  Signal level goes sub-basement.

>I would choose to make the archives public (still wrangling with the
>visible email address issue), and echo postings to a newsgroup in
>some fashion.  Membership should stay as it is now.

Understood.

--
J C Lawrence                           Internet: claw at null.net
(Contractor)                           Internet: coder at ibm.net
---------------(*)               Internet: clawrenc at cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...