Garreau\, Alexandre writes:
that might be useful so to standardize mailing lists working per user instead of per mailing-list,
This won't happen in Mailman 2. In Mailman 3, what we've done is
Create a true user class that can have multiple email addresses associated with it, as well as multiple roles;
Arrange that preferences are hierarchical, so that there are
Site defaults, which can be configured by the site administrator.
List defaults, which can be configured by the list owner.
User settings, configured by the user.
4a. User per-list settings, configured by the user.
4b. User per-address settings, configured by the user.
with the later settings overriding the earlier ones. (I forget the precedence between 4a and 4b, so "4a" and "4b" rather than "4" and "5".)
I think that does what you want, right?
so at subscription propose potential following options,
I'm not sure if you intended this, but I will take a look at the default welcome messages. It might be useful to provide a list of available options that the user can tweak for their subscriptions, or even their whole initial configuration, in the welcome message.
“Don’t send me mail with ‘X’ and ‘Y’ CW” (CW = content-warning): X being either specified in subject line (more accessible) such as “[CW X, Y]”,
Either this is "topic" (created by the list owner and used by the posters), which we already have in Mailman 2, and are improving for Mailman 3, or it is AI, and doesn't belong in Mailman (see the discussion of filtering below).
a widely inconsistant behavior for me between mailing lists and mailing-lists softwares, I can never recall it, nor can I recall to
In Mailman 2, this is a general property, and is due to the lack of a real "user" concept in the software design. It will be much better for you in Mailman 3. If you want a consistent experience across lists, get your list administrators to use Mailman consistently! ;-)
“Mail me regularely a reminder” (about that I’m subscribed and how to unsubscribe, may be really useful for low-trafic mailing lists)
Already in Mailman, but many list owners prefer to disable it because their users consider the reminder to be spam, and report it to their email providers, who may make real list traffic undeliverable to all subscribers on their platform. (Not so much a problem today, but AOL was infamous for this.)
or even “unsubscribe be after X delay of inactivity”.
I'd oppose this on the grounds that it's going to be rarely used, and an annoyance for list managers who get hate mail from ex-subscribers who forgot they set that option.
“Don’t mail me again mails that are already also addressed to me” (when the member is already cited in To, Cc, or Bcc for instance) since some people do complain about receiving some mails several times, and it might relieve mailing lists of sending more mails.
Already in Mailman. This is a possible exception to the rule that filtering is best done by the user agent, but it can be equally well done by the user agent.
In general, filtering is best done in the user agent because it needs to be extremely flexible, really a special-purpose programming language. If yours doesn't do it, consider switching; it's a feature I use all the time. I couldn't even keep up with my employer's mail without it (it's in Japanese which has to be the world's most difficult second language ;-).
BTW, in the following I'm going to recommend changing to a competent user agent many times. I know that "the customer is always right", and that users hate changing mail clients. But I *don't* recommend switching because implementing these features is a lot of work for us. The main point is that it is *impossible* for us to *make these decisions well* on the server, while the *client* has the option of making the decision itself, or asking the user. The client will do a *much better* job. Even if the user is not a hacker, configuring a powerful client will serve her needs more accurately than anything we can provide server-side, except for the very simplest cases like "don't send duplicates".
Also, note that *we* don't care about the work as such: it's a labor of love. The problem with work is that it takes time (often years) for volunteer developers to deliver such features, while competent clients are available *now*.[1] The sooner users switch to them and learn to use them, the longer they'll be happy. :-)
Here's an example, which looks simple but in fact really requires the mailing list manager software to read both the posts and your mind:
“Don’t mail me mails from threads I’ve not participated in, except first message”,
There's no good way to identify threads as a human would want it done, because of thread hijacking and topic drift. Inevitably subthreads you want to see will get suppressed, which requires a "send me what I didn't see" feature on the server side, which is a huge complication and in any case involves significant delay. This is partially alleviated by referring to threads archived by the server on a website, but means you have to switch back and forth between your mail client (or inbox tab) and the browser (or archive tab). Most people have enough bandwidth that just receiving 10x as many emails is not a burden as long as the user agent makes it easy to skip them.
In particular, many user agents provide a feature where threads are "collapsed" at the start, and only get expanded when the user decides to read one. This is exactly what you describe as a user experience, and the implementation ("send all mail") matters only if you are severely storage- or bandwidth-restricted. This seems likely only if the mailing list is used to distribute large multimedia attachments, but in my experience this is very rare nowadays -- people use the web for that.
a lot of mailing lists, and some mailing lists to touch a lot more people, as the traffic would be lower, and they might still react to announces and important stuff discussed there.
This is best done by having separate low-traffic lists, or using topics, although both have serious problems in the user experience too. A good user agent is worth its weight in gigaflops.
“Don’t mail me mails from threads I didn’t started”:
The only time I would find this useful is when I've sent a problem report to a mailing list rather than a bug tracker. In that case I'd ask the vendor to set up a tracker or web forum like StackExchange.
Do you have another use case? I didn't find "subscriber-only" persuasive as a general matter; there are lots of discussion lists which require subscription to post nowadays, as it's a relatively useful barrier to spam. And once again, a competent user agent or filter like procmail could do this for you.
Hope I’m encouraging and giving more ideas than I’m disturbing or seeming expectative. I find these would be really lovely features,
Most are already present, or beyond current server-side technology while already acceptably implemented in good user agents. I hope you'll look into configuring them in Mailman lists you're already using (in Mailman 2, for many options you can set them for all lists on that server with that address subscribed, so it's not that inconvenient). And as we roll out new releases of Mailman 3, with better support for user configuration options, I hope you'll support the administrators of lists you use in migrating to Mailman 3. (At present because of the complete reorganization of the database, it's painstaking to upgrade, but we're working on that.)
Steve
Footnotes: [1] You probably don't want to ask me to recommend one; I use Emacs and procmail. :-)