[Mailman-Developers] Mailman limitations

[Thomas Wouters]

On Sun, Feb 13, 2000 at 07:18:58PM +0100, Harald Meland wrote:
> [..] it shouldn't be too easy for Mailman list administrators to
> misconfigure their lists in a fashion that discards (or, possibly,
> rejects) incoming messages -- as that might lead to Mailman seeming
> reckless with incoming messages.  Deciding upon exactly what "too
> easy" means in terms of implementation is, of course, the hard part.

This is indeed something to keep in mind. But Mailman is, in my opinion,
nowhere near complicated enough to make it easy to misconfigure it. Yet. But
before any new flashy splashy administrator options get added, there is this
problem you mentioned, already, namely

> Next, there's the issue of not over-complicating the admin pages.

This problem ;)

> Ideally, we'd like to support as big a set of (good :) features as any
> other mailing list administration package, but without alienating
> first-time Mailman list administrators through a veritable maze of
> list settings, all of them interconnected...  Good documentation might
> solve part of this, but if there are (overly) complex features the
> corresponding documentation will probably have to be complex as well,
> meaning that the Mailman learning curve gets steeper.

Exactly. And let me tell you that good documentation is not enough if the
first look the fresh administrator gets of his new list is as complicated as
the bridge of the USS Enterprise. This is just about the case with our
current majordomo lists -- people want a list ? We give them one. They want
to configure it ? Let them read the manpage. This went well when most of our
customers were techies, but that day has past long since ;) The current
batch of list-owners freak out when they see the majordomo config file they
have to edit and mail.

However, I dont think redesigning the adminpages to make it all fit AND
appear sane, is impossible. I think it can be done with just a little bit of
thought ;) Currently, the admin page is, to be frank, overwhelming. The
moment you open the page, you get a large list of options to select from.
Some of these are useful and clear. Others, most, are more-or-less obvious,
but not of interest. And some are plain weird. You do your best to browse
them and edit them to your need, and then you look up, and you see that you
have *seven*more*pages* to do ! AND three more pages, which may contain more
links, of other administrativia !

What needs to be done mostly is just creating more but smaller pages,
especially for the current 'general options' and 'privacy options' pages,
plus for whatever options are added. Perhaps a more hierarchical layout is
in place, where you have 'general options', 'advanced options' and
'Membership management' (which isn't really about options anyway.) General
options would contain a few simple starter settings, like the first few
things in the current general options page, the things that are obvious from
the start and most people want to change, or at least think about.

The advanced options page would be either a page with a selection of
sub-menus, or a large page of options. (Or a number of options, like we have
now, but more subpages) There are a number of topics that require several
settings each:

- Membership and list exposure (with default hostname and such).

- (Un)subscribing, the default reject message of refused (un)subscribes.

- Message refusing/holding based on various headers and such, with their
respective default reject messages (perhaps a seperate page for refusing and
one for holding ?)

- the current bounce, (non-)digest member, archival and newsgateway option
pages.

And each page should be set to sane defaults, which is mostly the case
currently. The 'help' on some of the options could be a bit more guiding,
though. 'Dont touch this unless you know what you are doing', 'it's safe to
leave this untouched,' etc. Like the Linux kernel configuration ;)

(While I was writing this and thinking it up (in that order ;) I thought how
incredibly cool it would be to have some kind of rule-based message
acception (/refusal/holding/discarding/temp-fail/...) system, where each
rule could be header-match, number of postings to the list so far, load of
the machine matched against a priority for the list or user, time of day or
whatever. And where each rule would have it's own default reject/accept
messages, of course. Not very hard to implement in Python and the current
'pipe' architecture, if I may be so kind. But for the life of me I can't
figure out how to make such a scheme configurable through an HTML page ;P)

> > I can't say for certain what parts are currently being developped,
> > though, I'm relatively new on this list, and a lot of development
> > seems to happen behind the scenes.

> I'm not quite sure what you mean by that, but just to clarify: I try
> to keep/redirect whatever discussions on Mailman development I get
> involved in to this list.  However, I've "been away" for some time,
> busy doing Real Work -- part of which was to implement new Mailman
> features that we here at uio.no were in pressing need of.

> I don't want to give anyone the idea that the direction of Mailman
> development is not properly influenced by the input from the members
> on this list -- after all, discussing Mailman development is what this
> list is for.

I'm sorry, I didn't mean to imply that this list was defunct, or that
mailman development is dead, or that people are wasting their time waiting
for the developers, or any of that. It's just that I dont see the lively
discussions I'm used to (on, granted, *much* bigger projects and *much*
bigger lists;) and Barry mentioned the i18n 'effort' which I hadn't heard a
single bit about.

Now that I read that bit back, I must apologize for the way I wrote it. The
'a lot' is definately uncalled for, and most of the rest was written
half-asleep, probably. Or maybe I hadn't realized how busy the cabal is --
having a fun project (Mailman) highish on my priority list for once makes me
slightly impatient. I'm almost cured now, though, I'm facing some really
Hard Time, writing Perl and all. ;)

I shouldn't complain, anyway. Most of my patches have received good
commentary, and one even got applied ! haven't gotten that far in any other
project except at work, yet ;)

half-asleep-again-ly y'rs,
-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!