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 | [EMAIL PROTECTED] | | GPG: http://bretton.hivemind.net/bretton_vine.asc | aibohphobia, n., The fear of palindromes. ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
