Updates from the FAQ and TODO files.

Also, add Tollef Fog Heen to list of acknowledgements.

1 files changed, 2 insertions, 25 deletions

diff --git a/admin/www/todo.ht b/admin/www/todo.ht
index d62a2e311..abf75cd1b 100644
--- a/admin/www/todo.ht
+++ b/admin/www/todo.ht
@@ -2,14 +2,12 @@ Title: The Mailman Wishlist
 
 <h3> The Mailman Wishlist
 </h3>
-  You should consider this list of items a good basis for the requirements for Mailman 3.0.  It essentially contains a dream list of all the things that are too painful or destabilizing for the 2.x series.  <p>
+  Here's the wish list for future versions of Mailman.  Many new features have been added to Mailman 2.1 (still in alpha as of this writing 25-Jun-2001), so what's left will probably end up in a Mailman 3.0.  <p>
 <h3> Email Handling
 </h3>
 <ul>
     <li> Use VERP or DSN for address tracing, perhaps tied to the monthly password reminders, or VERPing the occasional regular message.
-    <li> Re-implement bulk mailer the Right Way: an asynchat/asyncore server to do DNS lookups and remote MTA delivery directly (optional).
-    <li> Plain text digests should conform to RFC 1153.
-    <li> If a message has MIME parts and the header/footer is going to be added, the message should be transformed into a mulitpart/mixed with the header and footer added as text/plain parts. 
+    <li> Re-implement bulk mailer the Right Way: an asynchat/asyncore server to do DNS lookups and remote MTA delivery directly (optional). 
 </ul>
 <h3> Documentation
 </h3>
@@ -29,54 +27,41 @@ Title: The Mailman Wishlist
     <li> NO DEAD ENDS
     <li> All web UI must be configurable so that it more easily integrates into an existing site's design.  Probably means using a template language/system like Quixote or PHP.
     <li> Default UI should add a navigation sidebar to all web pages.
-    <li> A heirarchy of page designs and information: e.g. the most specialized of the following wins: site, virtual host, list, language, user.
     <li> Web pages should never mention turned-off features. 
 </ul>
 <h3> List Administration
 </h3>
 <ul>
-    <li> Separate list admin role from list moderator role
     <li> Allow the moderator to edit posts being held for approval (make it evident, either through a header or other means that the message was edited by the moderator).
-    <li> Allow "urgent" postings to all members by the list admin which bypasses normal digest delivery.
-    <li> A button that will bundled and deliver a digest Right Now.
     <li> Allow the list-admin to require approvals for unsubs
     <li> Allow the admin to disable option settings by users
     <li> Ability to set defaults for the various user settings from the "Membership Management" page.
     <li> Allow admins to control and set individual headers, adding, removing, or overriding those in the original message (sometimes very useful, but could be dangerous!)
-    <li> Member management page should display case-preserved email addresses (but still sort case-insensitively).
-    <li> Member management page should work better for humongous lists, both in terms of performance, and in usability
-    <li> Searching for members/addresses with regular expressions from both the command line and web interface.
     <li> New moderation choice: archive but don't send to list.
     <li> New moderation choice: annotate and send to author for resubmittal.
     <li> Make it easier for an admin who manages multiple lists to handling pending requests sitting on all those lists.
     <li> Ability to ban specific troublesome users (from posting, subscribing, etc).  Posts from banned users would be discarded.
     <li> Better integration with moderated newsgroups (and allow some addresses to bypass even that moderation and be delivered to a secondary channel, like moderators@isc.org).
-    <li> Ability to set the next digest volume and issue number from the web
     <li> Add an option to include Reply-To: header in the membership test for a members-only list posting 
 </ul>
 <h3> List Membership
 </h3>
 <ul>
