[MUD-Dev] META: To flame or not to flame (was: Usability and ...)

[clawrenc at cup.hp.com]

Remember the META tag please.

NOTE: The following is __NOT__ written as the list owner.  The list
owner merely coincidentally, accidentally, nay, freakishly happens to
hold similar views...(surprise!).

In <199709222046.12986.hridil.ifi.uio.no at ifi.uio.no>, on 09/22/97 
   at 02:02 PM, Ola Fosheim Gr stad  <olag at ifi.uio.no> said:

>caliban at darklock.com (Caliban Tiresias Darklock) wrote:

>>It's a double-edged sword; if you do battle with the critics, it
>>consumes a lot of time and energy. If you ignore them, they can
>>undermine your efforts drastically. There's a happy medium in there
>>somewhere, but I haven't found it yet. 

>I think all message-based discussions formus (fora?) (news, bbs,
>mailinglists) are hampered with the very segmented and shortsighted
>"structure" of the dialog.  Sometimes I believe that a moderated
>mailinglist with formal rules would be more constructive and
>rewarding.

I won't argue with the value of an edited forum, with the editing
occuring either by moderation of content during the discussion, or
during collection after the fact.  There are currently two projects
underway to assist in this area.  Bother are after-the-fact as vs
pro-active. One is to provide a threaded, web-browsable, searchable
interface to past list traffic, and the other is to form summaries of
past threads, their outcomes, major points, models used etc.  <<Major
kudos to the people working on both>>

At this stage in the list's life I'm averse to attempting anything
like pro-active moderation or requesting greater format and topic
concensus from the membership.  When membership and traffic levels
increase enough (5x?), it may be warranted.  Until then the problem as
always is the list dieing in its own silence -- I've seen far to many
other promising lists go down the same chute.  Once you get a traffic
lag of more than a couple days the potential for the list to die
purely on the basis of its having been "forgotten" as the default
venue of topic X is present.

>What really annoys me is the inability of a thread to stay focused on
>one issue.  It often ends up with someone taking an example too
>literally, or making the worst assumption possible about an unclear
>sentence, or forgetting the original premises for the discussion.
>Still worse is that these offsprings, by their agressive nature,
>attracts so much attention that the original topic drowns completely.
>Quite often these offsprings manouver themselves to the same old dead
>end flame topics.

There are two ways to approach such: 

  1) Attempt to establish agreement up front with the other members of
the thread to limit discussion to a stated narrow theme.

  2) Have the thread topic definer champion the exact point he wishes
to discuss, and attempt to keep at least one portion of the thread
focussed on that specific aspect.

I'm not fond of #1.  I generally find that it stifles more signal than
it creates.  It specifically tends to stifle cross-pollination which I
consider invaluable in a venue like this.

#2 is what Caliban is attempting now with his interface thread.  He's
struggling to keep the conversation focussed on his specific point. 
It can be tough, and I don't envy him.  I suspect he'd more more
successful letting the thread fract, and then ensuring that there
remains a core dedicated to his pet topic.  This is the technique I've
found most successful.  

My general approach to this is to reply to any post on the thread as a
new post, treating it on its own merits.  This fosters increased
discussion and general signal content.  I then write a second seperate
reply to the same post picking out those aspects which pertain to my
pet theme, emphasising them as need be, and moving the pet theme
forward in a post which *ONLY* contains that pet theme.  This provides
a post which ONLY deals with my pet theme, helping to ensure that any
replies are also purely devoted to my pet theme, thus creating a solid
core of discussion on my pet theme as vs the theme diaspora.

Use of pet scenarios can be very useful here to concentrate attention
on the exact point wished, as well as to provide a commons strucuture
and framework to hang later extensions and debate off.  Scenarios also
provide a valuable shorthand during a topic's lidfe to refer to
complex ideas and details by minimal reference.  Thus we have things
like Bubba and the Crystalline Tree for state change monitoring, the
sceptre/castle Krak/Elven Forest for other aspects of state change and
spoof examples, The Great God GooGoo's holy relics for the canonical
case of programming paradigms and affects/Affects/spoofs, the Princess
and the Demon Wroth as the canonical spoof usage example, Bubba and
the panama canal for long running commands, UggUgg and the mana battle
for inapplicability of combat-unique commands, etc.  

