[petsc-users] Mailing list reply-to munging (was Any changes in ML usage between 3.1-p8 -> 3.3-p6?)

[Jed Brown]

Satish Balay <balay at mcs.anl.gov> writes:

> On Wed, 17 Apr 2013, Jed Brown wrote:
>
>> John Doe sends email to petsc-users and the mailing list rewrites
>> Reply-To back to the list.  Now any user hits reply-all and their mailer
>> gives them a message that replies *only* to petsc-users, dropping the
>> original author.  This is a problem,
>
> Its a problem only if the author is not subscribed.

If they are not subscribed OR if they have turned off delivery.  Even
with delivery turned on, they cannot reliably filter using "petsc-users
AND NOT to:me" because their address will be chronically dropped.  This
makes the list volume more burdensome.

> Or remove option 'subscribe-but-do-not-deliver' for our usage of
> 'Reply-To: list'

That is back to the current model where (I think) many people ask
questions on petsc-maint just because it's more effort/noise to be
subscribed to petsc-users with delivery turned on.

>> Perhaps a middle ground would be to have the list copy the From header
>> over to Reply-to (if it doesn't already exist) and then _add_ the list
>> address to Reply-to.  That still isn't quite right when cross-posting,
>> but it would allow us to advertise "subscribe with delivery off and ask
>> questions on the list" or even "mail the list without subscribing"
>> instead of "always write petsc-maint if you can't be bothered to filter
>> the high-volume list".
>
> Earlier in the thread you've supported: reminder emails to folks doing
> 'reply' instead of 'reply-all:' as an acceptable thing. [and this
> happens a few times a day]. But here a reply of 'use petsc-maint'
> instead of subscribe-but-do-not-deliver with petsc-users' is suggested
> not good. [which happens so infrequently - except for configure.log
> sutff].

I think almost nobody uses subscribe-without-delivery to
petsc-users/petsc-dev because it's useless with the current reply-to
munging.  I reply to the other point below.

> And I fail to see how 'e-mail petsc-maint without subscribing is not
> good - whereas 'email petsc-users without subscribing is a great
> feature'. [yeah you get archives on petsc-users - but I don't think
> uses are as much concerened about that.]

Each time someone resolves their problem by searching and finding an
answer in the archives is one less time we have to repeat ourselves.
The lists are indexed by the search engines and they do come up in
searches.  When a subject has already been discussed, linking a user to
that thread is much faster than retyping the argument and it encourages
them to try searching before asking.  My perception is that a lot of
questions come up more than once on petsc-maint.  We can only link them
to the archives if it has already been discussed on petsc-users, and
with so many discussions on petsc-maint, it's hard for us to keep track
of whether the topic has been discussed.

> And I'll submit - its easier for most folks to send email to
> petsc-maint instead of figuring out 'subscribe-but-donot-deliver stuff
> on petsc-users'. [Yeah 'expert' mailing list users might expect
> "subscribe with delivery" workflow to work.]

Which is why we would encourage them to write petsc-users, either via an
easy subscribe-without-delivery, or by having their original message
only go to a few of us, where a reply from any of us automatically
subscribes them without delivery.

If the list interpreted any mail from a subscribed user as subscribing
the Cc's without delivery, we could also move discussions from
petsc-maint to petsc-users/petsc-dev any time the discussion does not
need to be kept private.

> Perhaps the problem here is - I view petsc-users and petsc-dev as
> public mailing lists - and primary purpose of public mailing lists is
> all to all communication mechanism. [so subscription/ reply-to make
> sense to me.]  And petsc-maint as the longstanding
> non-subscribe/support or any type of conversation e-mail
> to-petsc-developers.

I've always thought of petsc-maint as the intentionally _private_ help
venue.  If the conversation does not have a good reason to be private,
then I'd rather see it on a public (searchable) list.

> But most use petsc-users [and some view it] as a support e-mail adress
> [with searchable archives]. If thats what it it - then
> no-subscribe-post or subscribe-but-do-not-deliver stuff would be the
> primary thing - and recommending that would make sense. And then we
> should be accepting build logs on it as well - and not worry about
> flooding users mailboxes iwth them. [compressed as openmpi list
> recommends]

I wonder if we can do either (a) selective delivery of attachments
greater than some small threshold and/or (b) create a [config] topic
that people can unsubscribe from.  (Maybe leave unsubscribed by
default.)

http://www.gnu.org/software/mailman/mailman-member/node30.html

> [what about petsc-dev? some use it as reaching petsc-developers - not
> petsc development discussions.

I don't think that's a problem.

> And what about petsc-maint? redirect to petsc-users and have
> petsc-developers an non-ambiguous place for non-public e-mails to
> petsc-developers?]

How about converting the petsc-maint address to a mailing list that
allows anonymous posting, but that has private delivery.  We don't use
RT numbers anyway.  Then any time the discussion clearly doesn't need to
be private, we just move it to petsc-users or petsc-dev.  Workable?