[Mailman-Developers] Some improvement suggestions

[Ken Manheimer]

Some of the other people here at cnri are using mailman, and they've
hit up against one small change needed.  I thought i'd mention it
here, in case anyone gets the chance and inclination to address it.  I
also have one other item which i would really like to do, but the
eventuality of actually doing it may be less near than i'd like
(especially since i'm going away for a week, and there's all that
catch-up time on return).

The first item is the ability to edit the new-member welcome message.
We offer list managers the ability to edit the html pages, and they
get to see the way the magic refs (eg, <MM-List-Name>) are used on the
template to see how they could use them for their own versions.  Well,
there is a number of standard mail messages, including particularly
the welcome message, that they may want to edit.  (IN FACT, two
different groups, separately, came to me today with the need to edit
the welcome message - for different reasons!  A sure sign...)

I think we would have to change the format substitutions, currently
all the "%s" order dependent style, to be "%(real_name)s" dictionary
substitutions, and otherwise do the same kind of thing we do for the
html templates.  (Ah, i see barry's done that in some recent
checkins.)  There is a bunch of messages, some which may benefit from
this treatment, other might just clutter the list admins choices.

Along these lines, there's something much more encompassing i'd like
to do or see done.  I'd like to extend the handling of list admin
options and html templates so list-specific versions are only
squirreled away in list-specific space if and when the list admin
changes them from the default.  This way, the central administrator
could change the template or default values, and the new value would
show for all the lists that haven't tailored their own versions.  This
would certainly be suitable for something like the html pages, where
site style changes need propagation, and also for stuff like the
forbidden posters.  It may not be suitable for some others.

This should be easy for the template files - just don't stash
list-specific copies until an edit is made (and the edited copy
differs), and use the default template if no list-specific one
exists.  It'd also be good to offer a way in the edit interface to
revert to the default version, wiping out the list-specific copy.

For the list admin options, we'd need a new field in the options data
structure specifying the *name* of the default value, and likewise
some way for the gui option for the list admin to explicitly revert to
the default.  Maybe there should be some way to have a locked-in
list-specific setting, even if it doesn't differ from the _current_
site default.  And then all the routines that use the list admin
options will have to mediate through a routine (or options mediator
object) that takes the name of the option and gets the default value
when suitable...

Well, i hope this is at least slightly understandable, if quick - i
gotta run.  C ya later!

Ken