[BALUG-Admin] how to (and not to) post to lists, etc.

[Rick Moen]

Here's an instructive case-study:

----- Forwarded message from balug-announce-bounces@lists.balug.org -----

From: balug-announce-bounces@lists.balug.org
To: balug-announce-owner@lists.balug.org
Date: Sun, 18 Jan 2009 08:05:58 -0800
Subject: 15 BALUG-Announce moderator request(s) waiting

Notice: 1 old request(s) automatically expired.

The BALUG-Announce@lists.balug.org mailing list has 15 request(s)
waiting for your consideration at:

	http://lists.balug.org/admindb.cgi/balug-announce-balug.org
	
Please attend to this at your earliest convenience.  This notice of
pending requests, if any, will be sent out daily.

[snip a lot of held spam]

From: john_re@fastmail.us on Sun Jan 18 02:53:09 2009
Subject: RSV #'s - Re: [BALUG-Announce] BALUG: Tu 2009-01-20 Kyle Rankin on Where'd my   files go?
Cause: Post to moderated list

[snip more held spam]

----- End forwarded message -----

That was, of course John Regan, attempting to respond conversationally
to Michael Paoli's meeting announcement _on balug-announce_ -- which
reply mode is of course is antithetical to the fundamental notion of an
announce mailing list.

Fortunately, we have and use the technology to _not_ allow through such
postings by default, so I was able to return John's posting to him with
a gentle reminder:  "Sorry, John, the balug-announce mailing list is
for, well, announcements.  If you need to comment in response to an
announcement posting, you need to send it to the poster personally (in
private mail) or post your comment to whichever of the _discussion_
mailing lists is appropriate."

Now, imagine that we did _not_ have the technological means to intercept
and return inappropriate postings to balug-announce.  What would we have
in its place?  A rule.  "Only meeting announcements from designated BALUG 
staff may be posted to balug-announce."

Then, about every month or so, member A would screw up by posting
something conversational, and get yelled at.  Member A would give the
traditional responses:  "Well, I didn't know / didn't understand.  And I
didn't mean any harm, so surely that makes it OK.  And it's not my
fault, because the rule wasn't clear enough."

A week later, member B, professing to be unaware of any of the affair, will
follow suit with another inappropriate posting to balug-announce.  After
getting yelled at, he/she will cite all of member A's excuses, plus add
a new one:  "Besides, I saw member A's conversational posting, and
naturally concluded that it's OK to post that way."

Members A and B now have a need to justify themselves retroactively, so
they go around arguing their point of view, and that the listadmin is
just a tyrant who wants to beat up on people.

The point is, that sort of dumb social dymanics is difficult to avoid,
in technical media used by volunteer groups, when bad behaviour is
perceived as being enforced only by rules that are to be, essentially,
self-applied.  You get people arguing their innocent intentions, you get
people arguing that they're exceptions, you get people arguing that the
rules are unjust or somehow up for debate.  The more types of
misbehaviour you add to the list, the more the list tend to serve as
notice that "People screw up a lot, here, and this is a roster of all
the most popular ways _you_ can do it, too."

And all of that goes away if you make a particular type of bad behaviour 
simply impossible to indulge, and automatically rejected -- as we do
with conversational replies to balug-announce.  (And the bizarre thing
is, one almost never gets any dumb backtalk, when enforcement is
automated that way.  Suddenly, it's perceived as no longer a matter up
for debate, but rather just "the way things work".)

Now, am I saying there is never any point to documentation on what to do
and not do?  No.  Some of it's quite classic, e.g., Brad Templeton's
"Emily Postnews Answers Your Questions on Netiquette",
http://www.templetons.com/brad/emily.html .

The central problem is one of the role such documentation ends up
occupying, which is not necessarily what the drafters intend.  You write
it with the intention that people will read it on some timely occasion
and think "Oh, this is how I should behave on the BALUG mailing lists
and not be perceived as a dipstick."  But most people won't read it at
all; most of the few who do won't do it in a timely manner, _and_
they'll tend to read it with automatic "sales resistance":  "Oh, this is
what some self-appointed czar at BALUG _wants_ me to do and not do.  Why
should I do a favour to this person?  What's in it for me?"

In other words, you intend it as a free clue, but the general population
are socially conditioned to reject the value of anything free, anything
they haven't sought out and paid for.  If you're handing out something
for free, there must be a catch:  You must be, somewhere, somehow,
angling for them to do you a favour.  It's being urged on you, so it
must be a sales job.  Sales jobs are to be resisted.   If what you're
suggesting is also inconvenient to the reader, e.g., requires thinking
before responding on balug-announce, then that clinches it:  The reader
implicitly assumes you're trying to pull a sly one, and should be argued
against, lest you finagle a favour from them for free.

In the Linux User Group HOWTO, I talk about this syndrome as a clash of
value systems:  People are conditioned from birth to apply the concept
of _acquisition value_ to everything:  It's worth what you paid (at
least, to a first approximation).  Anything someone's giving away must
be worthless, at best, and probably has hidden costs.  In the open
source world, we tend to apply _use value_ to things:  Something you
receive had value based on what can be done with it, irrespective of
what its original price was.

Many of the worst social problems of user groups arise from conflicts
between these value systems (or rather, failure of some parties to apply
use value because they're so conditioned to the other way of thinking).
E.g., an outsider enters and treats with contempt the feedback of
experts that he/she needs to be more specific in his/her questions, 
because, after all, who do those people think they are?  Why, the
ousider thinks, he/she isn't paying them a penny, so how dare they not
just get hard at work on his/her vague and sloppy demands?  Obviously,
their time and effort is worth nothing, or they wouldn't be handing it
out for free.

This problem applies in spades to documentation, especially
documentation of proper conduct.  When people come across Emily
Postnews, it's usually in the context of _them_ seeking out either
netiquette pieces, or humour pieces, or both -- so Templeton doesn't get
a continual backlash of sullen resentment and resistance.   But a user
group that says "You should do [foo] and not do [bar]", it _will_ get 
sales resistance, backtalk, and the attitude of "they must not be
serious, because they're talking too much".

So, in general, I recommend application of technology, over posting of
rules.  Make physically impossible every form of dipstick behaviour you
can, and you'll get no arguments.  (E.g., tell Mark Weisler to simply 
_not hand the microphone_ to the alcoholic who recently resigned the
SVLUG presidency, and you'll not have to endure a slurred 20-minute
incoherent speech that wasn't on the meeting agenda.)

There _is_ a place for posted rules:  That's where you point people to,
after they've screwed up, or tried to screw up and been blocked, as a
way of saying "You had no excuse, and continuations will result in
stronger measures" and making clear you mean it.  You want the posted
rules to be super-terse and as few & minimal as you can make them.  

http://lists.svlug.org/lists/listinfo/jobs is a decent example.  Because
jobs mailing lists have a particularly severe abuse problem, the list is
moderated, which is rare.  When I have to reject a post, which happens
frequently on that particular mailing list, I politely point the poster
back to that page and cite which rule or rules they failed (usually #1
or #2).  Note that the top of the "listinfo" page is the ideal place for
rules:  Any subscriber pretty much had to see that page, when joining.

Last, one caution:  There's a natural tendency among computerists to
think that, if people are screwing up, the problem must be that you
didn't explain well enough the first time.  So, you deluge the user with
additional detail -- which generally doesn't work either.

The fallacy lies in the assumption that your existing explanation /
documentation was insufficient.  More often, people screw up because
they just don't give a shit, or they weren't paying attention.  Or they
think that following rules and reading documentation is something one
does only when forced.