Re: [Evolution] Reply for list messages should go back to the list

On Wed, 2010-07-14 at 13:36 +0100, Pete Biggs wrote:

   [ ] Reply button invokes mailing list reply

This doesn't make a lot of sense to me. The user can *already* express a
preference, by moving their hand an inch or two to the left or right and
hitting a different (key|menu item|button).

But there isn't a "Reply to List" button - so instead of hitting the
reply button, you have to press ctrl-L or Message -> Reply to list.  And
no, I do not consider "Reply to All" to be suitable substitute for
"Reply to List".

Providing a 'Reply to List' button so that you don't have to use the
keyboard is a perfectly sane feature request.

But I would consider it to be a separate request.

This strikes me being a "DWIM" feature so that the user only has to bash
their head on the keyboard to get what they want.... as long as they've
preconfigured it.

In general, those who are sophisticated enough to preconfigure anything
are perfectly capable of hitting the right buttons in the first place.
There doesn't seem to be a lot of point in such a context-dependent
action, for someone who knows what they're doing.

I disagree. I have to consciously think "I'm dealing with a mailing list
post, so I don't want to click reply, I need to take my hand of the
mouse before I start typing the reply and then do Ctrl-L, then put my
hand back on the mouse to EDIT the message before starting to type."  If
I happen to be typing a quick reply to something on a list there is a
distinct (and high) possibility that I will automatically click Reply.

You want a Reply to List button.

Alternatively, I already posted a patch which allows you to configure
the existing 'Reply to All' button so that where possible it acts as
'Reply to List' instead -- falling back to 'Reply to All'.

I'm still slightly dubious about that -- I think the actions should each
do what they say they'll do. But at least it's still a *public* action,
when you press the *public* reply button.

Which brings us to...

Then we can debate an appropriate default for the preference.

If we're exposing it in the UI *instead* of the existing 'Reply' action,
then it really *has* to be private by default. The existing UI action
sends private mail, and we can't sensibly change that. Least
catastrophic failure mode and all that. So again it would only benefit
those who are paying sufficient attention to configure it in the first
place, which makes it rather pointless.

Virtually all of the direct replies I get from posts on this list (and
others) are from novice users - they do not realise they sent it
directly to me, they thought they were sending to the list. 

And if I push the nag popup I've already implemented and tested in, those users will get a
pop-up warning saying "You are replying in private to a list which came
from a mailing list.". They'll have to *explicitly* choose "reply
privately" or "reply to all" to continue. 

 All of the direct replies from experienced users are usually followed
within a few minutes by another email saying something like "Sorry, I
replied directly to you in my haste, that should have gone to the

Experienced users do make mistakes, and may well have disabled the nag
pop-up which saves the novice users. But still this is a *much* better
failure mode than accidentally sending stuff to the list which should
have been public.

Users will *always* get things wrong; even experienced users. The
question is what failure mode do we want to encourage -- do we want to
err on the side of sending private information out to the mailing list,
which cannot be retracted and can lead to *very* bad things, or do we
want to err on the side of sending responses to too few people, which is
easily remedied?

I think that any "DWIM" option which automatically chooses between
*public* and *private* on behalf of the user is asking for trouble.

But it's perfectly reasonable for you to want a "Public DWIM" option,
which chooses only between reply-to-list and reply-to-all for you (and
means you don't have to use the keyboard for that). That's what I did in


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]