[Mailman-Developers] Idea of subscription options (beside Digest)

[Stephen J. Turnbull]

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 

1.  Create a true user class that can have multiple email addresses
    associated with it, as well as multiple roles;

2.  Arrange that preferences are hierarchical, so that there are

    1.  Site defaults, which can be configured by the site administrator.

    2.  List defaults, which can be configured by the list owner.

    3.  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. :-)