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

[Bretton Vine]

Brad Knowles said the following on 2006/08/31 05:36 AM:
> It's a known serious weak spot within the Mailman project, and we'd love
> to be able to resolve this issue, but that means we need to get some
> people onboard that are good at writing documentation.  Any suggestions
> you may have in this area would be gratefully accepted.

Well a lot has been generated in this discussion already, now it's just a
case of summarising it and having someone edit. I like writing, and would
happily contribute but I can drag on a bit so need a good editor :-P

> My preference would be to have a more sustainable growth pattern over a
> longer period of time, based on a higher quality product that we've been
> able to develop and field, then let the growth take care of itself.

Sounds like a good plan. In a world of build-it, grow-it, sell-it in 24
hours it's useful to have the voice of reason prevail.

> I think that the developers are well aware of this issue, especially
> since multiple other groups have taken the Mailman code and made
> unapproved changes to it, and then fielded that to their users -- but
> without providing adequate support for their modified versions and thus
> leaving us holding the bag they created.

Yes, my initial experience (relating to virtual domains on a single
installation) using third party patches took a lot of time to reach the
conclusion that was already summarised as:

"it's possible, but better to have multiple separate installations instead"

There wasn't a very solid connection between the source, the documentation
and patches. Lots of information, but no index (metaphorically). Lots of
pointers and usefool tools for searching, but no real "start here to do it
differently to the default" approach. In turn I had to settle on an
installation method, write my own HOWTO specific to our system and then
tweak it over time to remove what was unnecessary and add in what I missed
conceptually first time around. A useful exercise, but time-consuming.

> Indeed.  We do the best we can through what documentation is available
> (including the FAQ), but there's little we can do beyond that.

I disagree, I've found this discussion quite informative and sure others
have as well. What I mean is you can 'do more' than just code or write up
some documentation. Merely engaging the user base one-on-one adds something
more to the experience of learning.

After all, for most people it's more like this:

  user <--> support desk <--> engineer <--> developer

with lots of fancy but useless communication methods in between. I think
most people are eager to learn, just afraid of looking stupid by raising a
hand for a question (especially a frequently asked one)

> It only takes one
> loop that causes every message coming in to the list to be duplicated
> and then re-sent back to the same list (and duplicated again, ad
> nauseum), to bring down the whole system.

I know. And embarrassing when you're the last to find out <chuckles>
I understand Mailman is superior to Majordomo in this respect, or is this
configuration dependant?

> These are powerful tools we're talking about here, and it's easy to do
> things to wind up accidentally shooting yourself in the foot -- or maybe
> accidentally shooting your neighbor in the head.
> With powerful tools, you also need powerful safeguards.

No disagreement. But safeguards are merely insurance when you have proper
education in how to use tools no? As opposed to a necessity due to gaps in
the knowledge chain.
(i.e. the safety line is not intended to be used as a hand rail)

> So, it's up to the site admin(s) to look through the defaults we've
> provided to them and decide which ones they want to change for their
> customers, and it's up to the list admin(s) to look through the defaults
> they're given by the site admin(s) and decide which ones that they want
> to change for their customers.

Thanks, you've just illustrated a point I often try to make. Ultimately the
proverbial 'you' drives the computer. You're responsible for what it does
and doesn't do. Mistakes happen, but so too does random knowledge ... you
know like you pick up a new short-cut you didn't know by watching someone
else do it fist.

Actually, if you're in an environment with lots of people interaction,
showing them a short-cut is like a good dead of the day, and in terms of
user-interface spreads nicely. Trouble is all the arcane knowledge is locked
up in the heads of people who spend more time in front of a pc than people :-)

> I submit we've done our job for our customers, and it's up to them to do
> their job for their customers, and so on.

Ok, sounds fair. I'm a customer. I want to understand why things are done a
certain way. I want to know why they're no done differently, and I'll be
stubborn and even try it myself until it stops working. I'm not about to
embark on learning Python just to understand Mailman (although it would be a
useful exercise in a broader sense) but I do wish documentation had the same
level of diligence and peer-review that the code gets (not specifically
mailman -- software in general)

I can point my users to documentation and URLs but I can't make them read :-)
-- 
| Bretton Vine | 083 633 8475 | bretton at hivemind.net |
| GPG: http://bretton.hivemind.net/bretton_vine.asc  |

If you're not failing every now and again, it's a sign you're not doing
anything very innovative. - W. Allen