Typically I deliberately trivialise or least-common-denominator the
aspects of the scenario which don't pertain to the exact point.  Thus
the "new" stuff stands out, and the "old" is both familiar and
assumable.  Usually this means assuming a stereotypically monty-haul
style hack'n'slash game with only the single new feature interjected. 


>As programmers we invest a lot of time and effort in a particular
>design, so we have a tendency of wanting to defend that design when
>someone are critical. Not because the design is a good one, but
>because we don't like the idea of having wasted so much time and
>effort! :-) Unfortunatly most designs programmers end up with is way
>less than perfect, simply because our desire to ease the
>implementation process.  Add to this the tendency of replying while
>reading a message and you are on your way to a flamewar (or a boring
>me-too).

This has happened here more than once, tho not not as frequently as
I'd feared.  I suspect it will happen increasingly often as the list
gets older due to older members, by now over familiar with certain
areas, presenting a daunting new members.  Historicially what has
often happened instead, is that while the original proponent may
abandon his charge, another member will pick it up and extend it.  The
language thread of about 4 months ago was a perfect case in point. 
The original postings were all but ignored.  Later, another member,
picking up on a different thread, referenced the original language
postings and brought in some new ideas.  Voila!  An active signal-full
thread on Languages was a'born and the original poster came back on in
in strength.  (Hope I remembered that right -- I think it was the
Languages thread that did that)

>I think it would be interesting if one could have not only
>"listowners" or "newsgroup agendas", but thread-owners.  That is, the
>person bringing up a topic could state some rules for replies to that
>particular thread.  For instance if the intention is to get as many
>ideas as possible, the thread-owner could state some brainstorming
>rules.

In a general sense, as a form of (attempting to) mandate concensus on
the thread definition I'm not fond of this for the reasons stated
above.  I'm also not fond of requiring a thread owner (not suggested
above), which has been prorposed before.  The problem is that it
provides an entry barrier to creating a new thread or proposing a new
topic (Oh dear!  I'll have to summarise this later, lets not bother).

The latter implicit concept above of following a structured ideas
development cycle (first brain storming, then...) is not one I've not
found workable with large groups (5+).  I have seen it attempted in
development meetings in software shops across the world and
participated in many.  I suspect it is also prone to the same
weaknesses discussed above.

Historically the list seems to have operated on an almost laissez
faire melting pot concept, with members acting as champions for their
own concepts or pet models (I actively encouraged this).  This was
particularly true in the technical discussions which formed the bulk
of the early traffic.  Such hard factual discussions encuraged such
aggressive ideas championing as they had strict physical metrics to
contain them (does it work?  Is it fast?  Is it resource expensive?).

In more recent months (since April?) traffic has been notably more
general, more hand waving in character as vs technical details of
implementation and design criteria.  Along with the influx of
non-server programmers, and RP'ers, this has lead to a large character
shift for the list, mostly it seems to a more loose discussion of
principles or possible feature areas.  ((Aside: Brandon's coverage of
macro probabilistic implementations is a wonderful crossover here that
is proving more than provoking)).  Such fuzzy discussions don't have
the easily verifiable metrics and constraints.  They are also much
more heavily prone to personal preference, style, and interpretation. 


The old model of competition between different models doesn't really
work any more as there are no models attempting to compete or validate
against shared metrics.  It makes for a particularly fluid thread
progression where there aren't necessarily solid conclusions, datums
reached, etc.  

The more general idea of a thread owner has been proposed several
times in various forms.  The most common form has been to have each
thread have a summariser who is reponsible for collecting all the
messages on that thread into one cohesive lump, and then providing a
summary, set of conclusions, etc for the thread.  I like this idea. 
The work required for even a modest thread is non-trivial however, and
many/most of us who have the expertise in the thread-topic, don't have
tht time to devote to collecting, summarising, etc.  I know I'd hate
to have to summarise many of the threads I've started.

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