[Thomas Wouters]

But Mailman is, in my opinion, nowhere near complicated enough to make it easy to misconfigure it. Yet.

With a few exceptions (read: weird special cases), I agree.

...

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.

That's what the "might solve _part of_ this" stuff was meant to imply... ;)

However, I dont think redesigning the adminpages to make it all fit AND appear sane, is impossible.

But, are "sane" and "user understandable" interchangeable? (Sorry, the bofh part of me took control there for a minute :).

I think it can be done with just a little bit of thought ;) Currently, the admin page is, to be frank, overwhelming.

Yup -- that's the reason I'm somewhat sceptical to accept patches for new "special case" features.

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 !

I guess this is a bit like what kind of stereo systems people prefer -- some people want the one with the most buttons (and flashing lights), while other people just want something that *works*. :-D

Some time back, someone asked whether it would be possible to have different "styles" on the list admin pages -- i.e., the more techish admins would get the full (overwhelming) set of admin settings, while newbie admins would get a (much less confusing and) smaller set of the most commonly used list settings (possibly with the option of getting access to the full set of settings if they e.g. followed some "for expert list admins" link).

Which set of options to present to the admin could either be settable per list or per admin (when we get the user database in place).

There have also been a little talk of even more generic solutions to this -- e.g. implementing list configurations as inheritance hierarchies, so that a change to the "base" configuration would automatically affect all the lists that inherit the attributes that were changed but don't override them.

<rant> However, it seems to me that every time we start discussing advanced web interface stuff, someone mentions integrating Mailman with Zope -- which it is said would buy us a lot of neat features practically for free -- and people go "Yeah" and "Cool" and "Sounds like a perfect match"... and then nobody actually _do_ anything about it all. :)

Should Mailman be integrated with Zope?

Would such a change mean that Mailman has to _rely_ on Zope being installed, or would it be feasible (and resonably easy) for Mailman to take advantage of Zope only if it's available (at run time? Or at install time?)?

What advantages would such a change buy us?

Are there things we want to do anyway, and which would _have_ to be changed to integrate with Zope, and thus could be started work on right away?

Should all of this wait until after the next Mailman release is completed? ;)

Is my ranting about this at all called for? ;) </rant>

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.

To me, having a tangle with lots of different pages with few options on them isn't really much better than a tangle with lots of options on a few pages. The _real_ problem is to avoid the tangle. I agree that the structure of the current admin pages aren't optimal, though -- but restructuring the pages will only take us so far if we start adding specialcase code left and right.

(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)

That's *exactly* the way I feel about that stuff. :)

Of course, you could just let the admin edit the rules as pure text -- and then have the CGI script do the appropriate syntax checks and other sanity checks/rule validation before actually changing the list's configuration.

Of course, that would mean we're _very_ close to significantly affecting the slope of Mailman's learning curve.

...

...

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.

Good -- and I tried to phrase the above in a way as not to suggest that I thought you did -- it was meant purely as an clarification, not as some kind of an accusation.

It's just that I dont see the lively discussions I'm used to

I can relate with that -- but I can't really figure out why that's how things are here at mailman-developers...

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.

You want us to believe that normally you're _not_ impatient? Yeah, right... ;-D

I shouldn't complain, anyway. Most of my patches have received good commentary, and one even got applied !

Well, neither should we... just keep'em coming.

Cheers,

Harald