Le nonidi 29 prairial, an CCXXIV, Andrew McGlashan a écrit : > If you see no reply-to header, then only do reply to list as already > instructed with L for mutt, which I don't use. > > Always do reply to list, it's simple. IF someone says they are not > subscribed, please CC me, then take that instruction as explicit from > the email that you are replying to ... again, simple. > > I used to do reply-all almost always, now I am more careful due to > requests from others being annoyed. Reply To LIST works perfectly well > for most people and the odd miss due to an extra instruction on a per > email basis is a different problem. I choose this mail to make my global answer because it raises the right points. But this is a reply to all the mails that argue similar positions. Yes, getting it right is simple. Once. But you are not seeing the big picture here. We are not talking about one mail, we are talking about a lot of mails, from several mailing-lists with different attitudes, and also from private discussions, including discussions with people who are usually found on mailing-lists (and that therefore seem at first glance to be on the list). People need get the recipient list right every single time. Even when paying attention, mistakes happen. The more rules there are to follow manually, the more mistakes happen. The whole point of using computers is to automate the stupid tedious tasks in order to save time for the humans for the interesting creative tasks. Choosing the list of recipient can be automated, most of the time. You actually have to wonder why people are so adamant at being good at the tedious automatable tasks; maybe they need to hide how bad they are at the creative tasks: "I have nothing interesting to say, but at least I say it to exactly the right people". Conclusion #1: selecting the list of recipients must be automated as much as possible. Claim (proven later): automation is possible. The efficiency of automation can be evaluated objectively, it is called the entropy. The result, as expected, is that the most efficient case is when there is a single button that does the work almost every time. The worst case is when there are several buttons that are used all roughly the same number of times. With that in mind, you realize that the reply-to-list feature is bad UI design: it moves away from the one-button-does-it-all case (entropy = ~0) towards two-buttons-half-the-time (entropy = ~0.7). This is painfully obvious if you realize that the reply-to-list feature just refuses (at least the Mutt implementation) to work for private discussions. Conclusion #2: the reply-to-list is not good automation. Now, let us examine the consequences of mistakes when selecting the CCs. As often in this kind of cases, there are two possible mistakes: forgetting a wanted CC or adding an unwanted CC. An unwanted CC is a minor annoyance for the recipient. It is not even spam: they wanted to see the contents of the mail, only not directly in their mailbox. A forgotten CC is a much more severe issue: it is breaking the thread for that particular recipient. Even more so, since people who reply to the mail with the forgotten CC will not have the CC either: all the subsequent discussion is diverted from the person who was most interested in it. It is the same reasoning with spam filters: people usually prefer seeing a few spams in their inbox than missing a legitimate, possibly urgent, mail. Conclusion #3: when in doubt, rules and automation must err in favour of CCs. With that in mind, let us examine the "code of conduct": # When replying to messages on the mailing list, do not send a carbon copy # (CC) to the original poster unless they explicitly request to be copied. How does that work, exactly? How is the "original poster" supposed to express that request? Once? Consider people who are involved in half a dozen threads spanning over more than a week. Are they supposed to remember every request of CC by everybody in the thread? That can not work. Or should the request be made on every single mail? People will forget it, and people who reply will forget to take it into account. All these honest mistakes result in broken threads. It does not work. Not really, not with the volume of a Debian mailing-list, and not with the volume of other mail that someone who can make the most useful contributions (someone involved in fixing bugs or developing other Libre software projects) handles. Automation is the only way to go. Conclusion #4: this clause of the "code of conduct" does not work and therefore must be ignored. How should it work. It is not that complicated. Consider you want to reply to one mail with a valid good list of recipients: From: A To: debian-user Cc: B, C Consider this is a normal reply (not, for example, a private reply to ask A how they get the French Republican calendar; for the record this is achieved with a Vim script on top of a specific date format selected in Mutt; I did that when I was young and stupid, but now that I am old and differently stupid I need to get over the inertia and remove it). It must be therefore be sent to the same people who were interested in the original mail. Since we assume the original recipient list is valid, that makes the list itself, debian-user, also B and C since the original mail took pains to add them in CC. And possibly A. And that is an important observation: if there were no mistakes earlier in the thread, then people who were already in CC should be kept in CC, and the question of CCing or not only applies to the author of the message. Therefore, the only information necessary is, for each mail, whether the sender wants a copy or not. (If there was a mistake earlier, people should try to fix it, but that goes beyond the scope of automation.) Conclusion #4: to achieve automation, each mail need to indicate if the sender wants a copy. Since we are talking about automation, that indication must be present in the mail headers. Let us examine the "mailing-list headers" that people pretend can solve the problem. # Resent-From: debian-user@lists.debian.org # X-Mailing-List: <debian-user@lists.debian.org> archive/latest/708606 # X-Loop: debian-user@lists.debian.org # List-Id: <debian-user.lists.debian.org> # List-URL: <https://lists.debian.org/debian-user/> # List-Post: <mailto:debian-user@lists.debian.org> # List-Help: <mailto:debian-user-request@lists.debian.org?subject=help> # List-Subscribe: <mailto:debian-user-request@lists.debian.org?subject=subscribe> # List-Unsubscribe: <mailto:debian-user-request@lists.debian.org?subject=unsubscribe> # Precedence: list # Resent-Sender: debian-user-request@lists.debian.org # List-Archive: [🔎] 7f8e8aed-8919-41dd-3a1f-8633e3aaa240@affinityvision.com.au">https://lists.debian.org/msgid-search/[🔎] 7f8e8aed-8919-41dd-3a1f-8633e3aaa240@affinityvision.com.au # Resent-Date: Thu, 16 Jun 2016 05:58:29 +0000 (UTC) What are they good for? They tell us that it is a mailing list, how to subscribe and unsubscribe, where to find the archives. They do not tell us anything about the preferences of the sender. Conclusion #5: the "mailing-list headers" are irrelevant for the current discussion. Now, finally, how do we achieve automation? The ideal solution would be to have a real header telling us what to do: "List-Reply-To: list" or "List-Reply-To: sender, list". Unfortunately, the people in charge of that messed it up, they invented these useless headers and the "list-reply-to" command instead, see conclusions #2 and #5. But we can make it work anyway by abusing the Reply-To header. Note: this is really abusing the header; the header was not originally made for that and does not allow to express all the policies we could think of. But it works. For most mailing-lists, setting the Reply-To header correctly has exactly the wanted consequences. That is not entirely satisfactory, but it works. So. If I want a copy of the replies, then I should write: From: me@home.org To: debian-user@lists.debian.org Reply-To: me@home.org, debian-user@lists.debian.org If I do not want a copy, I should write: From: me@home.org To: debian-user@lists.debian.org Reply-To: debian-user@lists.debian.org Note that the "debian-user@lists.debian.org" is unnecessary in the first case, but by being there it expresses the policy better. There is no way of saying "reply to me and not to the list"; this would be useful for an announcement mailing-list but not in our case. Theoretically, each list member needs to do that. Otherwise, it would not apply to people they CCed off-list (remember B and C in the example earlier). But this is not a severe issue (remember: unwanted CCs are only a minor annoyance, and most replies happen on the list anyway). In practice, since most users will not do that, mailing-lists managers can supplement by adding the required Reply-To header. They must do it smartly: only when there is not already one, and only when the post comes from a member of the mailing-list. To conclude, this is what I urge people to do: [A] To mailing-list subscribers, set a Reply-To header just as I shown above, to indicate your preferences. [B] To mailing-list administrators, configure the list manager to add the Reply-To header when necessary. [C] To people who reply to mails: just hit the global reply button and let the MUA decide the correct recipient list. Note that this solution is fair: people who are annoyed by unwanted CCs can make them stop with a minor effort of their own, they do not need to ask efforts from anybody else. As for me, I already do [A] and I intend to continue doing [C]. If people are annoyed by CCs from me, I urge them to do [A] (and I have explained how to do it with Mutt; I do not know how to do it with other MUAs, but any MUA worth using should allow it), but they can also try to convince me of stopping doing [C]. But note that they will only be able to do so if they address correctly the points I raised in this mail. In particular, I will not accept any solution that has a lesser level of automation. Also, since this off-topic thread has already gone long enough, I intend to reply only to new arguments. I do not intend to reply when the reply is already present in the current mail. Regards, -- Nicolas George
Attachment:
signature.asc
Description: Digital signature