At 9:32 PM -0500 1/6/99, David B. Smith wrote:
> Extended debates with folks about how they oughta be doing their own
> un$ubscribing doesn't contribute anything to a discussion of the
> relationship between death and law. Teaching folks how to use the list,
> however laudable, doesn't either. The discussion is -the- purpose of
> the list.
That's why I do all of this via private mail, and if it pops up on a
list, take it private as quickly as I can. I also step heavily on
these meta-topics, which sometimes upsets folks, but you're right.
Lists are for the topic, not meta-discussions about the list the
topic is for.
And I get the occasional REAL idiot who insists on answering my
private e-mail ON the list, but those trolls prove themselves out
really quickly. And I have, in fact, been known to delete a person's
POSTING priviledge while we contintue to discuss fine points of
netiquette privately. But you have to be a really nasty troll for me
to pull that one. That's not my normal operation.
> I would prefer that the users deal with those mechanisms themselves.
> But if doing it for them (from time to time) prevents interference with
> the purpose of the list, then that's what I'll do.
>
> If asked nicely, I'll explain. If not, I'd just as soon cut them off
> myself.
My policy is really simple. My lists are self-protected from the
usual administrivia. A user has to work REALLY hard to actually get
one of those requests through to the list. usually, one of my filters
catches it and sends a nice note back on how to do it right. Most of
the time, the next thing I see on my system is the proper unsub
command, and it's all over.
If it *does* in fact get through, amusingly enough, each message has
the unsub instructions on it. Most users who haven't noticed those
instructions BEFORE then notice them on that instruction, and that's
it (I find that an interesting side effect, by the way. But in
general, putting the information in a footer has more or less made
this problem go away for me. I have very little administrative
thrashing any more)
If they send mail to postmaster/etc, they get a mailbot back that
points out this isn't how unsubs are done, gives them the info on how
to do it, and tells them what to do if they can't make it work right.
In my case, the "secret password" is including copies of the attempt
to unzubscribe (or whatever) and the returned messages, so I can see
what's going on.
If I just get the blind "unzubscribe", I let the mailbot answer it.
If the user includes the attempt, I'll generally take care of it for
them. Ditto if the user is clearly upset/angry/frustrated, because
I'm here to be helpful, not anal about following instructions. This
seems like a solid tradeoff between encouraging users to help
themselves and turning this into a trivia contest with the users
freedom as the prize.
It also gives me wonderful feedback on where users are getting
sideways in the system, confused by the daemon, lost in the
documentation, or whatever. So if I start seeing trends in the
errors, I can focus on improving THAT problem and make it go away.
It's been quite useful in cutting error rates, although I'm not done.
Right now, my servers are averaging between 1,500 and 2,000
successful subscriptions for every "this server is too damn hard to
use" complaint, and that's not a bad percentage.
I've got three major projects left in the server make-it-easy
projects, and then I think it'll be about as easy as I can make it
based on what I know now.
FWIW, here are what I think are the key improvements people can make
to reduce user hassle. Unfortunately, this more or less requires the
ability to whack at the daemon level. If you just admin a list that's
run on a server managed by someone else, a lot if out of your control
here. My daemon is majordomo, and it's effectively vanilla. A couple
of minor patches, but I've consciously avoided whacking at the
source. Instead, I've built around it.
1) listname-zubscribe and listname-unzubscribe addresses. On my
system, these actually talk to perl scripts that suck the email
address out of the header and format mail commands FOR the user -- so
that a blank mailto: message is okay. Cut out the zubscribe jargon
completely. On the plus side, it makes the web interface pretty
simple, "click this link and send the message to subscribe". It
assumes that they (or *someone*) has configured their mail client
correctly. I find this to be a LOT more reliable than asking them
what their address is. Really.
2) unzubscribe-all address. Basically, a panic button. Very useful.
Very simple. Just remaps into an "unzubscribe *" request for the
address it was mailed from. The only bad side of this is that "unzub
*" is amazingly expensive computationally. I've experimented with
alternative front ends, but they're not much better so far. My answer
right now is to stuff these into a special sendmail queue so only one
is being processed at a time so they don't clog my other processing.
3) unzub/help info in the footer of every message, and header of ever
digest. I don't even bother with monthly help files or other regular
postings any more; my user studies have shown pretty conclusively
they're useless. Users tune them out, so I don't waste bandwidth any
more.
4) Every list alias (and the majordomo alias itself) is front-ended
by procmail, where I've scripted a whole bunch of safety checks and
other tests. I've got pretty solid protection against vacation
messages and mail-loops-from-hell, I have certain naughty word
restrictions (and some of them turn out to be non-trivial. Just ask
Igor Livshits). I have a blackhole, a greyhole (the difference being
whether you get a polite "go away" or not), and a no-posting test.
And the administrivia tests. And a bunch of other stuff. But
basically, all of the common stuff that ought to be trapped out of
the lists is, to keep it off the lists.
5) situational-specific help files. The only thing I've found is
*more* useless to the typical user than the "monthly help file" is to
send a message to the daemon, get it wrong, and get sent back a 10K
"help file" where the user (who's already confused, lost, naive,
irritated, frustrated or all of the above) has to guess where in the
help file the answer to his question is. So I've simply written a
bunch of filters that catch as many of these errors as possible, and
say "here's what you did wrong. Here's how you should do this. Here's
where the help files are for more information. here's how to contact
a human being"
(One could argue that if I'm smart enough to catch it, I ought to fix
it and do it for them. this is a religious argument, and both sides
are probably right. Religiously, I'm on the "give the man a fish and
he'll starve next week, teach them to fish and he'll invite you over
to dinner for some nice halibut" school. I won't argue. No need to
fight with me on this, I won't change my mind, you don't need to
change yours)
I can't over-emphasize the situational stuff enough. If the user knew
the answer, they wouldn't need help. And simply tossing the majordomo
help file at them isn't answering their question. they probably got
that already, and it didn't help them the first time. And if you can
teach your list serer to ANSWER their question, you don't have to.
But you have to answer the question, not just toss a big glob of help
text at them.
The two biggest problems I have these days are changed (and third
party) addresses, and the majordomo mailback authorization stuff.
These are intertwined -- users want to zubscribe aliases, hotmail
addresses, etc to lists, but it's a fine line between this and
allowing spammers to forge-zubscribe other addresses. Right now, I'm
taking a fairly strict line on this (and it only affects under 1% of
my users, based on the complaints I get), because I'm real sensitive
to the spam issues, thanks to the well-meaning but truly
brain-cramped Apple supporters who thinks the answer to every guy who
says "macs suck" on IRC is subscribe them to a hundred pro-Macintosh
lists. No thanks, I get tired of cleaning up after the kids.
The biggest single problem *I* have today is that 40% of my potential
subscribers never respond to the mailback validation request. If they
*do* respond, the error rate is quite low (about 2%), but that's too
many dropouts for my taste. so I'm designing systems that'll be
secure, but easier to use. And which, as a side effect, will
completely allow the alias and hotmail addresses without opening up
spamholes. (bad news for some, it'll be both mac-based and web-based.
Good news for me, there's so little no-web-based subscription traffic
for my stuff now that this isn't a problem....)
That and the endless (it seems) need to keep revising documentation
to keep ahead of the typoes that seem to magically creep in at
night....
--
Chuq Von Rospach (Hockey fan? <http://www.plaidworks.com/hockey/>)
Apple Mail List Gnome (mailto:[EMAIL PROTECTED])
Plaidworks Consulting (mailto:[EMAIL PROTECTED])
<http://www.plaidworks.com/> + <http://www.lists.apple.com/>
Featuring Winslow Leach at the Piano!
