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.