Gordon P. Hemsley writes:

Thus, a subject line that begins "[css3-fonts]" will be assumed to be about only the css3-fonts spec, [...] and not, say, the css3-flexbox spec (subject lines prefixed with "[css3-flexbox]").

To handle this, the Mailman archive interface would provide an option to filter only on particular prefixes (as well as messages that don't have any prefixes), allowing a user of the archive to use it as they otherwise would, but filtering the output such that they only see the messages they want to see, instead of the whole archive.

This would not be a big deal to implement in HyperKitty (though I don't personally have the necessary sum of time and interest). If you can wait until next August for product, it would make an excellent GSoC project, I suspect, and probably you could get a patch for Mailman 2's Pipermail archiver from the same GSoC project.

In addition, it would be helpful to allow mailing lists to automatically prefix subject lines when the message is sent to an e-mail address using a plus alias.

For example, sending mail to www-style+css3-fonts@w3.org would prefix the subject line of the message with "[css3-fonts]" in the message sent to subscribers and in the archive, whereas sending mail to www-style+css3-flexbox@w3.org would prefix the message with "[css3-flexbox]".

Yuck. (That's a technical term. :-) This is rather un-Pythonic (violates the "there should be one (and preferably only one) obvious way to do it" principle, AKA "TOOWTDI").

The conventional way to configure this in Mailman would be to have two normal mailing lists (css3-fonts and css3-flexbox), and one umbrella list (www-style) which subscribes to the css-* lists but doesn't receive posts directly. People who prefer to have the server make decisions for them would subscribe directly to css-* lists. Those who prefer to filter themselves would subscribe to www-style.

It should also be allowed to have multiple prefixes on a message, [...]. Now, I understand that this is likely a huge undertaking, but I think it would go a long way to helping users with large and diverse mailing lists.

It's still not a huge undertaking, and would be suitable for a GSoC project IMO.

However, this can also easily be handled by umbrella lists; you just cross-post to the various sub-lists. In the case of Mailman 3, it should also be possible to de-dupe automatically at the server side for subscribers with multiple subscriptions. This would be a GSoC- scale project too. For Mailman 2, it *would* be a pretty big project to de-dupe accurately, although "sibling lists" can help with this.