[Mailman-Users] query re "message has implicit destination" (devils advocate!)

[Bretton Vine]

Brad Knowles said the following on 2006/08/31 12:09 AM:
<snip useful comments>
> We prefer to have this option default to "on", because it is safer that
> way, and people can always choose to set their choice to be more
> permissive. 

(locally) it's been referred to as a "be strict in what you send, relaxed in
what you receive" approach but not everyone adheres to (or is aware of) this
way of looking at things and it seems antiquated to some.

I *know* the developers develop according to their needs, and needs change
with time and input. And the openness of the GNU approach allows anyone to
modify at will (provided they have the skill), and heck no-one likes
documenting stuff but someone has to do it.

But many people will choose a Mailman solution on the basis of cost and
relative availability of help and support. Plus Mailman has largely
dominated what was previously a majordomo or listserv orientated world.

Just because a 'default option' seems sensible and obvious to implement from
a developer perspective doesn't mean you can avoid having to explain it.
This is a frustration I personally have as I'm often the person documenting
things smarter people do on the network I look after.

No matter whether you're a core developer, patch developer, documentation
person, or verbal user, people are going to use your product. It's either
going to be good, or outright crap. And even when it's the best solution
available, and all the right decisions have been made in implementation
design, users may choose something else because it's *more shiny*.

And sometimes users may become irate at your implementation of a solution on
their behalf and decide they can do it themselves, only to repeat all the
same mistakes you made and end up at the same end result -- feeling like
fools but too embarrassed to return and ask for your help.

In a commercial environment this is quite costly to both parties so avoiding
that situation leads to more successful/stable product iterations (not to
mention $$$)

Ok, granted, no-one's specifically 'selling' anything here. That doesn't
negate responsibility for the default options though. It's insufficient to
give people an "option" to change something. Some need to know why/how/what.

</wipes froth from mouth>

> kinds of problems, especially if those sites tend to be administered by
> less Mailman-savvy personnel, since a great deal of damage could be done
> in a very short period of time.

I have lots of experience with non-list savoy people, from list-owners to
list-users. Few of them are inclined to actually /look/ for an answer. It's
much easier to ask someone else. And in many cases a sheep-like mentality
occurs where people do things a certain way because "that's just the way
it's done" or "things _may_ go wrong if we do it differently".

Think of a lowest-common-denominator list user. What would you recommend as
an OS interface to them? osx or windows or linux or even dos? Now apply the
same basic principle to a web-based list-administrative interface. Throw in
some experienced majordomo users for good measure, along with some people
that are unaware of anything other than a browser called IE exists and give
them full control of their own lists. Seriously, what's the worst that can
happen -- someone learning from mistakes, something we do naturally?

In my experience, presenting the end user with all the options early on
(with clear explanations) leads to a more rapid and confident learning curve
than giving them permanent training wheels and no explanation. Takes a bit
more effort, but the rewards are well worth it. But at the same time you
have a market that wants a one-size-fits-all solution. Catch-22.

A mailing lists key function is to act as a list. Not as a spam filter. Sure
it's a useful extra, perhaps even pretty-bells-and-whistles useful. But does
it actually contribute anything to the core function, or add any value that
can not be achieved from within the mail system itself?
If not, why is the default set to "on"?

Another school of thought evident in many .conf files I've seen is something
like the following:

# Uncomment the following line to enable $functionality. This setting is
# disabled by default because it is important you understand why it exists
# and actually turn it on purposefully (which is what we suggest you do)
# See http://..... for full explanation
#
# Functionality = 1

regards
-- 
| Bretton Vine | 083 633 8475 | bretton at hivemind.net |
| GPG: http://bretton.hivemind.net/bretton_vine.asc  |

aibohphobia, n., The fear of palindromes.