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?
