Sean responded to a bunch of Rick's points, and I'll just add a few more thoughts.
"RN" == Rick Niess <rniess@netserver3.otr.usm.edu> writes:
RN> 1) Please add an option so subscribers can elect to show only
RN> the username part of their e-mail address in the subscriber
RN> list instead of the whole thing (regardless of the @->" at "
RN> conversion).The problem here is that we don't actually keep that information around in the database. This is bogus, and is something that I hope will get fixed when we have a real User database (don't ask when ;)
RN> 2) In the section of the listinfo page where a user can
RN> subscribe to the list in question, please add another
RN> radio-button option for "Conceal yourself from subscriber
RN> list?"I'd actually like to see more options at the subscription page, if not all the options a user can change later (that might be too cluttered and daunting though).
RN> 3) Allow the system-wide admin to disable the mail->news and
RN> news->mail gatewaying for the whole system and/or for selected
RN> lists.You can disable news->mail easily by shutting off the cron entry for gate_news. Shutting off mail->news will actually be much easier to accomplish with the current CVS snapshot, since you can just edit out the ToUsenet module from the message delivery pipeline.
There's a meta-issue about providing more site configuration options via the Web, and that's definitely something I'd like to improve in the future.
RN> 5) Please setup a means by which a user can specify what
RN> additional addresses he/she posts from other than their
RN> subscription address. (For example, my campus has a mail
RN> aliasing system so that all public addresses have the form
RN> "firstname.lastname@usm.edu" or similar. But the address they
RN> post from may be "username@host.usm.edu" or similar. This
RN> becomes a problem for lists that have member_posting_only
RN> turned on.)Again, with a real User database, we could easily allow users to subscribe multiple addresses, enabling delivery to some or all of those addresses, and allowing postings from any of a User's known addresses. Very difficult to do right now unfortunately.
RN> 6) Please setup a mechanism for a pre-made set of options to
RN> be used as defaults when creating new lists.I've thought about this, but haven't had time to work on it. It actually would be easy to do (contributions?? :). Remember that bin/newlist isn't magic -- it's really quite simple. What you could do is hack this script to include various common list "personalities", which really just means certain list option settings, and then just make those settings after the call to newlist.Create().
A simple hack would be to just have a bunch of classes in the newlist script which implement these defaults, and add a command line switch to invoke one of those classes on the newly created list. If you want to get fancy, you could publish an API and let folks add their own list personalities. newlist would try to import a module, dig a class out, call the API method on the list object, and then Save it.
RN> 7) If anyone has written a withlist module that can read in
RN> the values in an existing Majordomo 1.94 config file and
RN> update the corrosponding values in a Mailman list's config db,
RN> I'd be ever so greatful to get a copy.And if you do, please let me know, 'cause I'd love to add something like this to the distribution!
RN> 8) The <body> tag is not currently setup right for error
RN> pages.I don't understand; I guess you mean the driver script is broken? Can you give me more details?
RN> 9) Please build-in the option for individual list owners to
RN> filter binary attachments. (I think something like this is
RN> already in the works, but I'd like it to be a per-list option
RN> settable by the list owner.)Again, while this functionality doesn't exist yet, the new message delivery architecture could accomodate this much more easily.
RN> 10) In the pipermail archives, please do the following:I'd love it if someone became the Pipermail champion. I just don't have the wherewithal to do much development on this code.
RN> Lastly, I'd like to note that, while I understand most of
RN> what's going on in the code, I don't have time ATM to sit down
RN> and really learn Python. Hence, I don't have the expertise to
RN> go about making most of these modifications myself. I do,
RN> however, plan to sit down and learn Python as well as possible
RN> over the holiday break. So perhaps I can pitch in directly
RN> during the new year.Well Rick, it'll probably take you about a day to learn all the Python you need to become a prolific Mailman hacker! Just be sure to try it /before/ you eat the turkey dinner and get all "stuffed". :)
-Barry