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

clawrenc at cup.hp.com clawrenc at cup.hp.com
Thu Jul 17 10:31:37 CEST 1997


In <199707161835.NAA04200 at dfw-ix5.ix.netcom.com>, on 07/16/97 
   at 08:02 PM, "Jon A. Lambert" <jlsysinc at ix.netcom.com> said:

>> From: clawrenc at cup.hp.com
>> Subject: [MUD-Dev]  META: Making the list public?
>> 
>> A)  Should the archives be requestable or browsable by non-members? 
>> Note that this effectively makes ever poster's email address open.
>>
>
>The email addr problem doesn't bother me personally. I think the
>benefit of archives to existing newer members would be high (list
>going public or not).  To see what has gone before and all that.

BTW: The archives have always been available by request.  Of course I
haven't publicised that fact much.  I salted several of the recent new
members by sending them the last couple months of archives when they
subbed.

Perhaps this salting should be a standard procedure, or at least the
archive availability should be documented in the welcome message...

>> 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?
> 
>I think it very unlikely that a new 'alt' group will be picked up by
>many news providers.  In fact my provider, Netcom, has been squeezing
>out some of the low traffic "standard" groups and alt groups are
>disappearing even faster.  

My main interest in exporting the list to a newsgroup would be to have
it archived by Dejanews.  However, I'm not convinced that archiving
the list like that, or making it searchable like that is a Good Thing.

>Why not flood rec.games.mud.misc?  

Because it would result in the dilution and eventual atrophy of the
list.

>Echoing to a newsgroup has the advantage that one can effectively
>ignore  noise ridden feedback should one desire.  It could also
>provide hours amusement and frustration for readers of rgmm only. ;)

I could see using periodic (fortnightly?) postings of a single recent
daily digest to r.g.m.misc as a list teaser, but I'm not very keen.

>> 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)

>I'm all for a subject tagging mechanism similar to what was proposed
>in rgma.  This would be especially nice of us if we echo to an
>existing NG. I think a physical list split would be counterproductive
>to discussion.   Like others have pointed out, some threads have
>bounced between hardwired  bit-level out to effects on user feelings
>and back.

I would have no problem with people using a sbject tagging scheme.  I
think its a great idea.  I am however not about to mandate it as a
large percentage of current traffic rarely falls into less than 3 or 4
tag categories.

>> E) How should new membership be handled?
>> 
>>     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 is the current method with the added fact of publicity.  This 
>could cause one to be open to elitism charges, but who cares.  

Moderation is all things, including moderation.  I don't consider
elitism a generically Bad Thing.

>It
>does avoid much of the hit and run of option 4).  I think that fact
>that  if someone takes the extra effort to request invitation from a
>member is a good indicator that they have an interest in positive
>contribution.

How do they know who the members are?  Do we really to make make all
members open for being pestered for invitations by the great unwashed? 
I can see it now:

  BubbaDork has been refused an ivitation by every existant member.

  BubbaDork scans the list archives.  

  Every time a new member joins BubbaDork spams him with a request 
  for an invitation.

An extreme and unlikely example, but the potential is there.  The next
variation is that BubbaDork sends his invitation request to every
single member...  Such dedication is of course commendable, but the
results not very worthy of reward.

>> Do realise however that taking the list public opens it to the Reese
>> idiot intolerace flames, Katrina's dunno-how-C++-works prattles,
>> Addledbrain III's LP-is-da-deity pieties, DikuHeads R00L chants etc of
>> the world, etc and that any moderation I do will be after the fact. 
>> As such it will potentially open us to hit-and-run attacks.  I don't
>> think this is a huge danger, but it is present and should be
>> acknowledged.

>Actually it would may likely open the list to more innocent forms of
>"noise".  Such as "How do I compile a fooble on a Z-system?" or  "I'm
>getting errors when I throw a flob switch in a widgetlib"

True.  I'd reword the welcome message to rule such off-topic with a
stated no-warnings penalty clause (1 post == desub).

>>   Note; Yes, I can close subscription for a while, ban selected 
>>   users, remove posting priviledges, personally accept/reject 
>>   every post for a while, etc, but the more time and effort 
>>   these tactics require of me, the less eager I am to use them.
>>
I think this question boils down mostly to your preferences.  If you
>believe you have the time, thick skin, big stick, et al to handle
>such a job then so be it.  

Time is a always a problem.  I think I have the thick skin (well,
outside of typos).  I have an endless supply of big sticks.  What I'm
missing are small sticks (<Wag finger>  "Naughty boy!  Don't do that
again!"  <stamp foot>).

>I know you have the best intentions at 
>heart for the good of the list and I'm certain you would close 
>subscription if going public backfired and decreased your pleasure in
>posting/reading the list.

Err, yeah.  My main guide is the stated purpose of the list.

--
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...




More information about the mud-dev-archive mailing list