[Mailman-Users] Re: remove this?

[J C Lawrence]

On Wed, 09 May 2001 01:09:26 -0500 
Bill Warner <lww at ictech.net> wrote:

> In the end, I think that any disagreement we may have over this
> issue is actually philosophical rather than technical.
> Personally, I am a firm believer in the guiding principle of the X
> Window System which always seeks to "provide mechanism, not
> policy."  If you apply that principle to this issue, then you
> conclude that Mailman should implement the mechanism for sending
> RFC2369 headers, but the policy decision of which, if any, of them
> should go out on a particular list should be left to the list
> owner.  It's obvious that many here disagree with that design
> philosophy.  So be it.

There is a critical difference.  X does allow you and even makes it
very easy to do damned near anything you want, encluding being
incredibly stupid and making bad decisions.  In a general light,
this is not a Bad Thing.  One critical aspect however is that should
you do one of those stupid things you only break/damage yourself
(person running the broken app).  A perfect example is X server
grabs.

With mail that's not the case.  One change affects hundreds if not
thousands or millions of people (we're getting lists of that size
now).  Yes, you can still do stupid things and write your own
policies, but the system instead of being geared to allowing that,
is instead geared to, "Make it easy for him to be a good netizen and
hard for him to cause us pain.".  There are too many other easy ways
to cause pain on the 'net to go around making it easy for there to
be more.

> It has also been said that because this is Open Source, I already
> have the ability to control this header behavior by hacking the
> source.  True enough, and I've already done that for my
> installation.  But I submit that deliberately making this kind of
> thing harder than it has to be, a kind of "Father Knows Best"
> attitude, is antithetical to the roots of todays Open Source
> movement.

If Father Really Knew Best, the source wouldn't be out there.  

> Unfortunately, if you don't buy the "mechanism, not policy"
> approach then you probably won't buy this argument either.

Actually I buy and agree with both arguments, I just consider them
misplaced in this case.  They work very well elsewhere.

>> and that's only to people with cruddy mail clients (consider it
>> an incentive to upgrade to soemthing decent).

> Unfortunately, the people I have to deal with don't see it that
> way.  They don't want anything to do with upgrades or
> reconfigurations.  

This sounds like your users need a FAQ.  It also sounds like they
may need some education -- often a Good Thing in any case (I
occassionally invent excuses for it with my list members).

There is a view that in the end the customer is always right and
that the provider therefore must (or will) always end up doing what
the customer wants.  This is the view that places the customer as
the 800lb gorilla and everyone/everything else as fleas sucking
their blood.  There is also a view that the provider vends the
service and the customer either accepts it or goes somewhere else.
Similarly, this is the vendor as the 800lb gorilla and everyone
else, and in particular the customers, as fleas (picking the host to
suck blood from).  The truth is somewhere in the middle.
Customer/vendor relationships are sympathetic not parasitic systems.

While arguably the September that Never Ended has, as promised,
Never Ended, in many ways it has actually begun to end.  The great
'net unwashed are not the uncontrollably 'net-cluefree barbarians
storming the castle they once were.  'Net life has improved, or, to
be excessively patronising, they have shown a capacity for learning
that was not at first obvious (the early days of Sept were bloody
and few bothered to observe the delicacies among the storming
hordes).  

I'm a believer in the relationship being balanced, and for that
balance to lean in my direction as regards use of my time and
effort.  I am not gentle with my list members, but I do respect them
and I will get their respect in turn or they will not post to my
lists.  I require them to follow my formatting rules, my quoting
styles, to attribute all quoted text, to not use HTML, to not
marketeer, to always be on topic, to always at least head towards
signal, etc etc etc just to have their posts considered bor
acceptance on my main list (other lists are more open).  And they
do.  They have changed and learned, and conformed.  And I've made
damned certain that I've returned value to them for their effort,
balancing the equation.

You've got to balance the books in their eyes.  The ROI must be very
clear.

> While the customer is not always right, you sometimes have to
> pretend that they are.

Sometimes you need to tell them they are wrong, why they re wrong,
and that you are more than willing to help them build and run
correct systems.

Trade offs.  The high road.  Those that leave are typically
(experience) better off gone, and (experience) their replacements
are much more valuable and numerous.

> [Oh dear me, I went and said the secret file name on the list, now
> everyone has the dangerous knowledge of how to get rid of the
> pesky RFC "mandated" List-* headers.  Whatever shall we do now?]
> Ahem, sorry (sort of) about that, but I really couldn't resist.  I
> know, childish at best...

Hehn.

A patch, instructions and considerable discussion of the area is
already sitting in the archives and available by search engine.  Not
a question of censorship, but a question of encouragement or lack
there of.

> So given that reality, what's so wrong with asking for an option
> that allows me to more easily control this trade-off?

Nothing wrong with it at all.  The only questionable aspect is in
expecting or demanding a conciliatory response.  I posit that you
received considerable help in your quest; in pointers to the RFC,
discusion of the header's values, and a pointer to the archives
where lives a patch and prior discussion.  The problem it seems is
that that was not the help you though you were looking for...

> I guess that's a rhetorical question, but as far as I can tell the
> only thing wrong with asking this particular question on this list
> is that people here are already entrenched in their positions on
> this issue.  

We've been through three prior lengthy discussions of the area, two
this year previous to yours (both much longer and more detailed).
I'd look at it less as a question of entrenching as good certainty
on a good decision well made and a fairly high burden of proof
required of those questioning the area.

I consider NFS to largely be a virus.  Alone, that's an unsupported
claim and I'm quite rightly laughed at for it.  When I support it
with arguments surrounding locking, file system semantics, fault
resilience etc I've demonstrated some of the burden of proof
(whatever your views on the validity of the arguments) to make the
assertion credible (other's of course disagree).

First you have to climb the mountain.

> In that case I highly recommend that the next time this issue
> comes up, as it surely will (which might be some kind of a clue),
> those who are tired of it, or offended by it, just ignore it.

Nahh, it should really go in the FAQ.  That's what FAQs are for.

> We now return you to your regularly scheduled program about how to
> get Mailman to run on the Linux flavor-of-the-day...

Yea gods save us.

-- 
J C Lawrence                                       claw at kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows