[Mailman-Developers] Mailman limitations

[Harald Meland]

[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