-    <li> Editing your user options should put you back to the edit-options page
     <li> Allow the user to be excluded from postings if they're getting them in the to: or cc: headers.  Be smarter about filtering out duplicate deliveries.
     <li> Have one account per user per site, with multiple email addresses and fallbacks.  Allow them to subscribe whichever address they want to whichever list, with different options per subscription.
     <li> Allow the user to get BOTH normal and digested delivery (but I still don't understand why someone would want this)
     <li> More flexible digests: index digests (subject and authors only, with URLs to retrieve the article)
-    <li> Allow users to subscribe without selecting a password and have Mailman create a password for them.
     <li> Timed vacations, allowing a user to postpone or discard email for a certain number of days or weeks. 
 </ul>
 <h3> Site Administration
 </h3>
 <ul>
     <li> Allow the site admin to define list styles or themes, and list admins to choose one of the canned styles to apply to their list.
-    <li> Full creation, deletion, renaming, etc. of lists through the web (and email?), including fixing aliases file updates.
     <li> add_members should have a switch to disable admin notifications 
 </ul>
 <h3> Other Usability Improvments
 </h3>
 <ul>
-    <li> Allow individuals to turn off password reminders
-    <li> Confirmations should be both email and web based, and be used for both subscription and unsubscription (configurable by the list admin).
     <li> A better strategy is needed for sub-lists and super-lists, including dealing with the resulting password reminders and authorization to modify the sub & superlists.  Majordomo2 is reported to have some good features in this regard.
     <li> Add a limit on the number of posts from any one individual within a period of time (1 post per day, 10 per week, etc).
     <li> Don't use the first public mailing list as the `originator' of password reminders. 
@@ -86,7 +71,6 @@ Title: The Mailman Wishlist
 <ul>
     <li> Provide an email interface to all administrative commands
     <li> Allow email unsubs from matching address to unsubscribe, possibly adding an "allow open unsubscribes" option to control this.  Also, adding a confirmation with hit-reply to resubscribe
-    <li> Add -join and -remove addresses for easy subscription, unsubscription
     <li> For email subscribes, keep an audit of where requests are coming from, and send the original request headers in the confirmation message.  Helps track down subscribe bombs.
     <li> Investigate Majordomo2's email admin capabilities.
     <li> Support the `which' command. 
@@ -96,14 +80,12 @@ Title: The Mailman Wishlist
 <ul>
     <li> Replace cron stuff with our own scheduling mechanism.
     <li> Get rid of the one-shot process model altogether in favor of a multithreaded monolithic architecture.
-    <li> Better support for distributed processing
     <li> Use a real transactional database for all information, and allow various bits of information to come from different sources (a relational database, ZODB, LDAP, etc)
     <li> Keep a members Real Name with their email address
     <li> Member profiles
     <li> Do a serious and thorough security audit
     <li> Allow lists of the same name in two different virtual domains
     <li> More sophisticated attachment handling: strip and discard attachments, post attachments (e.g. via WebDAV) and rewrite to include URLs, etc.  Should be admin configurable based on MIME type.  Check out Bill Bumgarner's work on this.
-    <li> Should include a --with-username=NAME option to configure (and not require it be literally "mailman").
     <li> Should be able to gather statistics, such as deliveries/day, performance, number of subscribers over time, etc.
     <li> Implement something like Roundup's nosy lists, maybe even integrate with Roundup.
     <li> Split Mailman into libraries so, e.g. the delivery part could be used by other projects. 
@@ -127,16 +109,11 @@ Title: The Mailman Wishlist
     <li> allow list owner to edit archive messages
     <li> archive link should do *something* reasonable before the first message has been posted to the list.
     <li> optional form front-end to public interfaces as a filter to address harvesters.
-    <li> clobber_date should support third option: only munge the date if the Date: field is unreasonable (far in the future or far in the past).
     <li> In general the whole Pipermail subsystem needs a good rewrite. 
 </ul>
 <h3> Code cleanup
 </h3>
 <ul>
-    <li> Use all the new wizzy Python 2.0 features
-    <li> Use the re module where regexp and regsub are used (not many left)
-    <li> Refine any remaining unqualified exception guards to specify target exceptions, when appropriate.
     <li> Turn all remaining string exceptions into class exceptions
-    <li> Remove dead code.
     <li> Unit and system test suite!  
 </ul>